I'm curious as to how (if at all) onPrepareOptionsMenu(Menu) (and by extension, onPreparePanel(int, View, Menu)) is used on Android 3.0+ when targeting API 11 or greater.
My thinking is as follows:
An Activity's ActionBar receives its content from onCreateOptionsMenu(Menu) where you can either inflate an XML menu resource, add items directly, or some combination of both. Any fragments of the activity will also receive this call and have the option of doing the same.
To update the items on the ActionBar you can either hold on to the Menu instance or call invalidateOptionsMenu() which will then wind up calling onCreateOptionsMenu(Menu) again.
Thus, is onPrepareOptionsMenu(Menu) then only still around to support legacy applications which do not target API 11 or newer?
Does calling getActionBar().hide() and getActionBar().show() trigger a call to onPrepareOptionsMenu(Menu) perhaps?
Does adding or removing a fragment somehow trigger this?
From my extensive testing, it strangely appears to work exactly like on pre-3.0 versions of the platform, only being invoked when the overflow menu is opened. The callback did not fire on either of the events listed in the original question.
A perhaps obvious but noteworthy fact: The entire menu is accessible on this callback so manipulation of items which are visible on the action bar, in the overflow menu, and/or hidden is possible.
Sice I recently had similar questions and stumpled upon this one, I'd like to add for later readers:
Yes, onPrepareOptionsMenu still does work.
However, you should just invoke the standard implementation for Honeycomb devices (i.e. if ( android.os.Build.VERSION.SDK_INT >= 11 ) return super.onPrepareOptionsMenu(menu);) and use invalidateOptionsMenu() (via reflection, if necessary) and onCreateOptionsMenu() instead, esp. when using showAsAction. Otherwise, the menu won't be updated until it's opened. For example, if you add some entries when an item is selected, the items will magically appear in the action bar when the menu's opened, not when the item's becoming selected. Same goes for deselection and hiding the menu items.
Related
Most of the times whenever there is a talk of updating the ActionBar options (like displaying/hiding items) I see people doing that with calling invalidateOptionsMenu method (or AppCompat equivalent) to force that onCreateOptionsMenu again, which essentialy does the same thing it did before which is inflating the menu again, setting up all the menu items etc. All this work, just to change a visibility of say... one item.
Same thing I see in all the samples I've seen from Google. And for the life of me I cannot figure out the reason why all this uneceseary overhead is done(inflating the menu etc) when all of this could be done if you only holded the Menu reference localy, and invoke a custom method say... adjustMenu(Menu menuReference), which would not have to inflate the menu and create it again, but just make neceseary modifications on the already created Menu. So something of these sorts:
https://stackoverflow.com/a/7066901/905938
Most likely there is a reason for doing it Google way (through forcing onCreateOptionsMenu again and again), since Google samples do the same, but since I couldn't figure out the reason on my own, maybe someone could give me a hand here, and point me to that reason.
You should only really be inflating your options menu within onCreateOptionsMenu().
when all of this could be done if you only holded the Menu reference localy
You can do this locally via the method onPrepareOptionsMenu(Menu menu). This would actually be a great place to set a menu item's visibility. As to the question of the significance to the call invalidateOptionsMenu(); it's purpose should be looked at from two viewpoints.
Before API 11 and the introduction of fragments, the call to invalidateOptionsMenu would signal that the methods onCreateOptionsMenu() and onPrepareOptionsMenu() should be called again. Since activities normally have only one options menu, the menu object could afford to be kept in memory so as to make subsequent calls to onCreateOptionsMenu() more responsive.
Since the release of API 11, the options menu could no longer be stored in memory as before, since the introduction of fragments meant that the activity as well as each of its fragments could have its own options menu, and as fragments can be changed dynamically during the lifetime of the activity, it would be inefficient to store a bunch of options menus for each fragment as these fragments would not be guaranteed to stay on screen. Remember as well that in API 11+, options menu items can be displayed on the action bar. Changing your phone's configuration from portrait to landscape would mean more options menu items could be displayed on the action bar, thus items present in the overflow menu could now be moved to the action bar itself. An alternate albeit slower solution would be to simply rebuild all onscreen fragments' options menus from scratch. So for API 11+, the call to invalidateOptionsMenu() can be viewed as a signal to indicate that the layout of an activity's fragments have changed, and that the methods onCreateOptionsMenu() and onPrepareOptionsMenu() should be called for both the activity and the fragments it is currently hosting.
Check out the entry on invalidateOptionsMenu(Activity activity) here for more information as to why invalidateOptionsMenu is used.
Working on Worklight project for Android platform. Wondering is there any way to override WL.OptionsMenu.addItem?
This is not to hide settings option menu. From Android SDK 11, option menu will be replaced with action bar. In full screen of WebView there is no way to show action bar. In this mobile app, implemented sliding menu. Each time invoke WL.OptionsMenu.addItem will add a menu item in sliding menu.
Thanks
Based on your edit:
Worklight does not yet support the ActionBar in Android, so oddities can happen when using the WL.OptionsMenu API in conjunction with API Level 11 in Android.
Can you explain what you're trying to accomplish? What does "overriding" an item mean in your case?
This is the WL.OptionsMenu API, you can do whatever you want in its limits.
If you mean that you'd like to simply remove the default "Worklight Settings" item, then you need to set worklightSettings to 'false' in application-descriptor.xml. After that, you can simply initialize the OptionsMenu and add any items you need to it.
If you mean that you have an existing item you would like to change, since you know the item ID, you can simply re-create the item, which essentially overrides what it was previously doing.
For some reason, onCreateOptionsMenu() is called AFTER onResume() in my app... Therefore, I just can't get a hold of the menu while I'm setting up my UI (between onCreate() and onResume()), which results in not being able to setup the corresponding action items for my ActionBar...
The only work-around I've found so far is to manually call invalidateOptionsMenu() right before onCreate() returns; that way onCreateOptionsMenu() is immediately called, I get a hold of the menu and then I can finally add the desired action items.
Has anyone experienced this issue? How are you supposed to programmatically setup your action items given onCreateOptionsMenu() is called after onResume()?
My app is running on JellyBean, it uses the built-in ActionBar (no ActionBarSherlock), android:minSdkVersion="14" and android:targetSdkVersion="16"
First consider that perhaps you shouldn't be doing this. It sounds like your idea might go against typical design patterns for Android. If your menu is changing in response to a user selection, for example, you should use contextual action mode instead.
From the Action Bar API Guide:
As a general rule, all items in the options menu (let alone action items) should have a global impact on the app, rather than affect only a small portion of the interface. [...] So, even before deciding whether a menu item should appear as an action item, be sure that the item has a global scope for the current activity.
From the Menu API Guide:
You should never change items in the options menu based on the View currently in focus. When in touch mode (when the user is not using a trackball or d-pad), views cannot take focus, so you should never use focus as the basis for modifying items in the options menu. If you want to provide menu items that are context-sensitive to a View, use a Context Menu.
Barring that, if you do want to change the menu items as you have described, you should make the change in onPrepareOptionsMenu(). When the event occurs that requires changing the menu items, put the relevant information into a field and call invalidateOptionsMenu(). Override onPrepareOptionsMenu() and check the value of the field to determine which menu items to add/remove.
(It would also work to call invalidateOptionsMenu() and override onCreateOptionsMenu() to modify which menu items should be shown, although this approach is not recommended.)
More from the Menu API Guide:
You should use onCreateOptionsMenu() only to create the initial
menu state and not to make changes during the activity lifecycle.
If you want to modify the options menu based on events that occur
during the activity lifecycle, you can do so in the
onPrepareOptionsMenu() method.
This method passes you the Menu object as it currently exists so you
can modify it, such as add, remove, or disable items. (Fragments also
provide an onPrepareOptionsMenu() callback.)
On Android 2.3.x and lower, the system calls onPrepareOptionsMenu()
each time the user opens the options menu (presses the Menu button).
On Android 3.0 and higher, the options menu is considered to always be
open when menu items are presented in the action bar. When an event
occurs and you want to perform a menu update, you must call
invalidateOptionsMenu() to request that the system call
onPrepareOptionsMenu().
I am using ActionBarSherlock. I wish to be able to make two buttons appear in the Action Bar in response to a certain user operation. The user operation is completely unrelated to the Action Bar. The visibility of the buttons needs to be controlled by calling a method. Also, response to clicking those buttons shall be handled by my own application code.
The buttons shall ideally look just like those that are created when defining menu items as Action Items using android:showAsAction="ifRoom|withText", as illustrated here.
My problem is that as far as I can tell, the standard ActionBar API provides no such mechanism to show or hide Action Item buttons at will, and the only time that the menu items can be defined is within onCreateOptionsMenu() which is of course called by the system.
My belief is that the only way I'm going to add buttons like this and show / hide them at will is to create a custom layout for them and make use of .setCustomView() to place them into the Action Bar. Would people generally agree with that, or is there something I have missed?
If I do go down the route of using .setCustomView(), I would like my buttons to look identical to Action Item buttons that ActionBarSherlock displays for a menu item that has the attribute android:showAsAction="ifRoom|withText". To do this, can anyone advise me which particular theme, style, or layouts from within the ActionBarSherlock library I should make use of? I have already tried to use R.layout.abs__action_menu_item_layout, but attempting to inflate this layout produces an exception relating to a colorStateList when attempting inflation of the CapitalizingButton that the layout contains.
You can call setVisibility on the MenuItem instances.
The documentation states that "You can safely hold on to menu (and any items created from it), making modifications to it as desired, until the next time onCreateOptionsMenu() is called."
If you want those two buttons to have the look and feel of menu items, then you should make them menu items. Your assumption that menu items can only be defined in onCreateOptionsMenu() is incorrect, because there's also a method called onPrepareOptionsMenu(), that will be called each time right before the menu is shown. Together with an activity's invalidateOptionsMenu() method, you can easily create a menu dat reflects the current state in realtime.
The alternative is to keep a reference to the individual MenuItem objects, as the documentation states its save to hold on to those, and change their visibility when appropriate. You may still have to call invalidateOptionsMenu() to update the menu- I can't remember from the top of my head. (Edit: Jake beat me to it on this one)
Personally, I prefer the first approach, since you keep all menu-related logic grouped together and the visibility is based on some sort of state/model. The second option may be more straightforward to implement, depending on your current code, but may result in menu-stuff all over the place.
have you checked the demo samples ?
they have this feature there on "feature toggles" .
I am working on an application for API 7+ that implements ActionbarCompat.
Currently I have an activity with a "favourite" icon on the ActionBar and I am trying to find a way to toggle the graphic between favourite and not favourite.
All my efforts with playing around in onCreateOptionsMenu, onPrepareOptionsMenu and onOptionsItemSelected have failed, it appears the icon can only be changed at the time of creation and not while the activity is already running.
Has anybody come across a way to change one of these ActionBarCompat item icons at run time while the activity is visible using ActionBarCompat and still maintain compatability with the native ActionBars on APIs 11+?
You need to implement some basic logic in onCreateOptionsMenu() that checks whether the item is favourited or not and changes the icon based on that logic.
In your setFavourite() method, you'll need:
setFavourite() {
....
if (changedFavourite)
invalidateOptionsMenu()
See documentation here: http://developer.android.com/reference/android/app/Activity.html#invalidateOptionsMenu()
That should force ABS to redraw.
Inspired by #mobinvent's comment I found that the following gives pre HoneyComb devices utlising ActionBarCompat the options menu lifecycle sequencing as per invalidateOptionsMenu() on HoneyComb and above.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) invalidateOptionsMenu();
else {
supportInvalidateOptionsMenu();
openOptionsMenu();
closeOptionsMenu();
}
Note the hacky requirement to open the options menu and close it. In my particular instance I call this from onActivityResult which at this stage does not appear to introduce any ugly menu flicker.
Good riddance to pre ActionBar OS / devices!