Best method to run a periodic background service in java blackberry

Question

Objective: I want to develop an UI application that runs a service/ task/method periodically to update database. This service should start after periodically even if my application is not active/visible/user exits app. Similar to an Android Service .

I'm using BlackBerry Java 7.1 SDK eclipse plugin .

The options I came across are the following:

1) How to run BlackBerry application in Background

This link suggests that I extend Application instead of UIApplication. But I can't do that as my application has a user interface.

2) Make application go in background

I don't want my UI application to go in background, instead i just want my application to call the service periodically .

3) Run background task from MainScreen in BlackBerry?

This link suggests to run I a thread, but I don't think that if user exits my application then the thread will run in background

4) Blackberry Install background service from UI application?

This suggests using CodeModuleManager ,whose usage I'm unable to figure .

Please suggest what is the best way to achieve this objective or suggests any other better method .

I am new to blackberry so please pardon my ignorance.

Answer 1

To expand on Peter's Answer:

1. You will need to create two classes :

   class BgApp extends Applicaton
   class UiApp extends UiApplication
   

   I guess you have already created the class that extends UiApplicaiton. So add another class that extends Application.

2. Then create a class that extends TimerTask and implement its run method to call the method that updates the database.

   class UpdateDatabaseTask extends TimerTask
   

3. In the BgApp constructor, create a Timer. And schedule the UpdateDatabaseTask using the schedule(TimerTask, long, long) method.

4. Define alternate entry points, check the "Do not show on homescreen" and "auto run on startup" checkboxes for the bgapp's entry point.

5. It is easiest and simplest to use the builtin persistence mechanism (PersistentStore and Persistable interface) for storing data. Even if you use any other means like RecordStore or SQLDb, both UiApp and BgApp can use access the same database. The values updated by the bgapp will be accessible by the uiapp and vice-versa, automatically.

6. If you want to send a signal from bgapp to uiapp (for example when bgapp downloads new data you want the uiapp to reload the data instantaneously), post a Global Event (ApplicationManager.postGlobalEvent()) when the download is complete and listen for it in the screen that is displaying the data (GlobalEventListener interface).

There are code samples for each of these available as part of the SDK or search on the internet and you'll find a lot of implementations.

Answer 2

Good research, lots of interesting thoughts.

I think the best thing to do is to try the simple standard approaches and only make something more sophisticated if you need to.

Here are two options that would be regarded as 'standard', with brief advantages and disadvantages:

a) Make your UiApplication go to the Background

Instead of exiting when the user presses the 'close' button, your UiApplication will "requestBackground()". it will automatically be bought to the foreground when the user clicks on the icon, or selects your application from the task switcher. Then you can run a Thread whenever you want or in fact leave one running to update the database.

This is my preferred method. But you have to careful with memory management to make sure there are no leaks. And some people don't like the idea that the Application is visible on the Task Switcher all the time.

b) Alternate Entry

With this option, your one Application package contains two Applications, or more accurately, one Application and one UiApplication. The UiApplication is run when the user clicks on the icon. The Application runs as a background task, and updates the database for your UiApplication.

This looks like a more elegant solution, but introduces some possible communication issues, and is more difficult to debug.

In your case, since you are relatively new to BB, I would suggest that you use option a, and if you find it doesn't work for you, you will not find it that difficult to swap to option b.

And to comment on the Options you have already presented:

1. Sort of covered with option b
2. Option a
3. You are correct - if an Application exits, all the Threads are killed
4. Leaves the problem of creating the application in the first place and then debugging it. This is not really a solution for you, more an implementation method.

The above is brief, please ask if it is not clear. This might help with b: http://supportforums.blackberry.com/t5/Java-Development/Set-up-an-alternate-entry-point-for-an-application/ta-p/444847

Edit:

Editing this to respond to the questions and to expand on the alternative answer, which expanded on this one (bit circular I know...).

To answer the second question first, I agree with the other answer which states the alternate entry (background) and the foreground app can share an SQLite database.

With respect to how these two communicate, while they work just fine, personally I am not a great fan of Global Events because they are propagated to all Applications on the BlackBerry. You can achieve similar things in many alternative ways - the trick is to find something that is common to both applications so that they can communicate. To this end, I recommend using RuntimeStore. See this KB article:

http://supportforums.blackberry.com/t5/Java-Development/Create-a-singleton-using-the-RuntimeStore/ta-p/442854

Regarding how you persist your database, I like PersistentStore because it is present on all devices. But if you really have a database, and not persistent Objects, then SQLite seems the ideal thing to use. Personally I would not use RecordStore, but here is a discussion of the options:

http://supportforums.blackberry.com/t5/Java-Development/Introduction-to-Persistence-Models-on-BlackBerry/ta-p/446810

And just a clarification - in the example given, you have two applications, BgApp and UiApp. You will only have one main() method. This main method will use the args that you specify to determine which one to start, which it will create and have it "enter the dispatcher". If I could make a recommendation - use "gui" as the argument to specify that you will start your UiApplication. I have experienced a circumstance that the OS attempted to start my alternate entry Ui application with this String, regardless of what I had actually specified. Might have been a one off, but I have stuck to doing that ever since.

Finally two comments on the use of Timers and Timertask to provide triggered events. The first comment to make is whatever you run in the TimerTask should not take that long - so you should just use the TimerTask to initiate the download Thread (which might take a long time). Secondly for me, in this situation, I would not use Timer/TimerTask. I would rather just have a single Thread, which 'waits', and then processes. The advantage to me is that this can be adaptive. For example, if you fail to connect, then you might shorten the time till the next connection attempt. Or if it is after hours, then you might lengthen the time between connections to reduce battery usage. Or you might stop connecting completely when the battery is very low.

Hope this helps.