Reputation: 7549
I have an application that has an IntentService to provide background processing - specifically it fetches data from the net and stores it in an Sqlite database. My Activities use Context.startService() to request the service to update data, and the service sends a local broadcast message when the update is complete.
The IntentService uses a thread pool to do the work - primarily in case a new Activity is opened before a request is complete, so a new request for a different resource won't block waiting for the previous one to finish.
That all works fine, but in order to prevent multiple simultaneous requests for the same resource, I set a flag in the activity after it has sent a request which stops it sending new requests until it gets back a DONE message from the service.
Now if the IntentService was killed off in the middle of an operation it will never send the DONE message, and the Activity will never know that the request is unfulfilled, and will not re-request the resource. Is this possible? And if it happens is there any way for the Activity to be informed?
Upvotes: 2
Views: 374
Reputation: 7824
If you are concerned about this then send a broadcast flag in the onDestroy of the IntentService (or just set a breakpoint so you can see if it is being hit). The IntentService is intended as a simplified service which handles its own lifecycle so if you are passing work from the service to a thread pool it's possible the IntentService believes it finishes its work - you can catch this in onDestroy.
Obviously can't say if that is happening without looking at the code but this mechanism will let you check if it is.
Upvotes: 0
Reputation: 1007276
Is this possible?
So long as you are catching all possible unhandled exceptions, no. Components are not "killed" individually for, say, memory reclamation -- that is done on a process-by-process basis.
Upvotes: 3