However, I recently read that an intentService may be more suitable for a long-running task as it is not run on the ui thread, but its own worker thread
Only for things that are "transactional" in nature: database I/O, Web service calls, downloading small files, etc. It is not suitable for cases like yours.
I am assuming this is because nothing is actively happening in the service, while the listeners wait for a location to be received, and so the service ends itself
More specifically, once onHandleIntent()
returns, if there are no more commands waiting to be processed, the service calls stopSelf()
.
What can I do to postpone when the service is ended?
Go back to your original approach, but have the locations delivered to you on a background thread, by using a HandlerThread
and the flavors of requestLocationUpdates()
that take a Looper
. That way, when your location arrives, you are on a background thread and can do whatever you need to do with the location, then you can stopSelf()
to go away.
However, this gets tricky, insofar as you also need a timeout, in case you never get a location fix. And, you have to worry about keeping the device awake, so it does not fall asleep while you are waiting for a fix. I wrote a LocationPoller
library that handles this stuff, though I have not used it in years, and so there is a fairly thick layer of dust on it.
You might consider using the PendingIntent
flavors of requestLocationUpdates()
, or its equivalent on the LocationClient
API, as an alternative to any of this. Then, you can use an IntentService
just for processing the results of a location fix.