Titanium JIRA Archive
Appcelerator Community (AC)

[AC-989] Android: lack of clarity or consistency with onCreateOptionsMenu, onPrepareOptionsMenu

GitHub Issuen/a
TypeBug
Priorityn/a
StatusResolved
ResolutionDuplicate
Resolution Date2014-05-19T05:13:41.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsTitanium SDK & CLI
Labelsactionbar, android, menu, triage
ReporterMark Mokryn
AssigneeRitu Agrawal
Created2014-05-01T09:28:16.000+0000
Updated2016-03-08T07:37:19.000+0000

Description

The good news is that with AppCompat TabGroups and Windows share the same base class - ActionBarActivity, and starting with 3.3.0 onCreateOptionsMenu is called when the activity is started across all Android versions. See http://developer.android.com/guide/topics/ui/menus.html The developer guide also states: "However, you should use onCreateOptionsMenu() only to create the initial menu state and not to make changes during the activity lifecycle." This is where the problems begin: *For TabGroups, the activity property is only valid after the TabGroup open event*. If the dev wants to set menu options - that should be the time to set activity.onCreateOptionsMenu - *and not call* activity.invalidateOptionsMenu after onCreateOptionsMenu was set! The example in the docs is wrong on this point. The reason to not call invalidateOptionsMenu() is that there is no options menu to invalidate at this point! Apparently, on Gingerbread this has no effect, but on Jelly Bean I have seen very strange behavior on occasion due to this issue. If you set debug logging on the SDK, you will see that onCreateOptionsMenu is actually called twice in this case, and apparently the first time is too early for the system, thus nasty behavior on occasion. *In the case of Window objects*, however, the system calls onCreateOptionsMenu *prior* to the open event. So for 3.3.0 at this time the correct behavior is to set onCreateOptionsMenu *prior to the window opening*, and again - not call invalidateOptionsMenu. In general, if invalidateOptionsMenu is called, it should be done *after* the initial call to onCreateOptionsMenu - and we don't have a suitable event in the SDK for this, at this time. Proposal: 1. Clearly state in the documentation that TabGroup.activity.onCreateOptionsMenu should be set during the TabGroup open event handler, and that Window.activity.onCreateOptionsMenu should be set as soon as the Window is created. And of course *not call* invalidateOptionsMenu after either. 2. Never call invalidateOptionsMenu before there was a valid options menu prior. 3. The safest solution is set onCreateOptionsMenu in the TabGroup and Window initialization dictionary. 4. onPrepareOptionsMenu is probably used more often that it should be. Looking in the Android docs, http://developer.android.com/reference/android/app/Activity.html#onCreateOptionsMenu%28android.view.Menu%29 state "You can safely hold on to menu (and any items created from it), making modifications to it as desired, until the next time onCreateOptionsMenu() is called. "

Comments

  1. Mark Mokryn 2014-05-01

    Just to make this issue even more clear: the root cause is that onCreateOptionsMenu is not in the TabGroup and Window creation dictionary.
  2. Mark Mokryn 2014-05-18

  3. Ritu Agrawal 2014-05-19

    Resolving this as a duplicate of TIMOB-16889 as suggested by the reporter. Reporter has also added relevant comments to TIMOB-16889 ticket.
  4. Mark Mokryn 2014-05-19

JSON Source