A lot of threads ask the question how to run code or get the visibility of the fragment.
But I would like to know "why" the Fragments: onResume() and onStart() are 'not' visible to the user, although the documents state it should be visible to the user.
From: http://developer.android.com/reference/android/app/Fragment.html#Lifecycle
onStart() makes the fragment visible to the user (based on its containing activity being started).
onResume() makes the fragment interacting with the user (based on its containing activity being resumed).
http://developer.android.com/reference/android/app/Fragment.html#onResume()
and onStart() for that matter, clearly describe:
Called when the fragment is visible to the user and actively running. This is generally tied to Activity.onResume of the containing Activity's lifecycle.
While I clearly see no fragment, till after onResume has completed. Soo the question remains: 'why' is the fragment only 'visible' after onResume. and not from onStart as per doc?
Oh and the expand on this: I use no ViewPager.. Just a simple Activity-Fragment model.
Hope anyone has some intel on this...
[UPDATE*] I have added a sample project with one activity and one fragment showing the issue. For anyone to try ;-)
https://www.dropbox.com/s/08noqvmq7sjwppb/fragmentUserVisibilityTest.zip
Perhaps, you have a long running operation in your onStart() which happens in the main thread. In this case you won't see anything until this operation ends. Which happens by the time onResume is called. Consider using AsyncTask for long operations.
onStart() gets called when a fragment is about to be shown, onResume() is called when a fragment is about to be interactible. That's the same as for an Activity.
onStart() and onResume() would have been of no use, if they had been called after a fragment becomes visible/interactible.
Related
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.
Is it necessary to initialize all the views of activity in onCreate() only. Can you tell me best initializations of views of activity.
Thanks
No need to initialize any view if you do not modify it.
you can initialize in any Activity lifecycle as your wish(before accessing).
But is is said as best practice to initialize it in onCreate().
Why:
if you see the lifecycle OnCreate is called when you app page is not shown. Like onStart called when app is partially visible & onResume is called when it is fully visible. So, mostly we want everything ready before seeing it. So that is one reason.
Another is findViewById is bit more expensive. So, we don't want to see that when app is visible.
OnStart & onResume may call multiple time when you go another page. So, it's preferable to initialize everything only once , than multiple time.
So, choice is yours now.
OnCreate() : This method is called once when activity is to be created. That is why all the gobal and static content should go there. Example - This may include your shared preferences, databases initialisations.
OnStart() : This method is called when you see your activity over screen. It is foreground method. OnStart() ends with OnStop(). Example : Let us assume A and B activity, A activity has been created and currently in onStart() method is being called. When one switches to B activity then A's OnStop() method will be called and B activity will be created. Thus OnStart() and OnStop() methods are called when you switches onto activities.
So according to your question initialisation is done once so it should be done in OnCreate() method if it is done in OnStart() then initialisation will takes place every time when you switch between activities.
Source : Difference between onCreate() and onStart()?
Please take a look over here this will clear your all faults regarding life cycle Activity | Android Developer
I have seen one of the tutorial on Firebase android in which they have initialized the view (UI) elements in OnStart() method of activity instead of OnCreate() method.
I know that the 'OnCreate()' method gets called once and 'OnStart()' methods gets called multiple times when we switch between the activities. I did some study but still wanted to know the exact reason why Firebase tutorial did that way.
I want to know what will be the recommended approach to do so and why?
Thanks in advance!!
onCreate is 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. Always followed by onStart().
onStart is Called when the activity is becoming visible to the user. Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.
For Example Let us assume A and B activity, A activity has been created and currently in onStart() method is being called. When one switches to B activity then A's OnStop() method will be called and B activity will be created. Thus OnStart() OnStop() methods are called when you switches onto activities.
So according to your question initialization is done once so it should be done in OnCreate() method if it is done in OnStart() then initialization will takes place every time when you switch between activities.
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
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