android - studio - Fragmento o fragmento de soporte?
get fragment by tag android (5)
Desde mi experiencia, usar la misma implementación de fragmentos en todos los dispositivos Android es una gran ventaja. No pude deshacerme de todas las NullPointerExceptions cuando el estado se guarda en Android 4.0 utilizando fragmentos nativos, con la biblioteca de soporte que todos se han ido. Además, no pude ver ninguna desventaja hasta ahora con este enfoque.
Así que mi respuesta a mi propia pregunta es ahora: cuando desarrolles para Android 4.x, usar los fragmentos de la biblioteca de soporte es una buena idea. La biblioteca de soporte tiene errores corregidos que todavía están presentes en las implementaciones de fragmentos más antiguos y se actualizan frecuentemente con más correcciones de errores.
Estoy desarrollando una aplicación que admite Android> = 4.0. Utiliza fragmentos del paquete android.app . Como estoy enfrentando problemas con la implementación de fragmentos más antigua en 4.0, como esta , que ya están solucionados en la biblioteca de soporte, estoy considerando volver a la implementación de fragmentos de la biblioteca de soporte para obtener una implementación más confiable y consistente.
¿Qué opinas de esto? ¿Estás utilizando fragmentos de la biblioteca de soporte, a pesar de que ya están disponibles, al desarrollar para Android 4?
En mi humilde opinión, si planea desarrollar solo para 4.0, le recomiendo que vaya con las bibliotecas nativas, ya que el ejecutable se hará más pequeño. Es cierto que puede encontrarse con problemas de errores en las primeras versiones, pero creo que la mayoría de estos deberían ser bastante triviales. Además, se supone que la biblioteca de compatibilidad se correlaciona con los fragmentos nativos en caso de que se ejecute en 4.0 y superior de todos modos. Entonces, de todos modos, podrías terminar teniendo problemas con este tipo de problemas. El problema con las bibliotecas de soporte es que tiene muchas de las clases que aparecen 2 veces (una en la estructura del paquete de soporte y otra en la estructura de paquete "nativo") que hace que el desarrollo sea un poco más engorroso.
Sin embargo, si también desea lanzar su aplicación pre 4.0, entonces no hay forma de evitar la biblioteca de soporte. Además, dado que hay aproximadamente el 38% de todos los usuarios en 2.3, podría tener sentido comercial incluir esta versión del sistema operativo. En tal caso, puede utilizar la biblioteca de soporte en combinación con Jake Wartons ActionBarSherlock (o con los googles compatibles con ActionBar Library una vez que finalmente se haya liberado).
Parece que es mejor usar Support Library ahora porque vi la declaración aquí https://developer.android.com/reference/android/app/Fragment.html
Esta clase ha quedado obsoleta en el nivel de API P. Utilice el Fragmento de biblioteca de soporte para un comportamiento consistente en todos los dispositivos y acceso a Lifecycle.
También me sentía frustrado al tener que incluir las bibliotecas de soporte, a pesar de apuntar a Android 4.0+, pero parece que se recomienda oficialmente:
El paquete de la Biblioteca de soporte de Android contiene varias bibliotecas que se pueden incluir en su aplicación. Cada una de estas bibliotecas admite un rango específico de versiones de plataforma Android y un conjunto de características.
Esta guía explica las características importantes y el soporte de versiones proporcionados por las bibliotecas de soporte para ayudarlo a decidir cuál de ellos debe incluir en su aplicación. En general, recomendamos incluir las bibliotecas v4 de compatibilidad y v7 appcompat, ya que admiten una amplia gama de versiones de Android y proporcionan API para patrones de interfaz de usuario recomendados.
http://developer.android.com/tools/support-library/features.html
Una razón importante para quedarse con el SupportFragment por un tiempo es que no tiene acceso al ChildFragmentManager hasta API 17. La biblioteca de soporte le dará una versión de soporte del administrador de fragmentos hijo.
Esto se convierte en un gran problema si tienes fragmentos que contienen otros fragmentos. Esto es común en las aplicaciones de tableta con una gran complejidad y / o su arquitectura general se basa en un diseño con pestañas o utiliza el cajón de navegación.