How do you use addContextMenuItem in sl4a?
I'm using the experimental full-screen UI to display a list view. I want to:
1) trap a long-press on an item on the list
2) show a "pop-up" menu of options relating to that item.
The listview part works fine.
I know how I can do 2) once I get an event (simply display an alert and add items) but I can't see what user action actually triggers the event you define, or how to control it.
E.g. what will fire the "Play" event defined below, and how do I control what does?
droid.addContextMenuItem("Play", "contextmenu", "test")
Related
I am having trouble remembering what kind of Android component is being used to make the selected list item menu in their Gmail app. That is, when I open the app and see the list of emails in the inbox, I can long-press one of the items, and some sort of list shows up in the top of the screen, sort of like a context menu, with actions I can perform on the selected item(s). I would like to replicate similar functionality in one of my own apps. If I recall correctly there is a way of doing this using some standard Android UI component, but I'm having trouble finding what that is. Any pointers?
You're looking for a contextual actions bar. Details on how to create one are stored under the menu section of the documentation as they relate to action items.
I'm using ListPopupWindow which I find very suitable for the purpose with one exception. I want to be able to detect when the user does other than select an item from the list or presses the back button. Currently what is happening is that when an item is clicked outside of the ListPopupWindow list I cannot determine what was clicked and the ListPopupWindow is dismissed. Ideally what I would prefer is for the user to only be able to select an item from the list or press the back button, however I cannot achieve that. I've searched for an answer and experimented for hours but I cannot achieve what is required. As far as I can determine, setting modal to either true or false appears to make no difference. I can obviously detect what is selected from the list, however whether the user presses the back button or clicks outside of the list appear to both dismiss the ListPopupWindow and I cannot determine the action that caused it other than an item was not selected. How can I either detect or prevent other than the user selecting an item from the list or pressing the back button?
As far as I can determine, this can be solved using
android.support.v7.widget.ListPopupWindow;
and
setForceIgnoreOutsideTouch(true)
This is my custom-dialog layout.
I want to move the selector of days and load respective items in the grid below it.
I could perform it via filter as said here
But because of the filter I am not being able to perform the action that should be triggered while clicking items in the grid view. It works fine when I click via mouse but not D-Pad.
If I remove the filter in keyevent, it works normally, but problem again in sliding the selector via.
As I am working in STB, I have no option except remote as remote functionality is kept as the basic requirement.
Finally solved it by using the filter in every case of key-event rather than at top.
I have a problem.
I have an action bar. It has a drop down list and it has an overflow button and another button some where in between.
Because I use a drop down, I am setting the action bar to use this mode:
mActionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_LIST);
mActionBar.setListNavigationCallbacks(mActionBarNavigationAdapter, mOnNavigationListener);
mActionBar.setDisplayShowTitleEnabled(false);
My mOnNavifationListener is set to call a REST api depending on which item I chose in the drop down list.
This works as excepted.
The problem is, if I click on the overflow button to reveal extra options (such as settings or more importantly, Signout), I still get the navigation listener activated.
So I thought. Ok let's try to distinguish between the buttons using their position or id which are passed as parameters in onNavigationItemSelected method.
So I added an if statement that checks the position parameter. But...
It seems that the position of the overflow button is ALSO 0 (exactly like the position of the first item in the drop down list, so it passes the check and calls the REST api which is not good.
Also, the third button (not the drop down list or the overflow), has a position of 1 which effectively calls the other REST api...
I can't find a way to distinguish between the items in the action bar.
Any suggestions?
First, I'd strongly consider replacing your use of list navigation, as that is officially deprecated in the "L" Developer Preview and should remain deprecated in the next shipping version of Android.
I still get the navigation listener activated
I am not clear on what you mean by this. I also don't know which action bar you are referring to:
native API Level 11+?
appcompat_v7?
ActionBarSherlock?
Ideally, onNavigationItemSelected() will be called when your activity first appears, then if the user chooses something from the Spinner. If you are saying that it is being called at other points in time, while unfortunate, this can be worked around by simply keeping track, in your own data member, of where you are in the Spinner, and only doing work if the Spinner position actually has changed. So, for example, if you start off showing position 0, and the user taps something which causes onNavigationItemSelected() to be called again with position 0, you know that nothing needs changing, because you are still on position 0.
The new (ICS) guidelines were published.
It is written there:
If you don't support multi-selection within a list, long press should do nothing.
I don't support multi-selection and still want to support acting on a single list item.
How should I support acting on a single list item?
You can support multi-selection at a basic level and provide context actions in the action bar for users that long press an item. (Limit selection to one entry.)
Alternatively you should provide such context controls from within the item itself.
For example if you have a list of music that you do not wish to make multi-selectable, the user can click a song to preview it, and in a new view see the options to queue/delete/etc.
With the original suggestion the user can long press the song, and then perform these actions from the action bar.
The obvious problem is that every action is now 1 further click or unnecessary action away. (For a non multi-selectable list anyway.)