Currently the Items in Action Bar seem to be sequenced by default as:
Order in which menu XML files are inflated. For example calls to onCreateOptionsMenu() or onCreateActionMode() in a Activity class hierarchy.
The individual order in which action items are declared in menu XML files.
Now problem is with point 1 stated above. Is there another way to ensure a proper sequence ? That is, action bar items are arranged in a particular sequence like more usable ones first, and less usable ones can rest in overflow menu.
As far I know, there is only showAsAction property for menu items and is not enough for sequencing items. Is there another property that can be used ?
In current API there's no way to do this. Hijacking super() calls in another (tough and ugly) option.
Related
What is the difference between the following in menus in android as I am getting the same output as when using never when using any of these:
1.withText
2.collapsActionView
Can anyone explain?
You have the answer on Google Developer site here.
withText for example, you can use in form android:showAsAction="always|withText" and it will try to show always text along with icon if there is room for it.
collapseActionView for example, you can use in form android:showAsAction="always|collapseActionView" to only show that item when menu is in collapsed view.
withText
Also include the title text (defined by android:title) with the action >item. You can include this value along with one of the others as a flag >set, by separating them with a pipe |.
collapseActionView
The action view associated with this action item (as declared by android:actionLayout or android:actionViewClass) is collapsible.
Introduced in API Level 14.
There are five values associated with showAsAction. There differences are below.
ifRoom - only place an item in the app bar if there is room. If there are multiple items with "ifRoom" flag a few will be shown as actions in the app bar and the rest will be visible in an overflow menu.
withText - shows text defined in the title for the item without an icon. You can add one more flag using pipe "|". eg- "always|withText".
never- It will always show the item in the overflow menu instead of the app bar.
always- It will always show the item in the app bar. Avoid using this because if there are multiple items with the same flag it will overlap with other UI in the appbar.
collapseActionView- The action view associated with this action item (as declared by android:actionLayout or android:actionViewClass) is collapsible.
Introduced in API Level 14.
For more info visit menu-resource
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" .
Does anyone know how to add a listener to the action overflow menu button ( the three dots on the action bar )?
I would like to add elements dynamically to the overflow menu, and I can't figure out how to do it.
Help please :)
Does anyone know how to add a listener to the action overflow menu button
You don't.
I would like to add elements dynamically to the overflow menu
You can try invalidateOptionsMenu() at the point when you know that you want different menu choices than what you had set up previously. However, I have heard reports that this may not affect the action bar.
If the "dynamic" aspect is based on fragments coming and going, have your fragments implement the option menu items (via overriding onCreateOptionsMenu() and calling setHasOptionsMenu(true)). Android will add and remove items based on the changing mix of fragments on the screen.
In the Honeycomb ActionBar, I am trying to determine the position of the icons that appear as my ActionBar's 'showAsAction' options. Several of my icons are set to appear only if there is room. I want to include helpful comments under each icon when the application is first run. To properly position the comments , I need an idea of where these icons are.
I have called getActionBar() from the activity and the icons don't appear in the ActonBar's View. I know I can get a handle on the Menu Item through the onPrepare and the onCreate for the OptionsMenu, but they don't contain any positioning information since the ActionBar has not been rendered. Any ideas? I have also explored the onMenuVisibilityListener, but the ActionBar at that point still does not contain any information that I can use to calculate the relative positions of the option menu icons.
If there is a way to also just determine which actionbar items are actually appearing, I can calculate where to place things too.
I want to include helpful comments under each icon when the application is first run.
Then load a different menu XML resource on the first run, one that has withText along with ifRoom for android:showAsAction.
You could make this a configuration option for the user, so the user gets to choose which style to use.
If there is a way to also just determine which actionbar items are actually appearing, I can calculate where to place things too.
Except that you can't actually place anything there. The toolbar buttons take up the full action bar height.
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.