oreo - Fragmentos obsoletos en Android P
android sdk android developers (2)
La reescritura en la biblioteca de soporte 27.1.0
El post mediano de Ian (28 de febrero de 2018) nos da una explicación al respecto. Él es el desarrollador de Android Framework en Google.
Cargadores en la biblioteca de soporte 27.1.0
Para la biblioteca de soporte 27.1.0, reescribí los aspectos internos de LoaderManager, la clase que impulsa la API de los cargadores y quería explicar el razonamiento detrás de los cambios y qué esperar en el futuro.
Cargadores y Fragmentos, una historia.
Desde el principio, los cargadores y los fragmentos estaban muy unidos entre sí por la cadera. Esto significaba que gran parte del código en FragmentActivity y Fragment estaba allí para apoyar a los cargadores, a pesar del hecho de que en realidad son bastante independientes. ...Lo que ha cambiado en 27.1.0
Con 27.1.0, la deuda técnica de los cargadores se ha reducido considerablemente: ......
Nota: Obviamente, estos cambios solo se aplican a los cargadores de biblioteca de soporte. Si está utilizando los cargadores de Android Framework, cambie a los cargadores de biblioteca de soporte lo antes posible. No hay correcciones de errores ni mejoras planificadas para las API del cargador del marco.
Parece que el código en Fragment y FragmentActivity ha sido refactorizado para que los cargadores sean una dependencia opcional.
De acuerdo con la nota de lanzamiento , la nueva implementación se basa en Lifecycle .
Cambios importantes
La implementación subyacente de los Loaders se ha reescrito para usar el Lifecycle .
Componentes de Arquitectura
En la biblioteca de soporte 26.1.0 , Fragment y FragmentActivity ha adoptado Lifecycle .
Esta es una versión especial para integrar la biblioteca de soporte con ciclos de vida de los componentes de arquitectura. Si no está utilizando la biblioteca Lifecycles, no necesita actualizar desde 26.0.2. Para obtener más información, consulte las notas de la versión de Componentes de Arquitectura.
Cambios importantes
- Fragment y FragmentActivity (la clase base para AppCompatActivity) ahora implementa la interfaz LifecycleOwner de los Componentes de Arquitectura.
Por el contrario, documentation y Activity en Android P no han implementado la interfaz LifecycleOwner .
En la publicación de Google+ (mencionada en la respuesta de ThanosFisherman ), Ian hizo un comentario:
no se puede cambiar el código del marco una vez que se ha enviado, está literalmente congelado en el tiempo. Eso significa que no hay nuevas características y, lo que es más importante, no hay corrección de errores Esa no es una buena experiencia de desarrollador, especialmente cuando tenemos una versión totalmente compatible, actualizada y con versiones anteriores en la Biblioteca de soporte.
Creo que esa es la razón por la que Android P no adopta Lifecycle . En consecuencia Fragment está en desuso en Android P.
Estaba mirando la documentation y encontré esto.
Esta clase fue desaprobada en el nivel de API P.
¿Por qué los fragmentos están obsoletos en Android P?
Los fragmentos de la biblioteca de soporte están aquí para quedarse. Google lo alienta a usar las versiones de la Biblioteca de soporte para obtener un comportamiento consistente en todos los niveles de API, correcciones de errores de backported y soporte de ciclo de vida y ViewModel.