I have a context menu on a TextView representing a user name in my app. When the context menu appears I want to have certain options such as View Statistics etc. The context menu is appearing fine and everything is working great except it's adding Input method to the context menu and I do not want it there. It's irrelevant to what the context menu is there for and there is not text entry. How can I remove this item from the context menu? I've tried removing item 0 in the context menu and adding
android:editable="false"
to the XML file to no avail. Any ideas?
How about menu.removeItem(android.R.id.switchInputMethod);?
Im pretty sure that isn't possible, the input method is how the user changes the current IME (soft keyboard) if the have multiple keyboards installed. Its a global setting.
Related
I have an editText that triggers the regular android context menu to fire up on long press. The talkback focus though doesn't go to the context menu directly but instead goes through other focusable elements first before focusing on the context menu. Basically is there a way to access the default context menu (marked as 2) in android and give focus to it first after long press instead of talkback moving to other elements (marked as 1)?
sample SS
I can setup the context menu of EditText when it is not in fullscreen with setCustomInsertionActionModeCallback and setCustomSelectionActionModeCallback methods but they don't do anything to setup the context menu when the EditText is in fullscreen (i.e. it remains default), and there seems to be no obvious way to do that.
Thus my question is: how to set the context menu of fullscreen EditText?
On android, whenever the user long-clicks on a text field, they get a context menu with options like 'copy' , 'paste', 'select all' etc. Now, I'm aware I cannot add my own items to this menu, system-wide - android won't and shouldn't let me. But I can write my own context menu from scratch, and whenever the user long-clicks on a text view, they will be given two options - 1. System context menu 2. My own menu.
I know this can be done, but I don't know what API calls to use, to achieve this.
Existing applications that do something similar:
Swype keyboard: This keyboard application overrides the system keyboard. So when user clicks on a text view to type something, they're given two options, namely - 1. Default system keyboard, or 2. Swype keyboard user installed. User also gets the option to make one of them the default.
Similarly, Go Launcher Ex: System wide whenever we press the 'Home' button, we get two options - to display the regular Home screen, or display the Go Launcher Home screen.
Any suggestions, or reference material are highly appreciated.
Thanks!
Both of your examples are accomplished using Intent filters. However, the EditText's context menu is not shown using an Intent, and therefore cannot be overridden in this way.
You can override the menu in your app using onContextMenu and related API's but there is no way to do so for other apps.
How would I go about adding a context menu to a spinner popup?
I have a spinner that is populated by a database cursor, and I'd like to have a context menu so when the user long clicks an item they can edit or delete the item (two options in context menu).
I can't seem to find a way to register a context menu for the window that appears with the selectable items. Is there a way to, like on a list View?
Otherwise, what about having a hidden view that is registered for a context menu and then use the spinner's OnItemLongClickListener call openContextMenu for the hidden view? This seems kind of like a hack so I'd rather do it the correct way, if possible.
Or maybe I should just register the spinner for the context menu instead of having a hidden one...
Thanks!
How would I go about adding a context menu to a spinner popup?
Ideally, you wouldn't even try. Classic pop-up context menus are going to be obsolete with the new Honeycomb UI, at least for the tablet form factor, so I would not invest a ton of time in hacking them into widgets where they aren't normally used.
Moreover, users are unlikely to discover your context menu, simply because they tend not to discover context menus too often in the first place. Users tend not to experiment by randomly stabbing the screen for a second-plus to see if menus happen to pop up. The only way they will know about your context menu is if they read the fine manual, and we all know how often that happens. Hence, you need some other way for the user to do the same operations -- having them be able to edit/delete only through a non-discoverable context menu is very user-hostile. Hence, context menus are, at best, an accelerant, and not worth forcing into unexpected and unsupported places.
I have a spinner that is populated by a database cursor, and I'd like to have a context menu so when the user long clicks an item they can edit or delete the item (two options in context menu).
If you want the context menu, convert the Spinner into a ListView. Not only will this be incrementally more discoverable (some users will be used to interesting things if they long-tap on a list item), but context menus work naturally.
If you really want, you can clone Spinner (and possibly AbsSpinner or other superclasses) into your project, so you can take control over the drop-down behavior, then write something that enables a context menu on the selection dialog box. Then, you will need to bear in mind that none of that will work, most likely, with the new Spinner in Android 3.0, simply because there is no more selection dialog box.
I would like to create a context menu (long press on a textview) that will show a list of options.
Difference from regular context menu will be, that the use is different: user will long click on the textview, menu will popup, user will not release finger, point to the menu item, release finger. This will fire the action.
Any idea how ot do it?>Can you refer me to an example
I don't know how to fully achieve it. But this might help you. You can create a context menu as shown here.
Hope this helps.
Unless you have a very specific use case, I'd recommend against changing how the user expects a context menu to behave, and stay with the default behaviour. It can lead to quite a jarring user experience.