Halo,
My ideia is to show a Context Menu by clicking on one of the options menu.
I don't think it will be quite difficult but I'm not being able to get the View in the OptionsMenu class.
So actually it is just call the showContextMenu() on the OptionsMenu class.
Can somebody give me a hint?
ty!
It's possible to call a Context Menu by means other than a long press. If you implement your menu options within your activity, using an inner class for instance, you should be able to call your context menu:
yourView.showContextMenu();
Remember to register your context menu at onCreate:
registerForContextMenu(yourView);
Finally made it, and it was a quite simple solution.
Basically I pass the View, to the OptionsMenu constructor.
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
this.setContentView(R.layout.activity_event);
View v = findViewById(R.id.activity_event);
registerForContextMenu(v);
options = new Options(getApplicationContext(), getMenuInflater(), v);
fillData();
}
...
private class Options extends ActivityOptionsMenu {
public Options(Context c, MenuInflater mi, View v) {
super(c, mi, v);
}
}
...
private abstract class ActivityOptionsMenu {
...
public void onMenuItemSelected(int featureId, MenuItem item) {
switch (item.getItemId()) {
case R.id.directions:
v.showContextMenu();
}
}
}
Thanks for all the help.
My ideia is to show a Context Menu by clicking on one of the options menu.
AFAIK, you cannot show a context menu from a long-tap on an option menu choice.
I don't think it will be quite difficult but I'm not being able to get the View in the OptionsMenu class.
The View is not exposed to you.
The only way to literally do what you seek is to not use the standard Android option menu. You can watch for the MENU key via onKeyDown() in your activity, at which point you can display whatever you want, including something that supports context menus.
However, context menus are not particularly popular among users, simply because they are not very discoverable. Users never read the documentation, even if it is supplied, and they tend not to randomly stab the screen to see if a menu will pop up. They will be even less likely to decide to hold down a fake option menu choice to see if a context menu will pop up.
Hence, I really recommend you consider some other approach, for improved usability.
Related
I have a context menu with a menu item that is supposed to start an intent:
#Override
public void onCreateContextMenu(ContextMenu menu, View view,
ContextMenuInfo menuInfo) {
MenuItem item = menu.add(menuItemText);
item.setIntent(intent);
This used to work, but in newer Android versions, it throws an exception:
Calling startActivity() from outside of an Activity context requires
the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?
Adding this flag would be the easy way out, but I don't want to create a new task since this is supposed to be part of the application's activity stack. The problem is that the system calls startActivity which the context of the item, which in this case is a DecorContext, not an Activity. Since this is all handled by the framework, I have no control over this.
Is there a good solution to this other than setting the flag or handling the operation in onContextItemSelected?
This is because Android uses DecorContext for Activities starting in Android 27.
You can see the change here.
You can confirm this in the system level by looking inside of line 319 in PhoneWindow. Notice that when the PhoneWindow is being constructed from an Activity, mUseDecorContext is always set to true. This means that your Menu will be built with the DecorContext every time.
My understanding is that having a separate DecorContext for ContextMenu is intentional. ContextMenus are meant to "float" above content and thus act as a separate menu from the content on which they are being presented.
Depending on what you are using ContextMenu for, you might have to consider waiting to build the Intent until onContextItemSelected, even though you mentioned you would like to avoid that situation. Alternatively, you might have to use some form of IPC to wrap and send your intent back to the Activity. We use the RxBus pattern for this rare use-case. Alternative options are LocalBroadcastManager and EventBus by GreenRobot. Hopefully, this helps get you started on alternative solutions. Let me know if you have questions.
Exception is because you may have not overridden onContextItemSelected method.You have to override onContextItemSelected() as below :
#Override
public boolean onContextItemSelected(MenuItem item) {
startActivity(item.getIntent());
return true;
}
Hope this will help you.
You can try
#Override
public void onCreateContextMenu(ContextMenu menu, View view,
ContextMenuInfo menuInfo) {
intent.addFlags(Intent.FLAG_ACTIVITY_MULTIPLE_TASK);
MenuItem item = menu.add(menuItemText);
item.setIntent(intent);
}
I'm new to android studio applications, so i'm not sure if either will work.
I use some custom ActionModes in my application. When an action mode is closed, I do some housekeeping, like closing related views, updating changes, etc.. I detect the action mode has been closed in OnDestroyActionMode.
My problem is, when inside of some of my ActionModes, the user may trigger another system actionmode (The text copy/paste/select). In that case, onDestroyActionMode is called and I erroneously asume the user is done with the first actionmode, rather than implement a "stack" functionality, so can I ignore this onDestroyActionMode, let the user edit / cut / etc the text, then reopen the former actionmode when done.
How can I achieve this?
Shedding further light on your situation: prior to honeycomb, longPress on a TextView will yield a popup window with options (like 'Select word', 'Select all', and 'Add "someword" to dictionary') while NOT affecting any existing ActionMode both when shown and when dismissed (by pressing back). So this isn't really a problem pre-honeycomb.
More light regarding HTC Sense: Sense does NOT honour TextView.setCustomSelectionActionModeCallback() because Sense doesn't use an ActionMode for the Text selection feature (and clearly don't care if the rest of the world do!). So this problem has a different smell in that situation (I haven't tested the following solution under Sense, so not sure how it'll behave).
A solution is to create your own custom ActionMode.Callback to replace the OS's one and apply it in setCustomSelectionActionModeCallback() of any TextView and/or EditText you desire (though only if device is running honeycomb or greater). Pass a custom onTextSelectionCABDestroyed callback interface to your custom ActionMode.Callback, call it in the onDestroyActionMode method.
Firstly create an interface and implement it where you want to handle the recreation of your original ActionMode (alternatively you may want to use a bus event with something like Otto):
public interface YourCallbackInterface {
public void onTextSelectionCABDestroyed();
}
and create a new class:
public final class CustomTextSelectionActionModeCallback implements ActionMode.Callback {
WeakReference<YourCallbackinterface> mYourCallbackinterface;
public CustomTextSelectionActionModeCallback(YourCallbackinterface yourCallbackInterface) {
mYourCallbackinterface = new WeakReference<YourCallbackinterface>(yourCallbackInterface);
}
#Override
public boolean onActionItemClicked(ActionMode mode, MenuItem item) {
return false;
}
#Override
public boolean onCreateActionMode(ActionMode mode, Menu menu) {
return true; //returning true will create the ActionMode
}
#Override
public void onDestroyActionMode(ActionMode mode) {
//this is the magic where we actually capture the destroy event for TextSelectionCAB and can subsequently do things like recreate the ActionMore that TextSelectionCAB greedily destroyed!
mYourCallbackinterface.get().onTextSelectionCABDestroyed();
}
#Override
public boolean onPrepareActionMode(ActionMode mode, Menu menu) {
return false;
}
}
And remember to avoid StackOverflowException when recreating an ActionMode from the onDestroyActionMode of an ActionMode, postDelayed a Runnable to a Handler like this I explain here: Reopen ActionMode (or CAB) after onDestroyActionMode is called
Lastly, if you're using ActionBarSherlock, make sure that your CustomTextSelectionActionModeCallback implements android.view.ActionMode.Callback rather than com.actionbarsherlock.view.ActionMode.Callback.
Note: I haven't played with ActionBarCompat so not sure how all this applies there. If someone knows, please post as comment!
I see that it's possible to handle a tap on a icon menù item or by implementing
onOptionsItemSelected
inside the acivity, or by using
onMenuItemClickListener
like onclick listener on a button. When is better to use the fist one method, and when the second one?
Because for my opinion, using an external listener makes more modular the code, but create a new class, but using the first way don't create new class, but makes code less modular...
There are use cases other than the ones outlined below, but I'm putting in the general cases that come up regularly.
onOptionsItemSelected
If you're using Fragments, you may want to use onOptionsItemSelected and consider adding menu items to the Action Bar the way that is described in Adding items to the Action Bar.
What this describes is implementing onCreateOptionsMenu inside your Fragment. To make this happen, you must call setHasOptionsMenu in onCreate.
protected void onCreate(Bundle savedInstanceState) {
this.setHasOptionsMenu(true);
}
Setting this will actually make the Activity call onCreateOptionsMenu which allows you to add the menu items.
#Override
public boolean onCreateOptionsMenu(Menu menu){
super.onCreateOptionsMenu(menu);
// add items corresponding to this Fragment
menu.add(...);
return true;
}
The reason I recommend this is that it allows you to put more of the menu handling code into your Fragment instead of the Activity to figure out which Fragment to call, etc.
In this case, clicking the menu item will call onOptionsItemSelected inside of your Fragment which I suggest.
#Override
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()) {
case R.id.my_id1:
dothing1();
return true;
case R.id.my_id2:
dotghing2();
return true;
default:
return super.onOptionsItemSelected(item);
}
}
More of a long winded answer, but this is the way to handle menu clicks inside your Fragment.
onMenuItemClickListener
In the case of onMenuItemClickListener, this is used when you DON'T want to use the pre-ready method above and implement your own.
What I mean by that is you implement OnMenuItemClickListener and generate the methods in the interface. You then assign the menu to call the Activity that implemented this where as the above option assumes what Activity to use based on the pre-ready implementation of the Activity to Fragment relationship.
If you are targeting API 14 or greater (ICS or above) you could implement an ActionProvider. If that's not an option then you could implement a base activity that will always populate the menu and handle any menu clicks using onOptionsItemSelected. This is a good approach to implement "About" or "Settings" menu items through all your activities.
In my Android application I have a Button which opens up a context menu when clicked. The issue is that if a user clicks quickly, they can open multiple instances of the menu.
b.setOnClickListener( new OnClickListener() {
#Override
public void onClick( View view ) {
// popup options
view.showContextMenu();
}
} );
How can I prevent the user from opening up more than one copy? I am looking for a 'boolean' like checking the Visible status, but can't seem to find anything. My hope was that there was a function somehow that would result in code similar to:
if (context menu is not open)
open context menu
else
don't do anything
I really don't like this UI pattern. It's this sort of thing that cause iOS developers (and users) to think that Android developers lack discipline. Context menus are for long-presses, period. Use something else, like an AlertDialog or PopupMenu, elsewhere.
That being said, set a boolean flag when you show the context menu, checking it first to prevent duplicate menus. Clear the flag in onContextMenuClosed().
I have an Options menu up and running in my Android application and I've overridden the onCreateOptionsMenu, onOptionsItemSelected and onPrepareOptionsMenu methods to customize the menu a little.
My question is related to keeping the Options menu open after the user clicks on a menu item. Basically, I'd like to be able to hide the menu until the user clicks on the device menu key. Once the user clicks on this key, I'd like to be able to hold the menu in place regardless of how many times the user clicks on menu items. If the user wants to hide the Options menu, they'd just need to click on the device menu key again.
Is this type of interaction supported (or even advisable). If this interaction is not supported, any alternative suggestions are more than welcome.
Cheers!
Sean
This will not be possible with onCreateOptionsMenu and the other methods. They always act that way.
But you can do it another way. But there you have to program the whole menu yourself. Basically add the Menu in your layout.xml and let it be hidden (visibility = gone). Then you overwrite the methods onKeyDown. There you check if it is the Menu key. if the menu is not yet open yes, then you show the menu. If it is open already, you hide it.
should not be too difficult. Good thing as well is, that you can make the menu look exactly the way you want and as well let it react the way you want.
For anybody like me, who found this question in google:
To keep menu open after selecting item, you need this code:
#Override
public boolean onOptionsItemSelected(MenuItem item) {
item.setChecked(!item.isChecked());
item.setShowAsAction(MenuItem.SHOW_AS_ACTION_COLLAPSE_ACTION_VIEW);
item.setActionView(new View(this));
item.setOnActionExpandListener(new MenuItem.OnActionExpandListener() {
#Override
public boolean onMenuItemActionExpand(MenuItem item) {
return false;
}
#Override
public boolean onMenuItemActionCollapse(MenuItem item) {
return false;
}
});
return false;
}
Important to return false in onOptionsItemSelected and methods of OnActionExpandListener
This solution from #MayurGajra. More details here: How to hold the overflow menu after I click it？