Jeffrey Blattman wrote:
mark, "perhaps some sort of service" is a little vague.
Generally speaking, if your manifest-registered BroadcastReceiver will
be doing things that are short (say, under a second), you won't need one
-- just do all your work in the BroadcastReceiver.
If you are going to do things that may take longer than that, such as
uploading something via the Internet, you'll need to delegate that work
to a service that can do things in a background thread (e.g.,
IntentService). A manifest-registered BroadcastReceiver cannot fork a
thread, and it is called on the "UI thread", which does not support
time-consuming operations.
the AM schedules an alarm that calls a receiver that does three things,
1. updates some data that is shared with the activity
You don't indicate where, but I'm going to assume the data is on the
device, not the Internet.
2. sends notifications
3. broadcasts back to another receiver that updates the activity, if
it's running (the activity registers / unregisters the receiver in
onResume(), onPause(), so it doesn't get called if it's paused or stopped).
i *could* have the scheduled BR call a service like in your example, but
why can't i just have the scheduled BR do the work?
Assuming #1 above is not too time-consuming, you can.
why would that make
a difference as to whether the BR is being called or not, which is the
root of my problem?
In my first reply, I wrote:
"You could encounter that behavior if you registered your
BroadcastReceiver via Java, instead of via the manifest."
You never stated, in any of your messages, how your code sets up your
BroadcastReceiver. And, since the only way to really use AlarmManager
effectively is to use a BroadcastReceiver registered via the manifest, I
have been trying to steer you in that direction.
If I am correct, and presently your alarm-catching BroadcastReceiver is
registered via registerReceiver() in some Java code, then that will only
respond to alarms so long as whatever contains it (e.g., activity) is
running. In this case, change your application logic to have the
BroadcastReceiver be its own standalone public class (vs. an inner class
of something else), dump the registerReceiver() and unregisterReceiver()
calls for it, put it in the manifest via a <receiver> element, and see
if that improves your results. The example I have been pointing you to
demonstrates receivers registered this way. There are a few other
examples of this technique in the SystemEvents set of projects.
If you *do* have your BroadcastReceiver registered via the manifest,
though, and you're not getting the alarms, then something else is afoot.
