How would one go about making sure a broadcast receiver (triggered)
code can run for more than 10 secs (this is the limit when you start
seeing not responding warnings),
This has been much disccussed in this group and excellent suggestions
and even working code like "wakefulintentservice" (thanks to Mark
Murphy) is available now.
Some of the available mechanisms are
1. Use a static wake lock in the broadcast receiver and start a
service. Have the service spawn a thread. Pass a handler to the thread
so that the thread can terminate the service when it is done. (A
static variable is only way to communicate between independently
invoked service and the broadcast receiver)
2. The protocol above is formalized in the SDK in 1.5 with something
called an IntentService quite nicely except for the wake lock
3. Mark's WakefulIntentService updates the solution 2 with a partial wake lock
I have been tinkering with these ideas and have some early sample code
that further narrows the problem space to specifically a
broadcastreceiver that is intentionally for long running code.
Here is the usage pattern.
Step1. Code a broadcast receiver inheriting from an abstraction that
is called "ALongRunningBroadCastReceiver". Here is an example
public class TestLRBCR extends ALongRunningReceiver
{
@Override
public Class getLRSClass()
{
Utils.logThreadSignature();
return TestLRBCRService.class;
}
}
The "LRBCR" stands for Long Running Broad Cast Receiver. Only thing
the derived class needs to do is specify the classname of a delegated
long running service. In this case it is called "TestLRBCRService".
Step2: Service code: Here is code for that service. I have excluded
some spurious lines that deal with debugging etc.
public class TestLRBCRService extends ALongRunningBroadcastService
(extends from IntentService)
{
//Required by IntentService
public TestLRBCRService()
{
super("com.ai.android.service.TestLRBCRService");
}
/*
* Perform long running operations in this method.
* This is executed in the
*/
@Override
protected void handleBroadcastIntent(Intent broadcastIntent)
{
Utils.logThreadSignature();
String message =
broadcastIntent.getStringExtra("message");
Log.d(tag,message);
// Sleep for a few minutes here if you want,
// it will keep the device partially on
and honor the delay
}
}
Clearly one has to define the broadcast receiver and the service class
in the manifest file.
Under the covers the abstract classes starting with "A...." will use
the wake lock and the intent service to make this work. The novelty i
have tried to accomplish is
1. Make the whole thing look like just a broad cast receiver and hide
the service as much as possible with only one method exposed
2. Pass along the broadcast intent all the way to the receiving
service method as if the service method is getting the broadcast
intent.
3. I have also taken a very slightly different approach to holding and
releasing the locks with an extra release from the "onDestroy" of the
service just in case (although unlikely) if the start and stop
services don't coincide due to exceptions or errors in code
I am hesitant and suspect that this may be a fishy thought.
Let me know if it is not the best of ideas...
Thanks
Satya
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
