If you follow the link https://developer.android.com/reference/androidx/lifecycle/Lifecycle.State.html#CREATED
you'd see that CREATED event is raised in two conditions
1) after onCreate (understandable )
2) right before onStop(wait what ?)
why would the lifecycle raise the CREATED event just before onStop ?
First of all, CREATED is not an event but an activity state. The given doc means after onCreate() called, activity is in CREATED (then became RESUMED after onResume() called). When the activity onStop() called, activity became CREATED again (CREATED but not RESUMED in this case).
Be careful, you're confusing states with events!
State (Enum values) :CREATED, DESTROYED, INITIALIZED, RESUMED, STARTED
also check this : https://developer.android.com/guide/components/activities/state-changes
"When a configuration change occurs, the activity is destroyed and recreated. The original activity instance will have the onPause(), onStop(), and onDestroy() callbacks triggered. A new instance of the activity will be created and have the onCreate(), onStart(), and onResume() callbacks triggered."
So given the possible states, CREATED is the one that fit best when onStop is called
Related
Is this safe to assume that when onResume is called all of the member variables native or objects in the activity are still valid ?
In otherwords is it possible that android cleans up any member of an activity under memory stress conditions and then ends up calling onResume ?
When onResume is called anything that was previously set in onCreate, onStart, etc will be there. However if the Activity is deleted due to memory pressure you may have to recreate old values in either onRestoreInstanceState or onCreate, either of which will be called again before onResume is.
I dont think the activity lifecycle guarantees the state will remain on calling onResume. The documentation states that you should reinitialise all components in onPause
https://developer.android.com/training/basics/activity-lifecycle/pausing.html#Resume
An excerpt from the above link:
When the user resumes your activity from the Paused state, the system calls the onResume() method.
Be aware that the system calls this method every time your activity comes into the foreground, including when it's created for the first time
As such, you should implement onResume() to initialize components that you release during onPause() and perform any other initializations that must occur each time the activity enters the Resumed state (such as begin animations and initialize components only used while the activity has user focus).
I have tried to research exactly when the onDestroy method is called for an activity, but I've read some confusing and conflicting information. In general, my question is: under what circumstances is the onDestroy method actually called on an activity? More specifically, if I have two activities, activity A and activity B, if activity A is running and I create an intent and switch to activity B, is activity A only stopped, or is it destroyed?
Like stated in the official documentation:
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.
In your example the Activity A is stopped and could be destroyed by the System
Note per documentation link above:
…do not count on [onDestroy()] being called as a place for saving data … [see] either onPause() or onSaveInstanceState(Bundle).
onDestroy() is called whenever:
The user takes out the activity from the "recent apps" screen.
The user takes out the activity from the "recent apps" screen.
onStop() is called whenever:
The user leaves the current activity.
So in your example, when the user launches Activity B, Activity A called onStop().
EDIT:
The onDestroy() method is not always being called, according to the documentation. onStop() is always called beginning with Honeycomb, so move code you explicitly need to do before the activity stops to there.
Starting with Honeycomb, an application is not in the killable state until its onStop() has returned.
https://developer.android.com/reference/android/app/Activity#ActivityLifecycle
Hope this helped :D
Please, help me understand activity lyfecycle more deeply. http://developer.android.com/guide/components/activities.html#ImplementingLifecycleCallbacks
They say:
The foreground lifetime of an activity happens between the call to
onResume() and the call to onPause().
Does this mean, that activity becomes resumed in some moment after onResume() is called, or after onResume() completely finished it's work?
Similar question about visible state and onStart.
And if the second is right (method completely finished it's work), then super.method() or overriden by me in activity class?
#Override
protected void onResume() {
super.onResume();
// is it now "resumed" after super.onResume()?
}
"The foreground lifetime of an activity" referes to the time it is directly being shown to the user. It also implies at the moment its process has maximun priority on the Android process priority ladder. You should read this http://developer.android.com/guide/components/processes-and-threads.html
Furthermore, onResume(), onPause()... are just hooks where you should insert code that needs to be executed on that specific moment of the activity lifcycle.
The foreground lifetime of an activity happens between the call to onResume() and the call to onPause().
Does this mean, that activity becomes resumed in some moment after onResume() is called, or after onResume() completely finished it's work?
Technically speaking, the Activity is in a state of being resumed before onResume() is called but the option for you to override the onResume() method allows you to fine-tune what needs to be done before the Activity enters the 'running' state. In other words, from the point of view of the OS, the Activity is resumed, then onResume() is called and, finally, from the point of view of your own individual app, resuming the Activity is complete when onResume() is complete and the Activity is running.
Similar question about visible state and onStart. And if the second is right (method completely finished it's work), then super.method() or overriden by me in activity class?
Again, the same logic applies - the OS goes through what it needs to do to start the Activity then calls onStart() for you to customise the starting stage of your Activity. The OS considers the Activity to have started before it calls onStart() but from your app's perspective, it hasn't completely become started until any code you have in your overridden onStart() method.
I looked on another thread on stack overflow (src: Difference between onCreate() and onStart()?)
That thread described the onStart() method as "Called when the activity is becoming visible to the user". However in that same answer and in many overrides of the oncreate method, i see setContentView called in onCreate. Wont that make the screen visible then? Therefore in that situation(where setContentView is called in onCreate), is onStart() called after the screen becomes visible to the user but before the user can interact with it?
The chances of onStart() can be called multiple times.
onCreate() : Called when the activity is first created.
onStart() : Called when the activity is becoming visible to the user.
Now look into the graph given to Difference between onCreate() and onStart()? post. onStart() can be called multiple times, in case if process is not killed (if activity has been called again.)
So if you set view at onStart(), you will need to initialize view into onStart() or later (i.e. onResume() ). This will be a repetitive process. Is not it a bad practice to initialize view again and again?
Hope I am clear here.
onCreate called when activity is first created.
onStart called when activity is becoming visible to the user.
and also
onResume called when activity will start interacting with the user.
onPause called when activity is not visible to the user.
onStop called when activity is no longer visible to the user.
onRestart called after your activity is stopped, prior to start.
onDestroy called before the activity is destroyed.
For difference between onCreate and onStart see this link
I have noticed that the onDestroy() method of a fragment gets called multiple times - why would this be? I would expect only 1 call.
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.
It's normal for an Activity or Fragment to get onDestroy()-ed multiple times. For example, when you change the device orientation, the current Activity goes through onDestroy() and then a new instance of the same Activity goes through onCreate(), now in the new orientation.
You might be confusing this for finish(), which gets called when the Activity gets "killed" per se and happens only once when you navigate away from it.