Question

Previously, under desktop environment, to implement a stock price alert system, here is what I do.

1. Spawn a infinity running Thread.
2. The thread will perform stock price query from stock server.
3. The thread will perform all the necessary alerting actions based on retrieved stock price.
4. The thread sleeps for N period. (N can be let’s say 30 minutes)
5. Go back to 2.

When comes to mobile environment, power efficiency usage is a major consideration. The stock alert mechanism should keep running, even when I “close” the application using back button.

There are 2 ways out from my mind.

Use Service

1. Spawn a infinity running Service.
2. The service will perform stock price query from stock server.
3. The service will perform all the necessary alerting actions based on retrieved stock price.
4. The service sleeps for N period. (N can be let’s say 30 minutes)
5. Go back to 2.

Use AlarmManager

1. Install a BroadcastReceiver in AlarmManager.
2. BroadcastReceiver’s onReceive will be triggered in next N period.
3. When BroadcastReceiver is being triggered, perform stock price query from stock server.
4. The BroadcastReceiver will perform all the necessary alerting actions based on retrieved stock price.
5. Before returning from onReceive, install another BroadcastReceiver in AlarmManager for next N period.

I was wondering, which way is better? Is there any better ways other than the 2 ways? It seems to me AlarmManager is better, as we do not require to sleep for a long period, which seems sort of wasting resource?

Answer 1

Use AlarmManager to trigger a BroadcastReceiver then have the BroadcastReceiver start an IntentService.

A BroadcastReceiver shouldn’t do any long-running tasks but it can start a Service to do work. An IntentService (which extends Service) will do work on a worker thread and then self-terminate.

See IntentService

And Extending the IntentService class

In other words you can combine both ways that you are considering but without a continually running Service.