Hi I have gone though activity lifecyle on many threads, but I could not find what we should do in onStart, onResume, onPause method of the activity.
In the onStart() method, you add code that's relevant at the beginning of the activity.
Let's say, you have an app that reads the temperature of the device's battery. You'll want to have an initial value, so as to show the user.
So in the onStart(), you'd add code that goes ahead and fetches the information you'd need, and displays it for the user, before your timer (for example) goes and reads the information a minute later.
The onPause() method is called before the application goes in to the background.
To stay with our example, in the onPause() method, you'd save the last recorded temperature to the device; so you can show a comparison when the user next opens the app.
The onResume() method is called when the application is brought back to the foreground (i.e.: you've gone to the task manager, and tapped on your app to show it again).
Again, staying with the going example; in the onResume() method, you'd go ahead, read your saved data, load fresh data, and show a comparison of the two in the application.
Then, when your timer ticks next, only fresh data will be shown.
Your question is a bit vague, so answer might not be super specific..
I would say there are no strict "rules" around what we should do in corresponding activity lifecycle methods.
In fact, you can do nothing there (just make sure you call super method if you decided to override those). I.e. your custom activity might not even override these methods - it will work just fine.
onStart, onResume and onPause methods are just hints to you about activity lifecycle change, so you can react accordingly, i.e. start/stop specific to your activity operations at the appropriate time.
For instance, when onResume is called it means that activity became fully visible to the user, so you might want to start some animation (if necessary)
Again, you are not obligated to put any code in there.
Usually most of the operations are performed within oncreate and onresume.
However for your info let me brief it out,
Onstart- this is called after Oncreate, once activity is visible to the user, if you want to perform some operations before the visibility do it in Oncreate, because most of codes should be operated before user views the activity.
OnResume-Be cautious on Onresume is it is quite tricky it will be called whenever you activity is brought to foreground.
Onpause-Called before Onresume, codes wont be executed here, so strictly avoid adding codes in Onpause instead add inside Onresume.
Hope it helps,
Related
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'm developing a videogame in Android. For it, I'm using a game loop and all the typical stuff it envolves. I have a doubt about the states of the activity in android.
I need an activity to create the GLSurfaceView and so, the problem is the activity, when it finishes its onCreate method, continues this way: onCreate -> onResume -> onStart -> onStop.
I guess it goes throught those states because the activity doesn't have anything to do and it's the loop who is working. But I have a problem with this behaviour:
How can I know when the user "minimize" or put the device in a stand by state? Again, the methods onStop -> onResume -> onStart will trigger, but, how can I difference this time with the first?
I need to stop the loop when the user switch the device to stand by, but not when it starts the first time.
I hope I have explained well. Thanks.
If onStop is running immediately after onStart, something is wrong. The activity will only be placed in the Stopped state only when it is no longer visible to the user. Unless maybe your code immediately creates another activity that displaces it as the foreground activity, I guess, but if the activity is visible on the screen, onStop shouldn't be firing. Some code would be helpful in diagnosing that.
onPause occurs when the activity is still visible but there is another activity that is being resumed. If you're trying to save game data or something when the user backs out of the app, gets a phone call, turns off the screen, etc., I'd use onPause, because onStop is not guaranteed to be called and you run the risk in certain situations of the system killing your activity before you can do what you need to do.
For more info on activity lifecycle, see the Activities guide.
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
I have two activities. One loads all rows from a database, and the other saves to the database. When I have the second save in onStop and the first repull the data in onResume, they do it out of order (the first resumes and then the second saves). I managed to fix this by putting the saving data in onPause, but why was this happening? Was this the cleanest way to do it?
Doing the save in the first actvity's onPause should be fine.
You've discovered that 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 on screen and is interacting with the user.
When you start the second activity, onPause is called on the first and then interactive control switches to the second, with onStop on the first to be called somewhat in background.
This improves responsiveness and gets the new activity in front of the user ASAP. Consequently, you should try to keep your onPause implementation as fast and efficient as possible.
See the following Android docs for more details on the lifecycle http://developer.android.com/guide/topics/fundamentals.html, but what you have found should work fine for you.
Some official quote as an add-on:
The Activity documentation states that
onPause() is where you deal with the user leaving your activity.
Most importantly, any changes made by the user should at this point be
committed
According to the "Application Fundamentals" article, section "component lifecycle", onResume() is always called when a View becomes active, independent of the previous state.
In the Notepad tutorial, Exercise 3, I have found something confusing in NoteEdit.java:
There is a call to populateFields() in onCreate() as well as in onResume().
Wouldn't it be enough (or even better) to have it only in onResume() ?
In such a small example, it will not do any harm if populateFields() is performed twice, but in a bigger App, things can be different ...
Thanks and Regards,
Markus N.
From a look at Notepad3, I would say you are correct. There doesn't seem to be any reason for them to call populateFields() in both onCreate() and onResume(). onResume is sufficient.
I can see where you need it in both places, if application pauses then you would need it in onResume and if your process gets killed or user navigates back to activity then you will need it in onCreate especially if you are doing some pre-processing.
Per the documentation....for onResume() they recommend using it for lightweight calls unlike in onCreate():
"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. "
The Notepad app may want a variable declared if the method was already hit by onCreate not to redo in onResume().