I need to make sure that the options menu has been created before i run a certain code that accesses one of the menu items. Is there a callback for that or how can i implement one?
Is there any guaranties that the menu has been created on the activity's onResume()?
You cannot use onResume for this.
In fact this is the call order when your app is launched :
onResume()
onCreateOptionMenu
onPrepareOptionsMenu
As you can see onCreateOptionsMenu is called AFTER onResume
(you can verify this yourself by writing to the console in the overriden methods).
Also notice that onPrepareOptionsMenu is called at least once - when your app is starting, even though the menu is at that time not shown to the user.
Now, you do not write in great detail about what you are trying to do, but if what you want to do is this "run a certain code that accesses one of the menu items", then you can use onPrepareOptionsMenu as it is called AFTER onCreateOptionsMenu and it also called whenever your app comes to the foreground - i.e. after onResume. Depending on whether this code needs to run once or everytime you can use a boolean flag inside that method (or store it in the Preferences or similiar persistent data if it is only once ever).
There are no other callback hooks mentioned in the documentation and I have never had the need for others, as onPrepareOptionsMenu should be enough to do the job. If you feel this is not the case, you need to be more specific in your answer and provide code for your specific usecase.
But as I said before, no other callbacks are mentioned in the documentation.
It is not a callback for after onCreateOptionsMenu is done, but onPrepareOptionsMenu can be used if you want to modify the menu before it is displayed to make modifications. This would only be called after onCreateOptionsMenu (if Android is behaving, which is should).
http://developer.android.com/reference/android/app/Activity.html#onPrepareOptionsMenu(android.view.Menu)
See the Activity documentation on this:
http://developer.android.com/reference/android/app/Activity.html#onCreateOptionsMenu(android.view.Menu)
Related
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,
As you know like samsung, htc have a custom task manager menu like below. This menu can be popup up long press the home button. If my application is working in background and if i close it from Task Manager, i can not handle it.
Activity onDestroy method is not invoked.
Unfortunately there isn't a good answer for handling this situation. If the app is force-killed, onDestroy method isn't necessarily called. According to the documentation
Note: do not count on this method being called as a place for saving
data! For example, if an activity is editing data in a content
provider, those edits should be committed in either onPause() or
onSaveInstanceState(Bundle), not here.
If you can, clean up in the onPause() method. In order for the user to get to that screen to kill the app, it has to have been backgrounded and thus onPause() would be called. (see documentation)
It looks like you're in a similar situation as the question being asked in another SO thread - https://stackoverflow.com/a/3856300/413254
I have a ListView Activity that uses a AsyncTask to load data from the database. This Activity has an options menu that checks to see if there are any data items in the Activities ListView in onPrepareOptionsMenu().
If there are items, I enable one of the options that is shown on the ActionBar that allows the user to delete the items.
Now, when the Activity starts, the AsyncTask starts and as onPrepareOptionsMenu() is run through while the AsyncTask is still running, this menu item is never enabled, unless the device is flipped and the listview data gets passed in as an instance, bypassing the AsyncTask.
So, in the AsyncTask's onPostExecute(), I call invalidateOptionsMenu() but that does not seem to be the menu to refresh (I have debugging code in onCreateOptionsMenu() and onPrepareOptionsMenu(), and neither is fired). Any help appreciated.
You can try creating a global boolean like haveData on your Activity and upon onPostExecute(), set the boolean to true or false accordingly. Then based on the boolean do a check on your onPrepareOptionsMenu() and enable the menu item accordingly.
The last time i tried it worked for me not sure why it didn't for you. Do a debug from there if it doesn't work tell us where it isn't executing.
The issue was related to a bad global variable value. I was gatewaying the code inside the onPrepareOptionsMenu() method with a global boolean value that was never true, and had put the debugging statement INSIDE the boolean check... resulting in the debugging statement never running.
After addressing that issue, everything is working as expected, code above is correct.
I have finished the Layout exercise and wondering why they include the call to populateFields() in both onCreate and onResume.
According to Activity Lifecycle "onResume" will always be performed before the Activity is shown so why not just there?
I have real production code that populates fields and is only called in onResume and it works just fine.
I thought one reason would be that maybe onResume is called after the activity is shown, but a bit of googling digs this (mostly unrelated) thread:
http://groups.google.com/group/android-developers/browse_thread/thread/ddea4830bedf8c6c?pli=1
Quote: onResume() is thus the last thing that happens before the UI is shown
This is what Dianne Hackborn says so i guess we can trust her :)
Actually I have seen apps (in my app and also others), where fields were only populated in onCreate(), but not in onResume().
Lets call that app 'A'.
The effect was that when the user pressed the home button, went to a different app, and then returned to 'A', the screen stayed black, as 'A' was still in memory and thus the system did not bother to call onCreate(), but directly went into onResume().
So basically I'd say (and this seconds what #Torp wrote) populate the UI in onResume() and be done.
But then, this answer is slightly off-topic as it does not answer your "why" question.
You don't populate in onResume because it will be called every time the activity is shown.
You generally want to create as few objects as possible, so you create them once and for all in onCreate, and then you can always check that they are still updated in onResume.
I know Android's Activity model is a bit different from what I usually consider to be an "app".
I want to do something (in this case, check some notifications on a server and show them if available) when my app is "launched". What is a good way to accomplish this?
I likely don't want to do it in an activity's OnCreate, since each activity can be created any number of times - the code would get called more often than necessary.
The app also has multiple entry points - would I have to duplicate the check in each activity?
What I'm thinking of doing is setting up this code inside the Application object, along with a flag that tracks whether it's already been called - and just call it from each Activity's onCreate().
Is there a better or more "proper" way to do this?
The right, Android-approved way to do this is:
Create your own android.app.Application class
Override the onCreate method
In the AndroidManifest.xml, change the android:name attribute of the application element to the name of your class
Now, whenever your app is "started" (any one of your activites is started for the first time and no other instances are alive) onCreate will be called.
You may also find the onTerminate method useful.
Can you just check if the bundle passed to onCreate() is null?
It's not null "If the activity is being re-initialized after previously being shut down..."
There's probably no harm in putting it in onCreate; the Activity is really only destroyed when the OS needs the RAM for something else, not when the user goes to another app.
EDIT: You can also have a Service that runs when the device gets booted up, too. This might be a better option if you also want to check when the app starts, since you'll only have to call context.startService from the Activity to run the check. Just be sure to stop it when it's done if you don't need it to be persistent.