Issue
I am developing an Android application which runs a series of asynchronous sensor scans such as getting a list of MAC address of nearby bluetooth devices, getting the current location of the phone (GPS) and recording an audio sample of the surrounding noise. Whenever each scan finishes I want a service to handle sending the collected data to a webservice (using http and REST).
The question I am facing is whether I should implement my own custom Service or use an IntentServce for handling multiple requests (intents sent using 'startService()') for uploading the data, because I want to be 100% sure that the found data eventually is sent to the webservice (if internet connection becomes available).
If Android decides to kill my IntnetService or the user force-kills it while still processing it's work queue of requests, will I lose the queue of pending requests? I.e. will I need to save the state of the work queue (and therefore be forced to implement the Service myself without the use of IntentService)?
Solution
If Android decides to kill my IntnetService or the user force-kills it while still processing it's work queue of requests, will I lose the queue of pending requests?
Your queue will evaporate if the user reboots their device. Otherwise, at least in theory, returning START_REDELIVER_INTENT
from onStartCommand()
(which is the IntentService
default IIRC) should give you any Intent
commands that were not handled.
That being said, if you "want to be 100% sure" the commands are processed, I suggest that you create your own durable work queue (e.g., database table). Use an IntentService
more as a request to process all outstanding durable work queue events (if any). Use a BOOT_COMPLETED
BroadcastReceiver
to handle the reboot case, telling your IntentService
to process any commands left outstanding due to the reboot.
Answered By - CommonsWare
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.