Question

I am developing a Multiplayer Online word game on Android and would like to implement a thread that checks for server side events like the following:

• Player join a game.
• Player left a game.
• Player won a game.
• etc…

The thread will be responsible for listening for all kinds of events and dispatching events to the responsible activity If it’s visible to the user.

In other words to be more clear, I’ve got a list of event and each activity must register to a subset of these events.

Events:

E1 – E2 – E3 – E4

Activities:

• Activity 1 interested in E1 and E2.
• Activity 2 interested in E1, E2 and E3.
• Activity 3 interested in E3 and E4.

I am asking about the best design approach to implement a thread that runs in the background and can dispatch events to all activities?

Some Ideas:

-Implement an AsyncTask on the application level.

-Send broadcast intents to a custom actions.

-A service is not the best approach because it should be created to run in the background when the user is not interacting with your application.

Can you propose a best practice approach?

Answer 1

A good approach for this is to use a Service combined with AsyncTasks.

While a Service is useful while the user is not interacting with your application, that certainly isn’t its only use. A Service is the logical home of anything that does not require a UI.

In data driven apps, I have used Services as API adapter layers. It is nice because I can launch it from any activity without worrying about whether it is already instantiated or whether I need to do any cleanup work after I’m done. The framework manages the service’s lifecycle and tracks clients.

I think your case is similar. Each activity can use bindService and unbindService to register for updates as long as it needs. The service will continue to do its thing as long as any Activity is bound. The service can keep track of which activities need updates using the Intents received in onBind and onUnbind, and send them updates via specific Intents, or, more appropriately, the service can fire broadcast intents and the Activities can register for what they need.

Within the Service, you would run AsyncTasks (probably running them on AsyncTask.THREAD_POOL_EXECUTOR so you get more than one thread) to do your updates. Remember that the service itself is launched on the UI thread.

Another nice benefit to using a service is that it doesn’t require an Activity to run. One use for this that comes to mind is post-shutdown cleanup. If you need to post scores or analytics or something when the user exits, you can allow the activity to close quickly and finish the longer-running work in the background.

Activities can request those longer individual tasks from the Service using startService, and the service won’t exit until it calls stopSelf (or stopSelfResult).

The combination of start/stop and bind/unbind really allows for clean management of the service. It will run when and only when it needs to, and you can keep all your API access in one place.

Edit:

As if this wasn’t a stout enough wall of text, I’ve come up with another good reason to use a Service. From the developer guide on processes & threads:

Because a process running a service is ranked higher than a process
with background activities, an activity that initiates a long-running
operation might do well to start a service for that operation, rather
than simply create a worker thread—particularly if the operation will
likely outlast the activity…