866352 - "Up" behavior in Settings ActionBar broken for nested xml preference screens

Status: RESOLVED DUPLICATE of bug 833625

(Firefox for Android Graveyard :: General, defect)

Description

[Chenxia Liu [:liuche]]

If you use nesting of PreferenceScreens in xml to build tiered preferences screens, the icon in the action bar does nothing when clicked. (This looks like an Android bug.) Currently we don't use this, but we might want to do so in the future.

Building tiered preferences screens via xml is the easiest way to make nested preference screens, but AFAICT it's not possible to get a handle to the ActionBar object that is actually displayed. This is a problem in v14+ where you must explicitly enable the "up" behavior with actionBar.setHomeButtonEnabled().

The hack is to make each settings tier its own Activity, so you don't have to deal with this nesting ActionBar bug.

Basically, this involves lifting out an abstract GeckoPreferencesActivity (from GeckoPreferences) that has the basic settings screen behavior, and let all settings screens inherit from there, so every settings screen is a "first-tier" PreferenceScreen.

Other approaches are:
- leave the "up" button on second-tier screens broken
- remove the "up" arrow and "up" behavior from the ActionBar

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

This work could tie into work Wes is doing to make the Setting screen better organized.

Comment 2

[Chenxia Liu [:liuche]]

Attachment: Abstract out preferences screen v1

Abstract out preferences for preferences screen. Groundwork for nested (non-broken) PreferenceScreens+ActionBar.

This is almost a strict lift of shared parts of GeckoPreferences into and abstract GeckoPreferencesActivity, except for the following:
- requiring nested preference screens support multi-pane mode for tablets
- fixed a strict-mode error in setting the Title Bar pref

Comment 3

[Chenxia Liu [:liuche]]

Note: since GeckoPreferences is changed fairly frequently, I'll check for changes to GeckoPreferences and incorporate them, because they will require manual copying/lifting.

Comment 4

[Brian Nicholson (:bnicholson)]

Comment on attachment 743750 [details] [diff] [review]
Abstract out preferences screen v1

Looks like you forgot to add GeckoPreferencesActivity to your patch.

Comment 5

[Brian Nicholson (:bnicholson)]

Comment on attachment 743750 [details] [diff] [review]
Abstract out preferences screen v1

Err, flipped the wrong flag.

Comment 6

[Chenxia Liu [:liuche]]

Attachment: Abstract out preferences screen v2

Derp, added GeckoPreferencesActivity.

Comment 7

[Chenxia Liu [:liuche]]

Ian, some input from you: I've been talking to Brian and Wes about the higher complexity that this hack adds, and I was wondering if you think it'd be acceptable to leave off the "up" arrows in the settings menu. On further thought, I don't think it's very easy to fake the "up" behavior.

As I see it, the up functionality is useful for navigating through the levels of an app if the user has been redirected there from somewhere else; in that case, the back button has a different functionality, returning the user to whichever app did the redirect.

Anyways, what is your opinion of removing the "up" arrow in the Fennec settings action bar?

I've posted two apks on people if you want to try them out. "Data choices" is the only nested screen at the moment.
https://people.mozilla.com/~liuche/bug-866352/

Comment 8

[Ian Barlow (:ibarlow)]

Hm, I definitely find myself missing the Up arrow when it's not there... 

I also notice that some Google apps (Gmail, Calendar, Chrome) have the up arrow in nested Settings lists, while others strangely do not (Maps, for one). Any idea what apps like Gmail and Chrome might be doing that we aren't? It would be great to keep the up arrow if we can.

Comment 9

[Chenxia Liu [:liuche]]

I was playing around Gmail this morning, and it appears that each level is a separate activity, so they won't be running into the action bar problem. I'm not sure exactly how they do the "up" behavior, but it's possible that they hard-code an "up" hierarchy (a guess on my part).

Chrome seems to do something different which is interesting, and I'll investigate a little more - thanks for the feedback, Ian!

Comment 10

[Chenxia Liu [:liuche]]

Closing this as invalid, because bug 833625 implements an approach for nesting Preference Screens, using Fragments for v11 and above and PreferenceScreen intents for versions less than v11. This approach does create xml resource duplication, so we might consider a fragment-only approach at some point, although this likely involves copying a lot of Android v11 code.