05-09-2012 05:06 AM
I am developing an app which needs to be running continuously. I set it to autostart, but I need it to restart if the user stops it or in the event of a crash.
My two techniques so far are:
- using the FLAG_AUTO_RESTART flag (FLAG_AUTO_RESTART)
- having a separate watchdog process that makes sure the main thread is always running (scans for visible apps and uses app descriptor to restart if necessary).
The problem with the FLAG_AUTO_RESTART flag is that it takes up to a minute to restart - the original instance must be properly shut down prior to restart - and this really impacts on the user experience.
The problem with the watchdog process method is that you need a second process which must poll for closure of the main app (and vice versa) which creates an overhead I'd prefer to avoid. I'm also thinking it needs to be an entirely separate app, in that the alternate entry point technique wouldn't work since we would be scanning for the same app.
Has anyone got any advice or experience they could offer regarding which technique is better, or if there is something else I have not considered?
Thanks very much.
Solved! Go to Solution.
05-09-2012 05:15 AM
05-09-2012 05:27 AM - edited 05-09-2012 05:28 AM
Hi Simon, thanks for the quick response. No problems with app crashing (yet!) but it needs to stay running to monitor certain activities so it's a safeguard more than anything.
So you would prefer the watchdog method with alternate entry point? How would I detect the same app started with an alternate entry point and vice versa (i.e. both app instances detect each other and restart each other as necessary)?
05-09-2012 05:34 AM
05-09-2012 06:16 AM
I think I need it to be responsive right away in case the user hits the icon and launches the GUI, hence watchdog seems the way forward. I'm supporting BB7 and upwards; does this mean the restart time still needs to be 60 secs? This KB article is from 2006 after all...
I think I see what you mean regarding ID - you just scan for modules with same name and get two app descriptors or handles back (or just one if the other has terminated). We can find our own module handle easily enough so we know what needs restarting.
I've think what I'm going to do is this:
- Have a single app with two AEPs. One for the UI and one for the monitor/listener.
- The monitor runs on startup and sets the FLAG_AUTO_RESTART flag on itself. It will then restart with the given delay.
- The UI runs from an icon and checks for the presence of the monitor, starting it if necessary.
- Both modules access a common data store. This contains the data collected by the monitor module and is displayed by the UI module.
So, just one more thing relating to module naming if you would oblige... can I be sure my module names are consistent after release? They won't be appended or prepended with net_rim_blahblah or anything?
05-09-2012 06:56 AM
Short of hand-editing the xml app descriptor to include an auto-restart flag that may or may not exist, thereby saving the hassle of restarting, is there any reason I shouldn't use a third AEP to start the monitor with a custom descriptor containing this flag on first run? This would effectively provide the immediate restart solution.
Does this cause the same problems as immediately restarting the same AEP before the old one was fully initialised/shut down? Because then surely there would be problems using *any* two AEPs under normal conditions since there is a risk one would fail to start properly depending on timing.
The thing that doesn't make sense is that the new instance will have a different handle so why are they conflicting?
05-11-2012 04:49 AM
Sorry I am coming in late on this and may have missed something:
The restart process you have pointed us to is only applicable for an application that restarts itself. I believe the timing issue is to make sure that the application has actually stopped before a restart is attempted.
You can use ApplicationManager to run a new Application immediately. You just need to set up the ApplicationDescriptor. If you are doing this from an AEP, then your can take your own Descriptor and change the param String to match the Application you are trying to restart.
So I think your approach with a UI and a Monitor AEP will work fine.
That said, I think this is overkill. Once the Application has started, in reality, there is nothing that will kill it, except System.exit(..). So if you make sure your UI doesn't do this, either intentionally or unintentionally by closing the last MainScreen, then your Application will stay up. Errors will occur on the processing, but these are usually on the Event Thread or some other Thread you are processing and just stop that Thread or that processing. So your Application should not itself stop.
I don't have watchdog Threads checking for Applications, I have them checking for critical processing in my Applications, for example the Network Listener.
The big exception here is anything that you do that makes the OS think your App is unstable, for example, blocking the Event Thread. That will cause the OS to kill your Application. Shouldn't happen in a well written program, and if it does happen, restarting the Application may just result in happening again, and again, and again - the old infinite BSOD problem.
Finally in answer to "can I be sure my module names are consistent after release" - Yes.
05-11-2012 10:53 AM
Hi Peter, thanks for your help.
Firstly, I'd like to link to this thread I started relating to immediate restart (I thought this thread had been buried and maybe I'd gone off topic).
That thread explains my current solution, which is effectively a sinlge app with 3 entry points. One simply starts the second with the FLAG_AUTO_RESTART flag, terminating itself in the process, and the third is the UI app that the user starts manually. This saves mutual polling for the other app's presence.
Regarding the possible overkill nature of this solution, I want to streamline the user experience by providing only one visible, useful interface to the user. The monitor will just sit there and operate unseen in the background and respond to whatever events it needs to. There's also the possibility that something will cause a crash and I need it to come back without missing key events, but I don't want the UI to appear each time. With any luck I can get these cases to a minimum with proper programming!
In summary, and I think with your agreement, the basic answer is FLAG_AUTO_RESTART is better. It just cannot restart *itself* without a delay. And there are ways to get around this delay.
Hopefully I got it straight - please let me know if not but huge thanks to Simon and Peter.