During my testing, I have not found a situation where onStart() runs without onResume().
If someone could shed light on this topic as this is the closest question I've found, but none of the answers address the start/resume part just the stop/pause part.
If there is no relevant situation, is it ok to omit onStart() or onResume() and not use both as that seems redundant?
There's documentation on it.
The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods you can maintain resources that are needed to show the activity to the user. For example, you can register a BroadcastReceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user no longer sees what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity becomes visible and hidden to the user.
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time the activity is in front of all other activities and interacting with the user. An activity can frequently go between the resumed and paused states -- for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered -- so the code in these methods should be fairly lightweight.
As I understand it, onStart() and onStop() represent visibility, while onResume() and onPause() represent priority.
For example, if you open your app, both onStart() and onResume() will be called. With your app still open, say you then get a Facebook Message and open the chat. onPause() will be called, but onStop() won't. Your app is no longer in the foreground, but it's still visible.
EDIT:
I know I linked the Activity documentation, but according to the Fragment documentation:
onStart() makes the fragment visible to the user (based on its containing activity being started).
onResume() makes the fragment begin interacting with the user (based on its containing activity being resumed).
onPause() fragment is no longer interacting with the user either because its activity is being paused or a fragment operation is modifying it in the activity.
onStop() fragment is no longer visible to the user either because its activity is being stopped or a fragment operation is modifying it in the activity.
The same principle applies. In most cases, it's just a direct call from the Activity.
Two examples off the top of my head:
1.) System dialog opens over your app (for example, via Intent.createChooser) but cancelling the dialog
2.) Multi-window mode, tapping on the other application then tapping on yours (you will receive onPause/onResume but not onStop/onStart)
In my experience, the only time you actually need onPause() is if you are writing your own camera.
If you're trying to show a DialogFragment after onPause, you generally need to wait until onResumeFragments/onPostResume.
Related
In Andoid Acitivity life cycle, why does an activity go through onPause() before going to onStopped()? Why can't the state go directly to onStopped()?
Paused and stopped are related but different states. From the point of view of the user, a paused activity cannot be interacted with, but may still be visible (e.g. if it has called a different Activity as a dialog). A stopped activity is guaranteed to be not visible at all (the uses is in another Activity or even a different app).
Of course, stopped implies paused, but the reverse is not the case.
From the official documentation.
If an activity in the foreground of the screen (at the top of the stack), it is active or running.
If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your
activity), it is paused. A paused activity is completely alive (it
maintains all state and member information and remains attached to the
window manager), but can be killed by the system in extreme low memory
situations.
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.
An even more detailed explanation is given in the Managing the Activity Lifecycle article in the Training section of the Android Developers site.
Refer to the documentation on Activities:
http://developer.android.com/reference/android/app/Activity.html
onPause()
"Called when the system is about to start resuming a previous activity. This is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, etc. Implementations of this method must be very quick because the next activity will not be resumed until this method returns.
Followed by either onResume() if the activity returns back to the front, or onStop() if it becomes invisible to the user."
Note: I would say "resuming another activity" instead of "resuming a previeous activity".
onStop()
"Called when the activity is no longer visible to the user, because another activity has been resumed and is covering this one. This may happen either because a new activity is being started, an existing one is being brought in front of this one, or this one is being destroyed.
Followed by either onRestart() if this activity is coming back to interact with the user, or onDestroy() if this activity is going away."
Because the documentation says so :-)
And it makes sense. The app is open and the user pressed the home button: onPause() gets called. After a while the system needs the memory and closes the app: onStop() gets called.
Because, onPaused() is executed when your App is rotated or a Dialog is open.
onStop() when your App is not in the screen, so is necesary that this two points in the lifecycle to the user or programmer can identify what action is executed.
I try to make Notification which must work only when Application UI isn't visible.
I tried to store preference which was written in onStart() and onStop() of my Activity. But sometimes, it's not working because another application became visible without MyActivity.onStop() being called.
What other method I can use for a Service to determine, if MyApplication is visible now? Or, maybe MyActivity?
If you already have code to keep track of the state of your app's UI, you can probably get it to work simply by putting the code in onPause() and onResume(), instead of onStart() and onStop().
It is possible for the UI not to be visible, or partially hidden, even before onStop() gets called ... as you found out.
Take a look at the Android Activity lifecycle diagram here:
http://developer.android.com/images/activity_lifecycle.png
and note the description:
The foreground lifetime of an activity happens between a call to
onResume() until a corresponding call to onPause(). During this time
the activity is in front of all other activities and interacting with
the user. An activity can frequently go between the resumed and paused
states -- for example when the device goes to sleep, when an activity
result is delivered, when a new intent is delivered -- so the code in
these methods should be fairly lightweight.
Read more about this in another question here.
This may be a bit of a stupid question but when is the best part of the Android life cycle to implement each step? The flow of my game is as follows:
Before onCreate: Data that is stored in a JSON file is parsed into String Lists when the game starts
onCreate: Basic UI is generated
onStart/onResume: Game starts: item selected at random from the lists, user selects corresponding item to proceed
If the user is correct, another item is selected from the lists. Occurs 10 times
After 10 items, game ends and score is displayed to user
Would this be considered good practice? I'm a bit confused about the life cycle steps
This might help with understanding the lifecycle of an Android app more. The following is quoted from that site:
As mentioned in the previous section, the lifecycle of an activity has 4 states and 3
lifetime periods. If you want to monitor and adding your own code
logics to an activity, you can use the following 7 basic callback
methods provided by the android.app.Activity class:
onCreate() - Called when the activity is first created. This is where
you should do all of your normal static set up: create views, bind
data to lists, etc. This method also provides you with a Bundle
containing the activity's previously frozen state, if there was one.
onCreate() is always followed by onStart().
onRestart() - Called after
your activity has been stopped and prior to it being started again.
onRestart() is always followed by onStart().
onStart() - Called when
the activity is becoming visible to the user. onStart() is followed by
onResume() if the activity comes to the foreground, or onStop() if it
becomes hidden.
onResume() - Called when the activity will start
interacting with the user. At this point your activity is at the top
of the activity stack, with user input going to it. onResume() is
always followed by onPause().
onPause() - Called when the system is
about to start resuming a previous activity. This is typically used to
commit unsaved changes to persistent data, stop animations and other
things that may be consuming CPU, etc. Implementations of this method
must be very quick because the next activity will not be resumed until
this method returns. onPause() is followed by either onResume() if the
activity returns back to the front, or onStop() if it becomes
invisible to the user.
onStop() - Called when the activity is no
longer visible to the user, because another activity has been resumed
and is covering this one. This may happen either because a new
activity is being started, an existing one is being brought in front
of this one, or this one is being destroyed. onStop() is followed by
either onRestart() if this activity is coming back to interact with
the user, or onDestroy() if this activity is going away.
onDestroy() -
The final call you receive before your 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.
How are you pre-loading data before onCreate? You got no Context object to work with app filesystem before your onCreate called. Here is documentation for Activity lifecycle, as you can see, onCreate is the first method where you can run your code.
I suggest to put data loading in other thread, for example AsyncTask.
So:
Generate basic UI
Start data pre-loading NOT IN MAIN THREAD
Update UI after data loaded
I've read several posts that describe the difference between onStart() and onResume(): onStart() is called when the activity becomes visible, onResume() is called when the activity is ready for interaction from the user. fine.
I've always just added code to onPause() and onResume(), and never bothered with onStart() and onStop().
Can anyone give some concrete examples of what you might do in onStart(), vs. onResume()? Same goes for onStop() and onPause(), how is onStop() useful? I must be missing something fundamental here.
onStop() will (for example) be called when you leave the activity for some other activity (edit: almost. see commonswares comment about dialog themed activities).
For example if you use startActivity() in activity A to start activity B. When you press back in activity B you will return to activity A and onStart will be called.
This differs from some of the reasons onPause might be called without onStop being called. If for example the screen times out or you press the standy button onPause will be called, but probably not onStop (depending on memory available and whatnot), so it is a "lighter pause". onStop will be probably be called eventually even in this case, but not immediately.
Ok, but what's the use
Often there is no specific use, but there might be. Since your activities will keep its memory state on the stack even after you start some other activity, that stack will increase with the number of activities started (height of the stack).
This can lead to large memory usage in some applications. After a while the framework will kick in and kill some activities on the stack, but this is rather blunt and will probably mean a lot of states to be retained when returning.
So an example use for onStart/onStop is if you want to release some state when leaving an activity for another and recreate it when you get back.
I have used it to set listadapters to null, empty image caches and similar (in very specific applications). If you want to free the memory used by visible views in a listadapter you can recreate it in onstart and let the views be picked up by the gc. This will increase the likelyhood that the rest of the memory state of the activity will live on.
Some resources can be deemed good enough to save while the activity instance is alive and some only when it is on the front of the stack. It is up to you to decide what is best in your application and the granularity of create/start/resume gives you that.
onStart() works after onCreate() ended its task.
It's a good place to put a broadcastReceiver or initialize some state about the UI that should display consistently anytime the user comes back to this activity.
onResume() works when you come back to your Intent or Activity by pressing the back button. So onPause will be called every time a different activity comes to the foreground.
i think that your question is pretty explained here on the doc : read about the Activity Life Cycle
Looking at the Activity Life Cycle diagram, I notice that onPause() and onStop() can both lead to the "process" being killed. This would require onCreate() to be called when the user wants to resume their application. The point being that onStop() is not necessarily called, nor is onDestroy(), but that onPause() may be the only event that the Activity may see. This being the case, onPause() must handle saving the application status so that the user can return back to it later, regardless of whether onStop() is called or not.
I can see onDestroy() being used to clean up Activity specific resources that would naturally be eliminated in a process kill action. Is there anything else that onDestroy() would be good for?
And what would onStop() be good for? Why would I want to override it for?
If I got your question right: It depends what you want to do with your application. Let's say you are programming application that uses GPS. In the onStop() which is called when the activity is no longer visible to the user, you can remove these requests. Or you can stop the some service if your application is running any. Or you can save preferences (not recommended, do it in onPause() instead), or you can close permanent connection to a server.....If I think of anything else, I'll add more...
If you have read the doc further, you'll see following:
Saving activity state
The introduction to Managing the Activity Lifecycle briefly mentions
that when an activity is paused or stopped, the state of the activity
is retained. This is true because the Activity object is still held in
memory when it is paused or stopped—all information about its members
and current state is still alive. Thus, any changes the user made
within the activity are retained in memory, so that when the activity
returns to the foreground (when it "resumes"), those changes are still
there.
However, when the system destroys an activity in order to recover
memory, the Activity object is destroyed, so the system cannot simply
resume it with its state intact. Instead, the system must recreate the
Activity object if the user navigates back to it. Yet, the user is
unaware that the system destroyed the activity and recreated it and,
thus, probably expects the activity to be exactly as it was. In this
situation, you can ensure that important information about the
activity state is preserved by implementing an additional callback
method that allows you to save information about the state of your
activity and then restore it when the the system recreates the
activity.
Summary: After completing onStop() Activity object is still alive in memory. And this will help the system to restore the activity.
Very basic example: consider you are showing your activity to user, and suddenly your friend calls you! Rest you can understand..
So now it it up to you that, which are the resources/objects/connections should be released on which event.
Another example would be to register and unregister a broadcast receiver.
Note that usually these things are placed in onResume and onPause, the difference is subtle though, onResume/onPause are called when the activity gets placed behind another activity, onStart/onStop are called when the activity is no longer visible in the screen.