views:

52

answers:

1

Hi,

I have some questions about the Android service and activity lifecycles. Hope you guys can help me out. I have written an application that uses GPS location and stores them. It must monitor the GPS location updates constantly to work properly.

Right now, it's all in one activity. So when you close the activity, you loose everything and can't continue monitor location updates. This is why I wanted to make a background service for the monitoring part. And I've been reading the Android Developer Guide and the Reference, but still can't fully understand the activity-service-process-lifecycle thing.

Consider this: you start the application. It gets a GPS fix and now you can start monitoring the location updates and save them. When you do so, it should start a service that receives GPS location updates. So now you have an activity AND a service running in the same process. Ok. But what happens if you push the hardware Back-button on your phone? Will only the activity be killed with the process still running your service? Or will it kill both, the activity and the service and thus also the process? Is there some way to ensure the service keeps running in the same process after the activity is killed? But a way not so complicated as the whole aidl thing for remote processes?

Creating a service in a new process seems unnecessary to me, because no other application should use my service, I just need the monitoring part to keep running while the (GUI) activity is dead. I wanted to make something like the Local Service example on the Developer site, but I must be sure the service keeps running after the activity is killed.

A: 

When the user hits the back button it is different that when the system ends the process that the application was running in. The current activity will finish() but the process remains alive. Android will, as long as memory permits it to, keep the service alive regardless of whether or not the activity is visible.

From the docs

If the service has been started, then its hosting process is considered to be less important than any processes that are currently visible to the user on-screen, but more important than any process not visible. Because only a few processes are generally visible to the user, this means that the service should not be killed except in extreme low memory conditions.

Services should NOT however remain in memory forever, this is bad practice and not exactly what you want. I would recommend using an IntentService coupled to receive location updates via a LocationListener and LocationManager link to docs

public void requestLocationUpdates (String provider, long minTime, float minDistance, PendingIntent intent)

This setup should serve you quite well because on each update you can fire off an Intent which can be handled by your Service, if it is not alive it will be created.

smith324
Thanks for clarifying about the activity termination thing.I've read about the memory managment techniques of android. There is a hierarchy for processes based on what they host etc.The solution you proposed, with firing intents to my service which can be restarted if it's not running is not really an option.My service should keep running until a certain GPS location is reached or the user closes the whole thing via the GUI. The task of the service is to monitor the locations coming in and to analyse them, so it should not be terminated while doing so until it's done. Else it's useless.
Androipithecus
I see no reason you couldn't do that with the method I described.Heres the situation.Your Activity registers a LocationListener with the LocationManger and using the requestLocationUpdates is scheduled to send an Intent to your service on EACH location update. When your service receives that intent it can compare it to this 'certain location' and do some action when it reaches it.
smith324
I see no reason why I should do it this way. If I understand this correct, requestLocationUpdates(...) used with an Intent will be able to restart the service? But if the service is killed in the middle of it's operation, I don't need it to be restarted, it's useless to the program. So why not use the normal requestLocationUpdates(...) with a LocationListener in the service? I mean, in my case, the service restarting capability is not needed, because once it's dead and the data aren't saved, the program has failed. For the same, you can just restart the app.
Androipithecus
The `requestLocationUpdates` when used with a `PendingIntent` will basicly send your service a message with the current location once the `LocationListener` has an update. Any information you may need later you can store on disk.If you don't want the auto restart then just use a `Service`. I have just recommended the `IntentService` because I believe it suits your needs better.
smith324
Thanks. I have made it with requestLocationUpdates with a LocationListener and the service in foreground, there was written somewhere that it won't be destroyed as fast if the service runs in foreground.
Androipithecus