Fragments déconseillés dans Android P
Je regardais le documentation et ai trouvé ceci
Cette classe était obsolète dans le niveau API P.
Pourquoi les fragments sont-ils déconseillés dans Android P?
La réécriture dans Support Library 27.1.0
Le post de Ian (28 février 2018) nous donne une explication à ce sujet. Il est Android Framework Developer chez Google.
Chargeurs dans la bibliothèque de support 27.1.0
Pour la bibliothèque de support 27.1.0, j'ai réécrit les éléments internes de LoaderManager, la classe alimentant l'API Loaders, et je voulais expliquer le raisonnement qui sous-tendait les modifications et ce qu'il fallait attendre de l'avenir.
Chargeurs et fragments, un historique
Dès le début, Loaders et Fragments étaient assez étroitement liés ensemble à la hanche. Cela signifiait qu'une grande partie du code dans FragmentActivity et Fragment étaient là pour prendre en charge Loaders, malgré le fait qu'il y ait effectivement assez d'indépendance. …Ce qui a changé dans 27.1.0
Avec 27.1.0, la dette technique de Loaders a été considérablement réduite:……
Remarque: évidemment, ces modifications s'appliquent uniquement aux chargeurs de bibliothèque de support. Si vous utilisez Android framework Loaders, veuillez basculer sur Chargeurs de la bibliothèque de support dès que possible. Aucune correction de bogue ou amélioration n’est prévue pour les API Loader de la structure.
Il semble que le code dans Fragment et FragmentActivity ait été refactoré afin de faire de Loaders une dépendance optionnelle.
Selon la note de version , la nouvelle implémentation est basée sur Lifecycle.
Changements importants
L'implémentation sous-jacente de Loaders a été réécrite pour utiliser cycle de vie .
Composants d'architecture
Dans Support Library 26.1. , Fragment et FragmentActivity a adopté Lifecycle.
Cette version spéciale intègre la bibliothèque de support avec les cycles de vie des composants d’architecture. Si vous n’utilisez pas la bibliothèque Lifecycles, vous n’avez pas besoin de mettre à jour à partir de 26.0.2. Pour plus d'informations, consultez les notes de publication des composants d'architecture.
Changements importants
- Fragment et FragmentActivity (la classe de base pour AppCompatActivity) implémentent désormais l'interface LifecycleOwner à partir de Composants d'architecture.
En revanche, fragment et activité sous AndroidP n'ont pas implémenté l'interface LifecycleOwner.
Dans l'article Google+ (mentionné dans réponse de ThanosFisherman ), Ian a fait un commentaire:
vous ne pouvez pas changer le code du framework après son envoi - il est littéralement figé dans le temps. Cela signifie pas de nouvelles fonctionnalités et surtout pas de corrections de bugs. Ce n’est pas une bonne expérience pour les développeurs, en particulier lorsque nous disposons d’une version entièrement prise en charge, actualisée et rétro-compatible dans la bibliothèque de support.
Je pense que c’est la raison pour laquelle AndroidP n’adopte pas Lifecycle. Par conséquent, Fragment est obsolète dans Android P.
Les fragments de la bibliothèque de soutien sont là pour rester. Google vous encourage à utiliser les versions de la bibliothèque de support pour obtenir un comportement cohérent à travers tous les niveaux d'API, les correctifs de bogues rapportés et le support de Lifecycle and ViewModel.