PreferenceFragment a été volontairement exclue depuis le package de compatibilité ?

Question

Je suis à la recherche d'écrire des préférences qui peuvent être appliquées à la fois 3.0 et pré-3.0 périphériques. En découvrant qu' PreferenceActivity contient des méthodes obsolètes (bien que ceux-ci sont utilisés dans l'exemple de code), j'ai regardé PreferenceFragement et le package de compatibilité pour résoudre mes malheurs.

Il semble, cependant, que PreferenceFragment n'est pas dans le package de compatibilité. Quelqu'un peut-il me dire si c'était intentionnel? Si oui, puis-je cibler facilement une large gamme d'appareils (c'est à dire < 3.0 et >=3.0) ou vais-je avoir à sauter à travers des cerceaux? Si ce n'était pas intentionnellement exclu, peut-on s'attendre à une nouvelle version du package de compatibilité? Ou est-il une autre solution qui est sûr à utiliser?

Cheers

James

Answer 1

Découvrir que PreferenceActivity contient des méthodes obsolètes (bien que ceux-ci sont utilisés dans l'exemple de code)

Les méthodes obsolètes sont obsolètes comme d'Android 3.0. Ils sont parfaitement bien sur toutes les versions d'Android, mais la direction est d'utiliser PreferenceFragment sur Android 3.0 et supérieur.

Quelqu'un peut-il me dire si c'était intentionnel?

Ma conjecture est que c'est une question de temps d'ingénierie, mais c'est juste une supposition.

Si oui, puis-je cibler facilement une large gamme d'appareils (c'est à dire < 3.0 et >=3.0) ou vais-je avoir à sauter à travers des cerceaux?

Je considère que c'est fait "facilement". A deux distincts PreferenceActivity des implémentations, en utilisant de préférence les en-têtes et PreferenceFragments, l'autre à l'aide de l'approche originale. Choisir la bonne au point de besoin (par exemple, lorsque l'utilisateur clique sur l'élément de menu options). Voici un exemple de projet de le démontrer. Ou, ont un seul PreferenceActivity qui gère les deux cas, comme dans cet exemple de projet.

Si ce n'était pas intentionnellement exclu, peut-on s'attendre à une nouvelle version du package de compatibilité?

Vous trouverez, quand le reste de nous trouver, c'est-à-dire, si et quand il les navires.

Ou est-il une autre solution qui est sûr à utiliser?

Voir ci-dessus.

Answer 2

L'implication subtile de la réponse de @CommonsWare est que votre application doit choisir entre la compatibilité de l'API ou de l'intégré dans le fragment de l'API (depuis le SDK 11). En fait, c'est ce que le "facilement" recommandation a fait. En d'autres termes, si vous souhaitez utiliser PreferenceFragment votre application doit utiliser le haut-fragment de l'API et de traiter avec les méthodes obsolètes sur PreferenceActivity. À l'inverse, s'il est important que votre application utiliser le compat. API, vous serez confronté à ne pas avoir un PreferenceFragment classe. Ainsi, le ciblage des dispositifs n'est pas un problème, mais le cercle-le saut se produit lorsque vous avez à choisir l'un ou l'autre API et donc soumettre votre conception des solutions de contournement. J'ai besoin de la compat. API, donc je vais créer mon propre PreferenceFragment de classe et voir comment cela fonctionne. Dans le pire des cas, je vais créer un normal (fragment) mise en page et de lier la vue des composants de la sharedprefs manuellement...pouah.

EDIT: Après avoir essayé et en regardant le code à http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.1_r1/android/preference/PreferenceFragment.java?av=h -- la création de mon propre PreferenceFragment ne va pas arriver. Il semble que l'utilisation libérale de colis-privé dans PreferenceManager au lieu de "protégés" en est le principal bloquant. Il n'a vraiment pas l'air comme il n'y a aucune sécurité ni vraiment bonne motivation pour avoir fait ça et il n'est pas très grande pour les tests unitaires mais bon...moins de frappe je suppose...

EDIT v2: En fait c'est arrivé et cela a fonctionné. C'était certainement un casse-tête pour rendre le code du travail avec la Compatibilité de l'API JAR. J'ai eu de copie environ 70% de la com.android.la préférence d'un package à partir du kit de développement SDK pour mon application et puis battre avec généralement de médiocre qualité de code Java dans Android. J'ai utilisé v14 du SDK. Il aurait été beaucoup plus facile pour un Goog ingénieur pour faire ce que j'ai fait, contrairement à ce que j'ai entendu dire que certains plomb Android ingénieurs dire sur ce sujet.

BTW - j'ai dit "ciblage des dispositifs n'est pas un problème"? Il est totalement...si vous utilisez com.android.de préférence, vous n'allez pas être en mesure d'échanger avec la Compatibilité de l'API sans modification majeure. Amusant journal!

Answer 3

Bâtiment sur CommonsWare de la réponse ainsi que Tenace' observations, j'en suis venu avec une seule classe descendante solution capable de cibler toutes les API Android versions avec un minimum de tracas et pas de code ou de duplication des ressources. Veuillez voir ma réponse à la question 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 que d'un téléphone sous 4.0.4 et 2.3.3 et aussi un émulateur de course 1.6.

Answer 4

Voir PreferenceFragment-Compat de Machinarius. Il était facile de tomber dedans avec gradle et j’oublie qu’il est encore là.

``

Answer 5

Tenace réponse est bonne, mais voici plus de détails.

La raison pour laquelle vous ne pouvez pas créer une mise en page normale et lier la vue des composants de la sharedprefs manuellement", c'est que il y a quelques surprenant omissions dans l'android.les préférences de l'API. PreferenceActivity et PreferenceFragment les deux ont accès à des non-public PreferenceManager méthodes, sans laquelle vous ne pouvez pas mettre en œuvre une préférence de l'INTERFACE utilisateur de votre propre.

En particulier, il n'y a pas d'API publique pour la construction d'une Préférence de la hiérarchie à partir d'un fichier XML, et la méthode de fixation de la Préférence onClick auditeurs à votre activité colis-privé.

Et vous ne pouvez pas contourner ce par sournoisement de mettre votre application dans l'android.préférences paquet, parce que les non-public des méthodes sur Android Api sont effectivement omis de le SDK. Avec un peu de créativité impliquant la réflexion et la dynamique des procurations, vous pouvez toujours les retrouver. La seule alternative, aussi Tenaces dit, est la fourche à l'ensemble de android.de préférence, y compris au moins 15 classes, 5 mises en page, et un nombre similaire de style.xml et attrs.xml éléments.

Donc, pour répondre à la question d'origine, la raison pour laquelle Google ne comprend pas PreferenceFragment dans le package de compatibilité est qu'ils ont eu exactement le même niveau de difficulté que Tenace et moi-même. Même Google ne peut pas remonter le temps et de rendre ces méthodes publiques dans les anciennes plates-formes (bien que l'on devrait absolument faire dans les prochaines versions).