I am developing the app, when I am implementing the menu for my app, the I am hiding some menuitems from some screens and for this I am using this code :
#Override
public boolean onPrepareOptionsMenu(Menu menu) {
MenuItem search = menu.findItem(R.id.action_search);
search.setVisible(false);
MenuItem create_opportunity = menu.findItem(R.id.menu_example);
create_opportunity.setVisible(false);
//this.invalidateOptionsMenu();
return super.onPrepareOptionsMenu(menu);
}
When I am uncommenting this invalidatinoptionsmenu line , it starts giving I/InjectionManager? dispatchCreateOptionsMenu continously in the logs of the app. May i know due to this the battery also can be consumed ?? , this logs I am getting in samsung mobiles only.
Appreciate your inputs.
I'm working on a similar issue with my own app. The documentation pretty much says it all:
When an event occurs and you want to perform a menu update, you must call invalidateOptionsMenu() to request that the system call onPrepareOptionsMenu().
so calling invalidateOptionsMenu() from onPrepareOptionsMenu will create an infinite loop.
Related
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 just started using Juno, and I was wondering what this method is really about. And since I
dont use it, I dont want it to create every time i create a project. How can I disable her?
#Override
public boolean onCreateOptionsMenu(Menu menu) {
getMenuInflater().inflate(R.menu.activity_main, menu);
return true;
All this does is create your menu that shows up when you press the menu key. It may also show up in the action bar depending on how your app is set up and the API version it is running on. It is not needed unless you have extra options that you want to show to the user in this manner.
This method is by default created from the ADT Activity templates.
I put a couple of breakpoints in onCreate (one at the beginning, and one at the end of the method), and I also put one at the beginning of onCreateOptionsMenu. The onCreate method is called first, and before it finishes onCreateOptionsMenu is called.
I'm trying to separate the Fragment navigation code in my app, so I have a couple of objects that I delegate onCreateOptionsMenu to depending on if the app is running on phone/tablet (I'm using screen size to determine this, my layout file for large screens has a View I check for after the layout is inflated). The problem I'm having is, I create these objects in onCreate, and I'm getting a null pointer exception when I reference the object in onCreateOptionsMenu.
The onCreate method is called first, and before it finishes onCreateOptionsMenu is called.
That will be true on devices and apps with an official Honeycomb-style action bar. If there is no action bar, onCreateOptionsMenu() should not get called until the user calls up the menu, typically by pressing the MENU button.
(I'm using screen size to determine this, my layout file for large screens has a View I check for after the layout is inflated)
That test will break very shortly, once Ice Cream Sandwich ships. From what I can tell, ICS phones will have action bars (though perhaps not system bars).
In my case on Android 2.3 and with FragmentActivity from v4-support library the order of life-cycle methods invoke is following:
07-18 18:29:21.629 20183-20183/? I/onCreate:
07-18 18:29:21.719 20183-20183/? I/onStart:
07-18 18:29:21.719 20183-20183/? I/onResume:
07-18 18:29:21.739 20183-20183/? I/onCreateOptionsMenu:
I found if in onResume() I call
invalidateOptionsMenu();
then onCreateOptionsMenu(Menu menu) is called afterward - as per the activity life cycle (I think that's the correct term here), as indicated by #tir38
#Override
public void onResume() {
super.onResume();
invalidateOptionsMenu();
}
Addition in above answer,
In case of ICS and Honeycomb onCreateOptionsMenu is called after onCreate and onPostCreate while in Gingerbread and earlier versions it is called after onCreate but before onPostCreate. Thats the only difference I found.
In my experience ActionBarActivity from support v7 onCreateOptionsMenu() called in setContentView() method in the middle of onCreate() it is appear on 4.1.1.
But on 4.4 another story onCreateOptionMenu() called after onCreate(). Also I don't know it may be immediately after, maybe not. But is fact after. I didn't test on other versions but 4.1.1 is first where I had have a trouble with init order.
i suggest to create a callback-function in your fragment to avoid timing issues with onResume() and onCreateOptionsMenu().
doing the following works flawless for me:
create and add your fragment to your activity
leave a reference of this fragment in your activity
create a public method doSomethingWithTheMenu() in your fragment
call this method from within your activity when onCreateOptionsMenu(Menu menu) is called.
example:
#Override
public boolean onCreateOptionsMenu(Menu menu) {
if (this.myFragment != null) {
this.myFragment.doSomethingWithTheMenu(menu);
}
return true;
}
I am using tabs, with Activity groups in each. I want to add an options menu to certain activities but it won't show on any. I have options menus working in other projects with the exact same code, so I can't figure out why they won't show up. This is the code I am using:
#Override
public boolean onCreateOptionsMenu(Menu menu) {
menu.add("Option 1");
menu.add("Option 2");
menu.add("Option 3");
return super.onCreateOptionsMenu(menu);
}
Is there anything wrong with this code or anywhere else I should be looking at that might be blocking this menu from showing when I hit the menu button?
The only thing that would be blocking the menu AFAIK would be if you are overriding onKeyDown. Make sure you aren't overriding that method and thus preventing the menu button from doing what it is supposed to.
I have a screen layout that is forced to be potrait mode. Because it is very complex I don't have the time right now to invest creating a separate one for landscape mode. It also doesn't make much sense for my type of application.
However, for input fields it's better to provide a landscape mode, because some phones have a hardware keyboard, which automatically aligns the phone in landscape and therefor makes it hard to look at the app that is still in portrait mode.
My solution to this is to put all text input into a dialog and temporarily enable landscape mode (if requested by the user) until the dialog is dismissed again.
This works perfectly. Except of the overlaying search widget (when pressing the search button from my application). I'm looking for two callbacks: one, when the search widget is raised (I cannot listen to the search button, because I sometimes raise it manually via a soft button) and when it is dismissed again (regardless if the search was finally triggered or canceled - it needs to work for both cases).
Any suggestions?
There is an Activity callback for when search is activated. onSearchRequested()
For the dismiss/cancel of the search widget, you can add listeners via the SearchManager:
SearchManager.OnCancelListener
SearchManager.OnDismissListener
Get a reference to your SearchManager with:
context.getSystemService(Context.SEARCH_SERVICE)
see getSystemService()
When using the Search Widget you can use the OnActionExpandListener on the associated action bars menu item. This also works great with the AppCompat Support Library for API versions below 14.
The OnActionExpandListener has two methods:
onMenuItemActionCollapse
onMenuItemActionExpand
See some code example below:
SearchManager searchManager = (SearchManager) getSystemService(Context.SEARCH_SERVICE);
MenuItem searchItem = menu.findItem(R.id.action_search);
MenuItemCompat.setOnActionExpandListener(searchItem, new MenuItemCompat.OnActionExpandListener(){
#Override
public boolean onMenuItemActionCollapse(MenuItem item) {
KLog.i(TAG, "onMenuItemActionCollapse");
return true;
}
#Override
public boolean onMenuItemActionExpand(MenuItem item) {
KLog.i(TAG, "onMenuItemActionExpand");
return true;
}
});
mSearchView = (SearchView) MenuItemCompat.getActionView(searchItem);
mSearchView.setSearchableInfo(searchManager.getSearchableInfo(getComponentName()));
In case you do not use the Support Library use the OnActionExpandListener on the menu item directly.