Reputation: 573
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)?
Upvotes: 1
Views: 983
Reputation: 1006799
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.
Upvotes: 4