I am porting an iOS App to Android, and am having a little difficulty with the terminally.
I want the App to sync when starting/coming to the foreground (i.e. the user selects the App) and when the App goes to the background (e.g. when going to the main screen and start using another App.)
Is there an easy way to do that in Android?
I added onResume() and onPause() to my Activities, but this will be triggered when the activity resumes or pauses, not when the App as a whole pauses (and results in a lot of sync each time the user does something).
Update:
The Sync operation is a Service which is called when the App needs to get new/updated information from the server. As such, this needs to be done when the Application is started/resumed by the suer (after inactivity for some time) and it needs to do this when the user actively stops using the Application.
when an activity goes to background,
onPause() -> onStop()
methods will be executed in sequence, if activity is partially visible, only onPause(), if activity is completely invisible by another activity, onStop() method will be executed after onPause().
onDestroy()
method will be executed if you either called finish() or when there is no enough memory in the system and system destroys it. You can't rely onDestroy() method unless you call finish() method.
It's best to use onStop() method to save your data.
nr4bt has a valid point and depending on your required functionality, a good option.
A global approach would be to start a Service when your application starts.
Make this Service responsable for your syncing operations with suitable callbacks to your active Activity.
Make this Service aware of your alive/paused/stopped Activity's. When the last one is finished -> Do your final sync and kill the Service
Related
I am working on a system that runs bluetooth/gps tasks as a foreground service.
At present if the app is minimised and opened again the UI state is retained,
However if the app is closed and it is opened from the service notification It returns to the correct activity but I do not have the same contents in textboxes/ same switch states etc.
Was planning to used sharedpreferences to retain this but was not sure which method to override when returning via notification?
According to: https://www.vogella.com/tutorials/AndroidLifeCycle/article.html
The onPause() method is typically used to stop framework listeners and UI updates. The onStop() method is used to save application data. These methods are guaranteed to be called before the activity is terminated.
If the user switches back to application which has been terminated by the system, it is restarted. Also its activity stack is recreated. The onResume() is used to register again listeners and to trigger UI updates based on the saved data.
Expected more to this, will update answer if I find any issues.
I need to set a background task when the app is in background.I am setting notification from the app itself.So,when the app is closed,app need to receive
notification.
You can start your background task from onPause or ononStop.
Take a look at this link from the docs. It says
When the system calls onPause() for your activity, it technically means your activity is still partially visible, but most often is an indication that the user is leaving the activity and it will soon enter the Stopped state.
When your activity receives a call to the onStop() method, it's no longer visible and should release almost all resources that aren't needed while the user is not using it. Once your activity is stopped, the system might destroy the instance if it needs to recover system memory. In extreme cases, the system might simply kill your app process without calling the activity's final onDestroy() callback, so it's important you use onStop() to release resources that might leak memory.
If I, for example, need to keep some very important data which the user can edit within my app, should I need to save them every time user changes such data or is it ok if I would save it within onPause(), onStop() or onDestroy() methods?
Can somehow application end without any of those methods calling? (For instance when battery runs out)
This certainly can't be done in onDestroy().
According to the documentation:
There are situations where the system will simply kill the activity's
hosting process without calling this method (or any others) in it, so
it should not be used to do things that are intended to remain around
after the process goes away.
So yes, the application can end without calling any of the lifecycle methods.
In that scenario when the phone is shutting down, you can use the ACTION_SHUTDOWN Intent.
More info here. For all other cases onPause should do the work. Even in the link provided, there is a statement that onPause will be called if the app is in FG.
Apps will not normally need to handle this, since the foreground
activity will be paused as well.
However, if it is not so expensive operation, I would go with saving data after edit.
As per the documentation of Android activity life cycle, onPause is called when an activity is going into the background, but has not (yet) been killed.
Hence, in most Android documentation, and sample codes you will find onPause is used for saving any persistent state the activity is editing, to present a "edit in place" model to the user and making sure nothing is lost if there are not enough resources.
So in your use case, all you need to do is implement onPause for your Activity and write a code to Save the activity state (EditText content or any other ongoing user interactions). Android system will save the activity state which you can always get back in onCreate of your Activity when android launch your activity next time.
in this case please verify your phone activity via debug interface , some of phones are terminate your application this is force quit.
I create a new thread in an activity and I rely on onPause() to interrupt the thread. If my app crashes, or the Activity somehow ceases to exist, I want the thread to be killed.
Is Activity/Fragment.onPause() guaranteed to be called when an Activity is no longer running? If not, how can I guarantee the thread in question is killed?
If my app crashes
onPause() is not called here, but this shouldn't bother you as your entire app process ceases to exist, inclusive of all threads you have created (UI or otherwise).
Activity somehow ceases to exist
onPause() will be called whenever your Activity is moved to the background from the foreground, which is done in every conceivable way in which your Activity can be shut down, except for your app crashing. However, as I mentioned above, the app crashing will also by default kill your thread.
onPause() is essentially called whenever your Activity is no longer in the foreground. Your Activity may still be alive and in memory after onPause() has been called, but there is no scenario which I can think of in which your Activity is alive and in the background without onPause() being called.
Yes , onPause() will be called when an activity is no longer running. Suppose an activity is closed then the sequence of events will be onPause() -> onStop() -> onDestroy(). Even if your activity slips into the background when another activity starts or when the screen switches off, onPause() is always called even if the other two methods aren't called. So even if activity ceases, onPause() will be called and your thread will be killed.
But when your app crashes, along with your entire activity, even the thread that you have started will be taken care of by Android by finishing it all.
Suppose you have two activities A and B. You navigate from A to B. Activity A goes to background ie activity A is paused. Activity B takes focus ie foreground. When you click back button activity B is popped from back stack and activity A takes focus ie activity A resumes.
When you display a dialog in activity the activity in paused and dialog is displayed on click of back button dialog is dismissed and activity resumes (foreground).
When activity is no longer running it is in background so it is paused. I agree with Raghav Sood to what happens when app crashes.
You should usually use the onPause() callback to:
Stop animations or other ongoing actions that could consume CPU.
Commit unsaved changes, but only if users expect such changes to be permanently saved when they leave (such as a draft email).
Release system resources, such as broadcast receivers, handles to sensors (like GPS), or any resources that may affect battery life while your activity is paused and the user does not need them.
Note :
Multiple tasks can be held in the background at once. However, if the user is running many background tasks at the same time, the system might begin destroying background activities in order to recover memory, causing the activity states to be lost.
In addition to the accepted answer, which helped me here, I would like to add that there exists a way to basically, catch any error or crash that happens. This allows you to do things before the app exits. For example, you can save the whole logs, in order to send it later to a remote server for debug.
This means you can also probably do other some kind of light computational things if you really needs to (properly closing active connexions, etc etc).
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.