Android - Correct Use of Invalidateoptionsmenu()

invalidateOptionsMenu() deprecated

They're deprecating this method in favor of calling invalidateOptionsMenu directly on the Activity (which this method actually does, internally). In order to replace it, you can do something like requireActivity().invalidateOptionsMenu().

invalidateOptionsMenu doesn't work in fragment

For updating the onCreateOptionsMenu inside the fragment you need to call the setHasOptionsMenu(true); inside the onCreate method of the fragment. Otherwise you won't be able to update it when you call getActivity().invalidateOptionsMenu();

sample:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setHasOptionsMenu(true);
}

EDIT:

@Override
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
        if(seachEditText.getText().toString().length() > 0)
        {
            menu.findItem(R.id.action_search).setVisible(true);
        }
        else
        {
            menu.findItem(R.id.action_search).setVisible(false);
        }
    super.onCreateOptionsMenu(menu, inflater);

}

What's the advantage of calling invalidateOptionsMenu when wanting to alter the created menu?

You should only really be inflating your options menu within onCreateOptionsMenu().

when all of this could be done if you only holded the Menu reference localy

You can do this locally via the method onPrepareOptionsMenu(Menu menu). This would actually be a great place to set a menu item's visibility. As to the question of the significance to the call invalidateOptionsMenu(); it's purpose should be looked at from two viewpoints.

Before API 11 and the introduction of fragments, the call to invalidateOptionsMenu would signal that the methods onCreateOptionsMenu() and onPrepareOptionsMenu() should be called again. Since activities normally have only one options menu, the menu object could afford to be kept in memory so as to make subsequent calls to onCreateOptionsMenu() more responsive.

Since the release of API 11, the options menu could no longer be stored in memory as before, since the introduction of fragments meant that the activity as well as each of its fragments could have its own options menu, and as fragments can be changed dynamically during the lifetime of the activity, it would be inefficient to store a bunch of options menus for each fragment as these fragments would not be guaranteed to stay on screen. Remember as well that in API 11+, options menu items can be displayed on the action bar. Changing your phone's configuration from portrait to landscape would mean more options menu items could be displayed on the action bar, thus items present in the overflow menu could now be moved to the action bar itself. An alternate albeit slower solution would be to simply rebuild all onscreen fragments' options menus from scratch. So for API 11+, the call to invalidateOptionsMenu() can be viewed as a signal to indicate that the layout of an activity's fragments have changed, and that the methods onCreateOptionsMenu() and onPrepareOptionsMenu() should be called for both the activity and the fragments it is currently hosting.

Check out the entry on invalidateOptionsMenu(Activity activity) here for more information as to why invalidateOptionsMenu is used.

use invalidateOptionsMenu inside BaseAdapter

You cant call invalidateOptionsMenu() as there is no such method in base adapter. What you can do is pass your activity as context to base adapter and call as below.

        ((YourActivity)context).invalidateOptionsMenu();

Also calling ActivityCompat.invalidateOptionsMenu() will through NPE as you are calling invalidateOptionsMenu on a class and not an object.

---

Related Topics