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
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.
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,
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.
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
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().