Skip to content

Remplacement de preferencex-colorpicker par un colorpicker maison - #81

Open
Spriana wants to merge 3 commits into
FranckRJ:masterfrom
Spriana:remove-preferencex
Open

Remplacement de preferencex-colorpicker par un colorpicker maison#81
Spriana wants to merge 3 commits into
FranckRJ:masterfrom
Spriana:remove-preferencex

Conversation

@Spriana

@Spriana Spriana commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Ça vire les dépendances preferencex & preferencex-colorpicker, qui sont plus maintenus depuis 2020 (utilisait de la réflexion, dépendait de androidx.preference en 1.1.0 tandis que c’est en 1.2.1 depuis 2023).

Le colorpicker est réécrit en Kotlin et en drawables. Quelques changements visuels : le nombre de colonnes dépend de l’espace disponible (avant c’était 4, avec 411dp de large 5 s’affichent) et il y a désormais un bouton Cancel en bas, ce qui suit les autres « fenêtres » de choix de valeur de paramètre.

Les préférences déjà appliquées par les utilisateurs sont conservées.

androidx.preference est lui-même assez vieillot, plus de màj depuis 2023, et le plus simple est d’utiliser une méthode dépréciée de androidx.fragment depuis 2021. Il y a un SuppressWarnings (avec un commentaire) pour ça. Le raisonnement de Claude Opus :

Écarté volontairement, si tu veux trancher autrement :

  • […]
  • Déplacer l'ouverture du dialogue (newInstance + setTargetFragment + tag) du SettingsFragment vers le fichier Kotlin regrouperait tout le sélecteur au même endroit et retirerait le @SuppressWarnings("deprecation") de SettingsFragment — mais s'écarte de l'idiome androidx, où c'est le fragment de préférences qui montre. Je ne l'ai pas fait.

Tu as raison, et mon mot était faux — ce n'est pas un idiome, c'est de la dette non migrée dans androidx.preference. Vérifié :

La dépréciation vient d'androidx.fragment, pas de preference. Dans fragment-1.8.9, setTargetFragment et getTargetFragment portent bien @deprecated (depuis fragment 1.3.0, en 2021, au profit de l'API Fragment Result).

androidx.preference n'a jamais suivi. Dans le 1.2.1 décompilé, PreferenceFragmentCompat appelle lui-même setTargetFragment(this, 0) à deux endroits (dont son onDisplayPreferenceDialog), et PreferenceDialogFragmentCompat.onCreate lit getTargetFragment() puis jette IllegalStateException("Target fragment must implement TargetFragment interface") si ce n'est pas un TargetFragment. Autrement dit la lib impose l'appel déprécié à quiconque étend sa classe de dialogue — ce n'est pas un raccourci que j'ai pris.

Et ça ne sera pas corrigé : la dernière version publiée d'androidx.preference est la 1.2.1 (2023), il n'existe aucune ligne 1.3, pas même une alpha. La bibliothèque est gelée, Google poussant vers Compose.

Donc mon @SuppressWarnings absorbe la dette de la lib, pas la mienne. Mais il y a une sortie propre.

Maigre allègement de l’APK release, de 22 Ko.

Spriana and others added 3 commits July 21, 2026 14:08
ColorPickerPreference est une DialogPreference qui affiche la couleur retenue en pastille dans la ligne de réglage, et ouvre une grille de pastilles rondes où la couleur courante porte une coche. Choisir une pastille applique la couleur et ferme la boîte de dialogue, comme le faisait celle de preferencex.

La grille est un GridView en numColumns="auto_fit" : le nombre de colonnes suit la largeur disponible, ce que la lib obtenait via un FlexboxLayoutManager, donc via une dépendance de plus.

Les couleurs proposées et la couleur par défaut sont déclarées dans le XML de réglages par les attributs colorChoices et defaultColor, en remplacement de pref_colors et pref_currentColor. Les couleurs déjà enregistrées sont relues telles quelles : même fichier de préférences, mêmes clefs, toujours des entiers.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…erencex.

SettingsFragment étend désormais androidx.preference.PreferenceFragmentCompat, sa surcharge onCreatePreferencesFix redevient donc onCreatePreferences. La boîte de dialogue du sélecteur de couleur, que preferencex ouvrait via une table de correspondance interne, est ouverte par onDisplayPreferenceDialog.

La page « Style » référence maintenant ColorPickerPreference par son nom complet : preferencex ajoutait son paquet à ceux que le PreferenceInflater essaie par défaut, ce qui autorisait le tag court <ColorPickerPreference> mais reposait sur un remplacement par réflexion du PreferenceManager, que R8 cassait.

androidx.preference.EditTextPreference ignore l'android:inputType posé sur la préférence, contrairement à celle de preferencex. Le clavier numérique est donc demandé depuis initFilterIfNeeded, à partir du même PrefsManager qui dit déjà quelles préférences sont des entiers, et l'attribut devenu mort est retiré des XML.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…idx.preference.

preferencex n'apportait plus que le sélecteur de couleur, désormais interne, et l'application d'android:inputType aux champs texte, désormais faite par SettingsFragment. androidx.preference, jusqu'ici tiré en transitif en 1.1.0, devient une dépendance directe en 1.2.1.

Partent avec elles preferencex-colorpicker, colorpicker et flexbox, soit 21 Ko de moins sur l'APK de release, ainsi que les règles keep qui protégeaient de R8 le remplacement par réflexion du PreferenceManager.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant