Override @OptionsMenu declared from super classes.

[mathieudebrito]

Hi there, It would be cool to be able to override OptionsMenu declared from super classes.
It would be really appreciated especially for stacked fragments.

@EActivity
@OptionsMenu(value=R.menu.my_menu, override=true)
public class MyFragment extends Fragment {
  // ...
}

Should produce :

@Override
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
  menu.clear();
  inflater.inflate(my.package.R.menu.rides_menu, menu);
  super.onCreateOptionsMenu(menu, inflater);
}

Best

[WonderCsabo]

I think we should fix #1067 instead.

[mathieudebrito]

@WonderCsabo I think it's not the same issue:

• in @OptionsItem doesn't allow subclasses to override menu item handling  #1067, we want to override the click handling in a subclass
• in Override @OptionsMenu declared from super classes. #1156, we want to override the menu in a stacked fragment

am I wrong ?

[WonderCsabo]

Nope, sorry, i am tired.

So it is clear that you do not want to inflate the menus defined in the superclasses, so you do not add the calls, right? But why do you want to call clear()?

[mathieudebrito]

My bad - I'm also tired :p
My idea is not to override from superclass, the title of this issue is wrong.

Actually, the problem is about stacked fragments: when you have more than 1 fragment added to the stack, AA stacks all the menus. So you can see the menus of each fragment in the stack. And so, even if others fragments are not displayed.

I would like to be able to display only the menu of the current fragment.

PS : May I edit the title of this issue ?

[WonderCsabo]

OK, i understand now. I am not sure about this feature, this is not too clean i think. But i accept that this could be useful in some cases. Also please note that @OptionsMenu also can be used with @EActivity, so if we introduce this feature, we have to decide what happens if someone uses this on an @EActivity.

PS: Yes, please do.

[mathieudebrito]

Ok, The title of this issus can remains the same, here is why :

Making possible to override the superclass menu would actually also override the stacked fragments menus. And the behavior would be the same for the @EActivity.
It would a 2 in 1.

Clean & Clear ?

[WonderCsabo]

Sorry, i cannot follow you.

[mathieudebrito]

I'm sorry, I'm making this difficult.

What I would like is to override the menu. So inflating a menu from a clear state.
2 situations :

• Overriding the menu of a parent
  I am in a ChildActivity that extends a ParentActivity.
  ParentActivity has its own menu.
  ChildActivity would like to override the parent menu to display its own menu.
  -> an override option in @optionsmenu would be perfect

-> The same for fragments (ChildFragment & ParentFragment)

• It appears that it also solves the stacked fragments issue :
  FragmentOne is added to the stack. It displays its menu.
  FragmentTwo is added to the stack. It displays its menu, unfortunately, the menu of FragmentOne is still there.
  FragmentTwo would like to override the menu.
  -> an override option in @optionsmenu would be perfect

The generated code for these 2 situations is exactly the same :

@Override
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
     menu.clear();
     inflater.inflate(my.package.R.menu.rides_menu, menu);
     super.onCreateOptionsMenu(menu, inflater);
}

[WonderCsabo]

Ok, i see now. And what if a Fragment wants to remove the other stacked menus, but wants to add the ones from its superclass? In that case your generated code would be incorrect. I do not think we should mix overriding menus from superclasses and overriding menus from other classes.

[mathieudebrito]

Well, it's actually the idea : overriding the menu (not depending on superclasses or other classes : whatever since the idea is to override the menu).

I am not the only one who struggles with this problem. Everyone using FragmentManager and stacked fragments are getting multiple menus.
@mathieuboniface already talked about that in #473

Here is what I have to do for now, and that's not very clean :

@EFragment(R.layout.my_layout)
@OptionsMenu(R.menu.my_menu)
public class MyFragment extends Fragment {
    ...
   @Override
    public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
        super.onCreateOptionsMenu(menu, inflater);

        menu.clear();
        inflater.inflate(R.menu.my_menu, menu);
    }
    ...
}

You asked : And what if a Fragment wants to remove the other stacked menus, but wants to add the ones from its superclass?

@EFragment(R.layout.my_layout)
@OptionsMenu(value = {R.menu.my_menu, R.menu.my_parent_menu}, override = true)
public class MyFragment extends Fragment {
    ...
}

If I may : how would you do if you have stacked fragments and wants to display only the current fragment menu ?

[WonderCsabo]

Yey, this is indeed an issue. Your proposal for my question can work, but it is not clean, since you have to replicate all menus added by parent classes in the @OptionsMenu annotation.

@yDelouis, @DayS what do you think about this?

[mathieudebrito]

Good point

[yDelouis]

I think we should handle the most frequent use case which is what we do.
For other use cases, the developer has to do the old way.

[mathieudebrito]

I would think using the fragments backstack (via FragmentManager) would be a very frequent use case.

[WonderCsabo]

@yDelouis WDYT?