According to this page: http://developer.android.com/guide/topics/ui/menus.html#context-menu, Contextual Action Mode is preferred when working on Honeycomb or higher. This is actually very useful when you can apply the same kind of action to several items at a time (eg: delete).
But some actions actually only make sense on one item at a time (eg: Edit).
If you have only one of these actions, well, you can simply use the single click for it. So: One click = edit and select multiple items = action mode with actions that apply to many items
An example of that is the Gmail app: one click = read the email and selecting many items, you can mark them as read, delete them, etc.
OK, but what if you have multiple actions that can only a apply to one item at a time? Imagine the following situation.
You have a list of profiles.You can do the following actions on the profiles:
delete
export (save in a file)
share
These actions could be applied to many items at a time, so you place them in the action mode. But other actions could be:
edit
apply
You can only edit or apply one profile at a time.
So, in that case, is it OK to continue using floating menus like this:
One single click or long-click opens a floating menu with available options on that particular item alone (edit, apply, delete, export, share).
Selecting multiple items activates the action mode with actions that apply to all the selected items (delete, export, share)
Or maybe is it better to keep using action mode only?
When one item is selected, all actions are available (edit, apply, delete, export, share)
When more than one item are selected, the actions edit and apply are disabled/removed from the action bar.
Both methods can work of course and it could be up to the developer to choose but what would be best practice or the best approach to be more user-friendly?
Thanks!!
In GMail, you can also star as well as read on clicking on one item. This is achieved by putting buttons into each row (a star).
Related
Right now I am using three FloatingActionButtons to represent add, save, and reset operations. However according to Material Design guidelines, you shouldn't use more than one such button: https://material.google.com/components/buttons-floating-action-button.html
What is the accepted practice? Is there another sort of bar that is better for holding onto multiple functionality buttons?
I would suggest using a single action button that transforms into related actions, i.e., add, save and reset.
So you'll have something like this after the floating action button was pressed:
If you choose to do this you might want to check out this:
Morph floating action button into related actions
Another option could be transforming the floating action button into a toolbar like this:
In that case you will want to check this out:
Floating Action Button expansion
The Action configuration behavior seems different between an iPhone and Android device.
On an iOS device, the action items or buttons are permanently visible on a toolbar. On the Android the user has to select menu on their device first to make these action items visible in a list. The list will popup.
Is there are way to make these action items always visible on the Android, just like on the iPhone? Our customer base will for sure not know to press that button in order to see more options for our app.
On the Android the user has to select menu on their device first to make these action items visible in a list
It depends on the phone. This behavior is right only for the phones that have a menu button (like the Samsung ones). For the phones without a menu bouton (like the nexus 5 for example), menu can be visible after clicking on the "3 points" in the action bar (the number 3 is the following photo) :
Is there are way to make these action items always visible on the Android, just like on the iPhone?
Yes ! If you see the number 2 into the previous photo, you can see that 2 icons are always visible (the glass and the google play store icon). These 2 icons are 2 menu items but setting as "show always".
More information can be found here.
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'd like to use a drop-down menu for letting the user choose an action (in this case, they select some items from a list, and use the menu to select "delete", "move" etc.)
The way Spinner works is quite close to what I want, except Spinner is clearly designed for selecting some data, rather than issuing a command.
Before it is clicked, I'd like the drop-down menu to just look like an arrow (no adjacent space for displaying the 'currently selected' data
Ideally the drop-down menu would appear directly beneath the arrow, rather than in the middle of the screen.
Items in the menu shouldn't have a radio button to indicate whether they are selected
Is there a component that is more appropriate for this than Spinner, or should I achieve these goals by tweaking a Spinner?
You should use a ContextMenu to do what you are looking for. In the dev guide there is a page about menus and a section about ContextMenus that will help with the implementation. If you put some time in skinning this menu you can change the look to match what you want.
may be i not getting you but You can use actionsheet which you can handle as you want
I was wondering if it were at all possible to have checkable icons in an action bar in ICS? Not with a check, but with a android:stateChecked property to play around with. I want it so when the user clicks on the icon, they enter a certain mode (and the background of the icon would be a bright color to let them know they are still in that mode), and when they click it again they are taken out of that mode. I've played around with some selector xmls but nothing has worked...Any ideas?
EDIT: I just learned that Checkable items cannot appear in main menus, they can only be in submenus. However, is there a way to still get the behavior of a checkable? It's easy enough to have a boolean like isInModeA, but is there a way to programmatically change the background/icon of an Action bar item?
There is a way to programmatically change the background/icon.
You can use ActionBar.setBackgroundDrawable, for instance, or setCustomView, or setIcon (found on the same page).
You may consider using a dropdown-like ActionProvider to provide e.g. a radio-button-like "on/off" rather than a checkbox.
One approach you could try is to keep the state saved in some variable and just display different items based on this state. Obviously, some of these items can change the state. You might look at doing this by implementing a custom action provider.