New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 710657 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Task



Sign in to add a comment

Investigate converting Preferences to use support library support.v7.preference.Preference (et al)

Project Member Reported by tedc...@chromium.org, Apr 11 2017

Issue description

From bsazonov's initial investigation:

"""
It looks like there's already a lot of code for adding/removing dividers: https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/preferences/ChromeSwitchPreference.java?l=56, https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/preferences/autofill/AndroidPaymentAppPreference.java?l=55, https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/preferences/SearchEnginePreference.java?l=55, and more.

We could solve all these divider problems once and forever would be using android.support.v7.preference.Preference instead of android.preference.Preference.

Pros:
1. android.support.v7.preference.PreferenceViewHolder has setDividerAllowedAbove & setDividerAllowedBelow, that would allow easy dividers management.
2. Using android.support.v7.preference.SwitchPreferenceCompat would allow us to get rid of ChromeSwitchPreference.
3. No minor workarounds like this one: https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/preferences/ChromeBaseListPreference.java?l=57.
4. Support library will (hopefully) provide more consistent appearance and behavior on different Android versions.
"""

One thing we'd need to verify is the APK size increase that would result from switching to app compat.  If it was a large increase, we might have to live with the current Preferences behavior.

Nearly all times that we have migrated to the support library (or updated the support library to major revs), we've run into compatibility and expectation issues between what Chrome and the support library expect.  While this could be a straightforward migration, it could also uncover oodles, and oodles of issues that we'd to address on multiple different Android platforms.
 

Comment 1 by ew...@chromium.org, Apr 12 2017

Cc: ew...@chromium.org
There's another reason for this migration: fragments not from SupportLibrary are getting deprecated in Android P (see note at https://developer.android.com/reference/android/app/Fragment.html).

I've tried replacing Chrome usages of android.app.Fragment with android.support.v4.app.Fragment a while ago, but it appeared to be unfeasible without switching to support library for Preferences, too. It's been a while ago, so I don't remember the details, sorry.
Is there any move on this issue? I wonder if there is any plan in progress internally or somewhere.
Components: UI>Browser>Mobile>Settings
Labels: Type-Task
I've taken a stab at this, but realized that this will take a significant amount of time. As far as I know, there are no immediate plans for this migration, sorry.

Can you please explain why you need this migration to happen? It may help us take the right decision when prioritizing this.
Another reason for this migration - it has onAttached(), onDetached(), and setVisible() methods in Preferences. These methods allow writing self-contained Preference subclasses that can listen for changes in other components and  appropriately update its visibility/content.

Sign in to add a comment