tags:

views:

126

answers:

1

In Android, onContextItemSelected has a single MenuItem argument and so it isn't clear how to identify the view selected. MenuItem.getMenuInfo provides access to Contextmenu.ContextMenuInfo, but while both known subclasses provide access to the target view, there does not appear to be an accessor on the interface.

One alternative is to save the View provided in onCreateContextMenu in a private class variable which relies on onCreateContextMenu not being called again in the activity before onContextItemSelected. Another is to use the id of the View for the itemId argument of ContextMenu.add. If we do this, we would then need to identify the option selected from the context menu by using its (possibly internationalised) title.

What is the best method for identifying the View selected in onContextSelected?

+1  A: 

There is no such concept as "identifying the View selected" for either option menus or context menus in Android. Hence, it is rather difficult to answer your question. So, I'll take some guesses.

If by "identifying the View selected" you mean which menu choice was selected, that is getItemId() on the MenuItem that is passed to onOptionsItemSelected() or onContextItemSelected().

If by "identifying the View selected" you mean which row in a ListView was the one long-tapped on to bring up the context menu, cast getMenuInfo() (called on the MenuItem) to AdapterView.AdapterContextMenuInfo, then use either the id or the position values as appropriate based on your adapter. See here for a sample project that uses this technique.

If by "identifying the View selected" you mean you have more than one non-ListView context menu in an activity, I would not use that UI technique.

CommonsWare
I meant the third option, that in general there could be multiple views on screen and that some of them might want to have the same context menu. Why would you not use that UI technique?
Casebash
Simple: there are no visual cues for context menus. A small percentage of Android users know to long-tap on lists for context menus. Next to nobody will bother trying to long-tap on anything else for context menus. Everything you offer via context menus needs to be offered by at least one other mechanism, just for better discoverability. Power users might find the `ListView` context menus, and so offering those to speed up navigation is OK. Context menus on things other than `ListViews`? I just wouldn't bother.
CommonsWare
@Commons: Good points, but you forgot to @reply me. Suppose you had to use multiple context menus. What method would you use?
Casebash
@ replies have no particular impact on StackOverflow AFAICT. Again, I simply would not use multiple context menus. Assuming somebody is holding your loved ones at gunpoint, I fear that having N menu items with the same ID might confuse Android, so your 2nd option seems prone to eventual failure. The 1st option should be safer, albeit ickier from a state-management standpoint.
CommonsWare
When someone comments on your answer or question, you receive a notification. When you comment on somebody else's answer or question, you only receive a notification if you are @ replied. This means that if someone is waiting for a clarification before accepting your answer they might never discover that you have replied and so you will gain less reputation.
Casebash