When my midlet goes into the background, I still have a thread running, doing some work. Sometimes it tries popping up a notification by eventually calling setCurrent().
On my test blackberry device, the call to setCurrent() actually forces my application into the foreground again. Is there any way to block that from happening, other than coming up with my own system of catching calls to setCurrent() and ignoring them while in the background?
I think I came up with something that works, I'm confused because the j2me docs use the word "may" a lot, so I'm thinking maybe you can choose the behavior. This is what it says for setCurrent() that led me to my current state of confusion:
"The application may pass null as the argument to setCurrent(). This does not have the effect of setting the current Displayable to null; instead, the current Displayable remains unchanged. However, the application management software may interpret this call as a request from the application that it is requesting to be placed into the background. Similarly, if the application is in the background, passing a non-null reference to setCurrent() may be interpreted by the application management software as a request that the application is requesting to be brought to the foreground"
"passing a non-null reference to setCurrent() may be interpreted by the application management software as a request that the application is requesting to be brought to the foreground"
but I guess on my blackberry the "may" == "will".
Ok so now I'm just not calling setCurrent() if my midlet is in the bg, but when my app first comes back into the foreground via startApp(), I take an extra step and call the pending setCurrent() myself to make it seem like everything has been running in the background as usual.