Je cherche à écrire des préférences qui peuvent être appliquées aux appareils 3.0 et pré-3.0. En découvrant que PreferenceActivity
contient des méthodes obsolètes (bien que celles-ci soient utilisées dans l'exemple de code qui l'accompagne), j'ai regardé PreferenceFragement
et le package de compatibilité pour résoudre mes problèmes.
Il semble cependant que ce PreferenceFragment
ne soit pas dans le package de compatibilité. Quelqu'un peut-il me dire si c'était intentionnel? Si tel est le cas, puis-je cibler facilement une gamme d'appareils (c'est-à-dire <3.0 et> = 3.0) ou dois-je sauter à travers des cerceaux? Si ce n'était pas intentionnellement exclu, pouvons-nous nous attendre à une nouvelle version du package de compatibilité? Ou existe-t-il une autre solution de contournement qui est sûre à utiliser?
À votre santé
James
PreferenceFragment
que vous oublierez même là. Voyez ma réponse ."Because most of Preferences' implementation is hidden, therefore impossible to backport without lots of hackery."
PreferenceFragmentCompat
a été récemment ajouté à la bibliothèque de support.Réponses:
Les méthodes obsolètes sont obsolètes à partir d'Android 3.0. Ils conviennent parfaitement à toutes les versions d'Android, mais la direction est de les utiliser
PreferenceFragment
sur Android 3.0 et supérieur.Je suppose que c'est une question de temps d'ingénierie, mais ce n'est qu'une supposition.
Je considère que cela se fait "facilement". Avoir deux
PreferenceActivity
implémentations distinctes , l'une utilisant des en-têtes de préférence etPreferenceFragments
l'autre utilisant l'approche d'origine. Choisissez le bon au moment où vous en avez besoin (par exemple, lorsque l'utilisateur clique sur l'élément du menu d'options). Voici un exemple de projet démontrant cela. Ou, ayez un seulPreferenceActivity
qui gère les deux cas, comme dans cet exemple de projet .Vous saurez quand le reste d'entre nous le saura, c'est-à-dire si et quand il sera expédié.
Voir au dessus.
la source
<include>
fonctionne avec la préférence XML. BTW, si vous êtes abonné, la mise à jour du livre faisant référence à ce projet a été annoncée il y a quelques minutes.L'implication subtile de la réponse de @CommonsWare est que - votre application doit choisir entre l'API de compatibilité ou l'API de fragment intégrée (depuis le SDK 11 ou plus). En fait, c'est ce que la recommandation «facile» a fait. En d'autres termes, si vous souhaitez utiliser PreferenceFragment, votre application doit utiliser l'API de fragment intégrée et gérer les méthodes obsolètes sur PreferenceActivity. Inversement, s'il est important que votre application utilise le fichier compat. API, vous serez confronté à ne pas avoir de classe PreferenceFragment du tout. Ainsi, le ciblage des appareils n'est pas un problème, mais le saut d'obstacles se produit lorsque vous devez choisir l'une ou l'autre API et ainsi soumettre votre conception à des solutions de contournement imprévues. J'ai besoin du compat. API donc je vais créer ma propre classe PreferenceFragment et voir comment cela fonctionne. Dans le pire des cas, je '
EDIT: Après avoir essayé et examiné le code à l' adresse http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.1_r1/android/preference/PreferenceFragment.java? av = h - créer mon propre PreferenceFragment ne se produira pas. Il semble que l'utilisation libérale de package-private dans PreferenceManager au lieu de «protected» soit le principal bloqueur. Il ne semble vraiment pas y avoir de sécurité ou de très bonne motivation pour avoir fait cela et ce n'est pas génial pour les tests unitaires, mais bon ... moins de frappe je suppose ...
EDIT v2: En fait, cela s'est produit et cela a fonctionné. C'était définitivement un casse-tête de faire fonctionner le code avec le JAR de l'API de compatibilité. J'ai dû copier environ 70% du package com.android.preference du SDK vers mon application, puis lutter avec un code Java de qualité médiocre sous Android. J'ai utilisé la v14 du SDK. Il aurait été beaucoup plus facile pour un ingénieur Google de faire ce que j'ai fait, contrairement à ce que j'ai entendu certains ingénieurs Android principaux dire à ce sujet.
BTW - ai-je dit "le ciblage des appareils n'est pas un problème"? C'est totalement ... si vous utilisez com.android.preference, vous ne pourrez pas échanger avec l'API de compatibilité sans refactorisation majeure. Journal amusant!
la source
En me basant sur la réponse de CommonsWare ainsi que sur les observations de Tenacious, j'ai mis au point une solution de classe descendante unique capable de cibler toutes les versions d'API Android actuelles avec un minimum de tracas et sans duplication de code ou de ressource. Veuillez voir ma réponse à la question connexe ici: PreferenceActivity Android 4.0 et versions antérieures
ou sur mon blog: http://www.blackmoonit.com/2012/07/all_api_prefsactivity/
Testé sur deux tablettes sous 4.0.3 et 4.0.4 ainsi qu'un téléphone sous 4.0.4 et 2.3.3 et également un émulateur sous 1.6.
la source
Voir PreferenceFragment-Compat de Machinarius. C'était facile de passer avec Gradle et j'oublie que c'est même là.
compile 'com.github.machinarius:preferencefragment:0.1.1'
Mise à jour importante: la dernière révision du
v7 support library
a désormais un PreferenceFragmentCompat natif .la source
En août 2015, Google a publié la nouvelle bibliothèque de support des préférences v7 .
Vous pouvez maintenant utiliser PreferenceFragmentCompat avec tout
Activity
ouAppCompatActivity
Vous devez définir
preferenceTheme
dans votre thème:De cette manière, vous pouvez personnaliser le
preferenceTheme
style des dispositions utilisées pour chaque type de préférence sans affecter les autres parties de votre activité.la source
La réponse de Tenacious est correcte, mais voici quelques détails supplémentaires.
La raison pour laquelle vous ne pouvez pas "créer une mise en page normale et lier manuellement les composants de vue aux sharedprefs" est qu'il y a des omissions surprenantes dans l'API android.preferences. PreferenceActivity et PreferenceFragment ont tous deux accès aux méthodes PreferenceManager non publiques critiques, sans lesquelles vous ne pouvez pas implémenter votre propre interface utilisateur de préférence.
En particulier, pour construire une hiérarchie de préférences à partir d'un fichier XML, vous devez utiliser un PreferenceManager, mais tous les constructeurs de PreferenceManager sont soit privés, soit masqués. La méthode pour attacher les écouteurs Preference onClick à votre activité est également privée de package.
Et vous ne pouvez pas contourner ce problème en plaçant sournoisement votre implémentation dans le package android.preferences, car les méthodes non publiques dans les API Android sont en fait omises du SDK. Avec un peu de créativité impliquant la réflexion et les procurations dynamiques, vous pouvez toujours les atteindre. La seule alternative, comme le dit Tenacious, est de bifurquer l'ensemble du package android.preference, y compris au moins 15 classes, 5 mises en page et un nombre similaire d'éléments style.xml et attrs.xml.
Donc, pour répondre à la question initiale, la raison pour laquelle Google n'a pas inclus PreferenceFragment dans le package de compatibilité est qu'ils auraient eu exactement la même difficulté que Tenacious et moi-même. Même Google ne peut pas remonter le temps et rendre ces méthodes publiques sur les anciennes plates-formes (même si j'espère qu'ils le feront dans les versions futures).
la source
Mon application cible est l'API +14, mais en raison de l'utilisation de la bibliothèque de support pour une navigation sophistiquée, je ne pouvais pas utiliser le
android.app.Fragment
et devais l'utiliserandroid.support.v4.app.Fragment
, mais j'avais également besoin de le mettrePreferenceFragment
en place sans modifications importantes du code.Donc, ma solution facile pour avoir les deux mondes de bibliothèque de support et
PreferenceFragment
:la source
J'avais besoin d'intégrer les préférences dans la conception de l'application et de conserver la prise en charge d'Android 2.3. J'avais donc encore besoin de PreferencesFragment.
Après quelques recherches, j'ai trouvé android-support-v4-preferencesfragment lib. Cette librairie vous fait gagner beaucoup de temps pour copier et refactoriser l'original PreferencesFragment comme l'a dit Tenacious. Fonctionne bien et les utilisateurs apprécient les préférences.
la source