11-20-2011 05:09 PM
I ran into this problem at my UI App in last one day and spent quite some time over this. The root reason I found out is that the code didn't call a clean up code at one of screen close method (last screen), so the following won't be cleaned up:
1. my whole UI app is put into runtime store
2. global envent listener for my Ui App
After debugging, I found out that it is due to the #1. However over the debugging time, I found out that this problem actually is very hard to debugging since reproducing it is not consistent. So even every time, I won't clean up my Ui App from the runtime store at my last UI screen close, the "previous instance is still active" will only appear after quite some runs (it seems that I should also let my screen open for a little bit time as well). So although that I could not reproduce this problem any more after adding the clean up code at close method of last screen, I can not say 100% here that I fixed the issue.
It would be appreciated if someone would confirm the reproducing behavior I saw here.
At this post, it also talked about against to put the whole app into the runtime store:
So I think that I should remove the code to put whole Ui App at the runtime store anyway.
I also searched on the forum, I think the following 2 posts are most helpful:
In the post, it said that we need to be careful with external listener. For my background app, I did use phone listener and I found out that it would be invoked at phone application. However other listeners which I used as following, I haven't seen that they are invoked at external applications (should be at the main event thread of current background application)
CoverageStatusListener, RadioStatusListener, WLANConnectionListener
Should I be concerned with those listener as well?
Solved! Go to Solution.
11-21-2011 03:41 AM
11-21-2011 04:31 AM
I agree with Simon, and I think it is good to think about what happens when you remove a Listener too.
That said, it is unlikely that a Listener that is registered against your own Application will cause this problem. So things like SystemListener are not where I would look first when faced by this.
11-21-2011 06:46 AM
Thanks to both Simon and Peter.
>>I think it is good to think about what happens when you remove a Listener too
Not sure if I understand this completely.
I am already doing that to unregister every listener. I guess my concern is also about what if background application is crashed with some unhandled exception or for some other reason. I guess for this case, there is not much we could do here to cleanup unless that we would have to make sure that we did catch every exception possibly and then do proper shutdown as well. However there is no default exception handler at blackberry, there would be some cases that background application would crash. In this case, if I do get the "previous instance is still active", I am not sure if there is anything we could do here.
There are also worries that previous listeners would still be there after application is crashed at this post: http://supportforums.blackberry.com/t5/Java-Develo
listeners in native apps are not removed when the app exits.
they are weak references, this means that your app does not stay in the memory.
the listeners, are still active. they are running in the context of the native applications (this is proven), but are nonetheless part of your application.
it is getting problematic when you restart your app. in my experience the listeners are called multiple times, that means the remaining listener from the last instance docks with your new instance.
i suggest to use a shutdown method instead of just calling system.exit when employing listeners to native apps (like phonelistener etc).
i use runtimestore to store references to the listeners i register, this way i can't register a listener twice even if the app crashs and is restarted.
>> they are running in the context of the native applications (this is proven)
For this, I am not sure this is true for every listener. It seems to me that this is only for external listener.
I guess at this case, I would have to store all the listeners at the runtime store. On startup of my application, if I found out there are still some old listener at the runtime store, I should remove it from runtime store and deregister the listener as well (not sure if old listener could be invalid here or not, and whether deregister such listener would have any bad effect or not, I guess I need some testing here). Then I could start up my application cleanly.