My activity binds to a service in onResume and unbinds from in onPause so it can use the service as long as it is active.
Now I want to avoid this (un)binding if the activity is recreated only because of an orientation change (display rotation). Keeping the connection object alive (instead of creating a new one) is possible using onRetainCustomNonConfigurationInstance().
But I don't see a way to know when I can skip unbinding in onPause and later re-binding in onResume. What can I do to handle this special case?
Another thing I'm thinking about is, is there a way to get told when the app goes active or inactive? Then I could keep the service alive for all my activities and unbind from the service only if the app gets destroyed or put in the background. (compared to bind to the service for each activity, which I have to do to in order to unbind the service correctly when an activity is left and no other one is coming)
Related
I am looking for a bit of app design advice.
I have an app that connects to the Google Location Services and tracks location coordinates it receives. These are displayed as a path on the UI.
When the screen times out and goes blank then this Activity will, of course, shut down as per the normal Activity life cycle.
However - I atill want to record the co-ordinates coming back in each onLocationChanged event from Location Services, but, of course, the Activity has paused so it cannot do that.
I don't particularly want to prevent the screen from blanking in the Manifest (and thus the Activity would never pause). Though I believe it would still pause if, say, a phone call is received etc.
My solution would be to start an IntentService in one of the Activity pausing events (either onPause, onStop or onSaveInstanceState) to receive Location updates, and then when the Activity restarts, collect the data from the Service and close the Service down.
Would this be an efficient and correct way of achieving this, or is there some Android black art that I don't know about? If so, is IntentService the correct way to go about it (or should I use Service)?
Proberly a normal service that gets restarted by an alarmmanager is an better idea.
In order to tie up loose ends, I'll add my own answer to this now I have implemented something.
My solution in the end was not an IntentService. This was because I thought that the IntentService would consider its work to be the actual setting up of the LocationService and once that work had been completed then it would shut itself down rather than hang about waiting for LocationService 'pings'.
Therefore, I implemented a normal Service, but I bound it to the calling Activity. I also set up a callback to the Activity. This way when a 'ping' was received I could process it and pass back the data directly to the Activity. Also, the Service would remain alive as long as the binding was in place. I clear the binder when the Activity is destroyed.
This worked perfectly....HOWEVER
I then discovered that the reason that the LocationService 'pings' were not being handled in the Activity was bacause I was disconnecting the GoogleAPIClient when the Activity onStop was called. Having removed this, the Activity processed the 'pings'even in its stopped state, so no Service was required anyway.
Therefore the correct answer to this question is... Activity should continue processing in the background (unless it's destroyed for memory management purposes), so check you're not stopping stuff in your 'shutdown' handlers onPause onStop etc. Then you won't waste time writing services like I did!
Stackoveflow!
I have an application with sticky background service and visible part, consisted of several activities.
I need to track start and stop of visible part (all activities).
For example:
When user starts MainActivity, Service receives LocalBroadcast that tells it to start something.
When user rotates screen, Service must not receive anything.
When user goes to SecondActivity, Service again must not receive anything.
When user closes ALL ACTIVITIES, Service gets LocalBroadcast telling it to stop something.
If I use Activity. onCreate and onDestroy, or onStart and onStop, I get events related to lifecycle of single activity. Also I get events related to screen rotation.
I also cannot use Application. onCreate or onTerminate, as they will not trigger because of service running in the background.
I need to track real start and stop of entire application except service.
See: http://developer.android.com/guide/components/bound-services.html
When the last client unbinds from the service, the system destroys
the service (unless the service was also started by startService()).
So each Activity should bind() to the service, in onCreate, and unbind() in onStop/onDestroy
Now to fix the problem with the orientation changes, you can check for isFinishing in the onStop/onDestory callback
(see: How to distinguish between orientation change and leaving application android)
and also put some flag in onSaveInstanceState callback, so that in the following onCreate you can check for the existence of that flag, and act accordingly (refresh the binding, or avoid calling bind() again)
Can I safely stop a Service in my main Activity's onDestroy method? I know that onDestroy is not guaranteed to be called, but I also do want to keep my Service running until the app is destroyed.
I'm thinking that maybe in all situations where the activity is destroyed, the service would also be destroyed?
You can stop a service in the onDestroy of an activity, but to do it successfully requires either:
Running a Service in the Foreground
A foreground service is a service that's considered to be something
the user is actively aware of and thus not a candidate for the system
to kill when low on memory. A foreground service must provide a
notification for the status bar, which is placed under the "Ongoing"
heading, which means that the notification cannot be dismissed unless
the service is either stopped or removed from the foreground.
For example, a music player that plays music from a service should be
set to run in the foreground, because the user is explicitly aware of
its operation. The notification in the status bar might indicate the
current song and allow the user to launch an activity to interact with
the music player.
or Managing Bound Services
A bound service is the server in a client-server interface. A bound service allows components (such as activities) to bind to the service, send requests, receive responses, and even perform interprocess communication (IPC). A bound service typically lives only while it serves another application component and does not run in the background indefinitely
In all your activities, manage any resources you have created within that activity and with a null check, close them down. Like you have in your service class. If you want to override the parent onDestroy, place your custom code before super.onDestroy.
There's more detail about this here.
but I also do want to keep my Service running until the app is destroyed.
The activity can remain on the stack in the stopped state and will not be destroyed until more memory is needed. This means that there is no fixed time that the service will continue to run until the activity is destroyed.
Activity Lifecycle
If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
The entire lifetime of an activity happens between the first call to onCreate(Bundle) through to a single final call to onDestroy(). An activity will do all setup of "global" state in onCreate(), and release all remaining resources in onDestroy(). For example, if it has a thread running in the background to download data from the network, it may create that thread in onCreate() and then stop the thread in onDestroy().
To ensure that all your resources are cleaned up, you could either call finish() on the activity, or end the service in the onStop() method or use a timer in the onStop(), that will end the service or destroy the activity after x time.
The problem with calling finish() is that if the use navigates back to the activity quickly, it needs to be recreated. The problem with using stop() is if the activity is restarted the service will need to be restarted. So a timer could be a way to keep the activities natural state preserved to allow user navigation, but it would need to be stopped if the activity resumes in onResume().
For protected void onDestroy ()
Perform any final cleanup before an activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.
Yes it is safe to do it in onDestroy. Because before killing your activity background service or forground service that is bound to component will get killed by system as priority for service running in background is lesser then component you are interacting with.
Suppose that Activity A starts Service S and binds to Service S.
What will happen to S when A is destroyed?
How can I recreate another Activity that binds to S? The sample code in http://developer.android.com/guide/components/bound-services.html unbind the service in onStop(). I think if I open the app again, a new process is created for another instance of A and S. But I want the new activity to get data from the old service.
What will happen to S when A is destroyed?
If A is the only Activity bound to S and you didn't start the Service via startService(Intent), S will be destroyed. That's because a Service will be alive till the last bound Activity unbounds from the Service. This is documented here.
How can I recreate another Activity that binds to S?
If A is bound and you switch to Activity B via Intent, the Service will be destroyed and recreated when B binds to it.
If you want the Service to be alive even if no Activity is bound to it, you have to call the Servie with startService(Intent). Now it will be around if you explicitly stop it or system means it's time to destroy it. If you don't want this behavior, persist your data and access it at given time.
I think if I open the app again, a new process is created for another instance of A and S
The process remains the same till the process is killed from the system or if you kill the process, which is not recommanded.
Edit:
Only the bound service lifecycle depends on Activities. If you want a stand alone one use startService(). This way it's independent from Activities and runs in background as long as the process of the App is up or you explicitly stop the Service with stopService() / stopSelf(). You could even have a Service in a own App and use IPC to communicate between Apps. It's all a matter of the use case.
As you can see the configuration of a Service is very flexible and you have to decide which fits best for your App.
If You start service through startService() it will keep remaining after Activity finishes.
If You start service through bindService() it will live until last Activity unbounds from it.
Also if service is already started and you call startService() no new instance of service will be created, but in living service method onStartCommand() will be executed.
Almost same when you bind to living service, methon onBind() will be executed.
I want to know what is the best place in an Activity to bind to a service?
I saw examples doing it in onResume() and also in onCreate(). I was asking myself if it is not a problem putting it into onCreate(), because in onPause() I will do a unbind to the service, so I don't get a serviceConnectionLeak, if I leave the activity. Now if I press the Home Button and then switch to the Home Screen, the Activity will unbind from the service, when I go back to the Activity from the Task Manager, then onCreate() will not be called and if the code is trying to access a function from the service I will get a NullPointerException. If I bind and unbind only in onResume() and onPause() I don't have this problem. Am i right?
I would generally recommend doing this in either onCreate()/onDestroy() or onStart()/onStop(), depending on the semantics that you want:
If your Activity wants to be interacting with the Service the entire time it is running (for example maybe it can retrieve some data from a network for you and will return the data when ready and you want to allow this to happen while in the background so if the user returns you will have the data ready), then onCreate()/onDestroy() is probably appropriate. Note that the semantics here is that the entire time your Activity is running it needs the Service, so if this Service is running in another process then you have increased the weight of it and made it more likely for it to be killed while in the background.
If your Activity is only interested in working with the Service while visible, then onStart()/onStop() is appropriate. This means your Activity will unbind from the Service when the user leaves it (and it is no longer visible) and connect back up the next time the return and it is re-started and resumed.
I generally wouldn't recommend doing bind/unbind in onResume() and onPause(). These generally won't decrease significantly the amount you use the Service (and thus your overhead), and in fact, because a pause and resume happens at every activity transition, this is a code path you want to keep as lightweight as possible. Doing it here can have other unexpected negative consequences: for example if multiple Activitys in your app bind to the same Service, when there is a transition between two of those activities the Service may also get destroyed and recreated as the current Activity is paused before the next one is resumed.
Also these pairs (onCreate()/onDestroy(), onStart()/onStop(), onPause()/onResume()) are intended to be the proper pairs for acquiring and then releasing resources (such as binding to Services, registering receivers, etc) to ensure that they are correctly acquired prior to being needed and released (and not leaked) when no longer needed.
What you say is correct. In most cases you will want to register in onResume() and unregister in onPause(). If you use onCreate() and on onDestroy() you will still be registering for updates when you are paused, which is being a bad citizen. If you register in onCreate() and unregister in onPause(), when you resume the task the registration will be gone, which is almost certainly not what you want.