I'm trying to understand the difference between onPause and onStop.
I've read all the different forums but I still am not clear about the difference. I've created a simple app to try and test when which method gets called. For that I've simply placed loggers in each method.
From my trials -
I've only seen either both methods being called in quick succession or neither getting called at all. I'm trying to find scenarios where onPause gets called but onStop doesn't.
The purpose is to understand whether defining onPause is even required. If the scenarios in which only onPause gets called are so rare, it doesn't even make sense to write separate code for onPause. Shouldn't writing onStop be sufficient?
public class LifecycleActivity extends ActionBarActivity {
@Override
protected void onDestroy() {
super.onDestroy();
Log.d("Rachit", "In Destroy Method");
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_lifecycle);
Log.d("Rachit", "In Create Method");
}
@Override
protected void onStart() {
super.onStart();
Log.d("Rachit", "In Start Method");
}
@Override
protected void onResume() {
super.onResume();
Log.d("Rachit", "In Resume Method");
}
@Override
protected void onPause() {
super.onPause();
Log.d("Rachit", "In Pause Method");
}
@Override
protected void onRestart() {
super.onRestart();
Log.d("Rachit", "In Restart Method");
}
@Override
protected void onStop() {
super.onStop();
Log.d("Rachit", "In Stop Method");
}
}
onPause() is always called. This is guaranteed. If you need to save any state in your activity you need to save it in onPause() . onStop() may be called after onPause() , or it may not.
The onStop method is called only when the activity is not completely visible, whereas the onPause method is called when the activity is still visible but has remained in the background.
onPause. Called when the Activity is still partially visible, but the user is probably navigating away from your Activity entirely (in which case onStop will be called next). For example, when the user taps the Home button, the system calls onPause and onStop in quick succession on your Activity .
OnStop is called when FirstActivity calls SecondActivity and FirstActivity looses visibility. If Second Activity has a transparent background then the FirstActivity will be visible underneath, so not loosing visibility and onStop on FirstActivity will never be called.
I figured this out a while later, but forgot to post my answer here.
The instance where I noticed that onPause() was called, without an immediate subsequent call to onStop() was when I got a notification from a different application when a different app was open on my phone.
For example, say you have Facebook running on your phone currently. If you receive a notification from WhatsApp (in the pop-up dialog box), your Facebook activity will be paused. If you close the WhatsApp pop-up during this time, the Facebook Activity will get Resumed. On the other hand, if you open WhatsApp from the pop-up message, your Facebook Activity will be stopped.
This scenario occurs when you start a DialogActivity
from your current activity, then the onPause()
of current activity is called and after coming on current Activity
the onResume()
is called.
For more information, please see Developer Docs.
Activity A --> Activity B If B is transparent, A' onPause will be called but no onStop.
The official Android Developers page you can see all the information relating to these two states of activity
onPause() (http://developer.android.com/training/basics/activity-lifecycle/pausing.html)
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. 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.
Generally, you should not use onPause() to store user changes (such as personal information entered into a form) to permanent storage. The only time you should persist user changes to permanent storage within onPause() is when you're certain users expect the changes to be auto-saved (such as when drafting an email). However, you should avoid performing CPU-intensive work during onPause(), such as writing to a database, because it can slow the visible transition to the next activity (you should instead perform heavy-load shutdown operations during onStop()).
You should keep the amount of operations done in the onPause() method relatively simple in order to allow for a speedy transition to the user's next destination if your activity is actually being stopped.
Note: When your activity is paused, the Activity instance is kept resident in memory and is recalled when the activity resumes. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state.
onStop() (http://developer.android.com/training/basics/activity-lifecycle/stopping.html)
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.
Although the onPause() method is called before onStop(), you should use onStop() to perform larger, more CPU intensive shut-down operations, such as writing information to a database.
When your activity is stopped, the Activity object is kept resident in memory and is recalled when the activity resumes. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state. The system also keeps track of the current state for each View in the layout, so if the user entered text into an EditText widget, that content is retained so you don't need to save and restore it.
Note: Even if the system destroys your activity while it's stopped, it still retains the state of the View objects (such as text in an EditText) in a Bundle (a blob of key-value pairs) and restores them if the user navigates back to the same instance of the activity (the next lesson talks more about using a Bundle to save other state data in case your activity is destroyed and recreated).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With