Fragmento o fragmento de soporte?

Estoy desarrollando una aplicación que admite Android> = 4.0. Utiliza fragmentos del paquete android.app . Como estoy enfrentando problemas con la implementación del fragmento más antiguo en 4.0, como éste , que ya están arreglados en la biblioteca de soporte, estoy pensando en cambiar de nuevo a la implementación de fragmentos de la biblioteca de soporte para obtener una implementación más fiable y consistente.

¿Qué opinas de esto? ¿Está utilizando fragmentos de la biblioteca de soporte, aunque ya estén disponibles, al desarrollar Android 4?

Desde mi experiencia, el uso de 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 usando fragmentos nativos, con la biblioteca de soporte que todos han desaparecido. También no pude ver ninguna desventaja hasta ahora con este enfoque.

Así que mi respuesta a mi propia pregunta es ahora: Al desarrollar para Android 4.x, el uso de 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 actualiza frecuentemente con más arreglos de errores.

Una razón importante para seguir con el SupportFragment durante un tiempo es que no tiene acceso al ChildFragmentManager hasta la API 17. La biblioteca de soporte le proporcionará una versión de soporte del administrador de fragmentos secundarios.

Esto se convierte en una gran cosa si tienes fragmentos que contienen otros fragmentos. Esto es común en las aplicaciones de tableta con una gran cantidad de complejidad y / o su arquitectura general se basa en un diseño con pestañas o utiliza el cajón de navegación.

También estaba frustrado por tener que incluir las bibliotecas de soporte, a pesar de orientar 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 la aplicación. Cada una de estas bibliotecas soporta una gama específica de versiones de plataforma Android y un conjunto de características.

En esta guía se explican las funciones importantes y el soporte de versiones proporcionadas por las bibliotecas de soporte para ayudarle a decidir cuáles de ellas debe incluir en su aplicación. En general, recomendamos incluir el soporte v4 y las bibliotecas v7 appcompat, ya que admiten una amplia gama de versiones de Android y proporcionan API para los patrones de interfaz de usuario recomendados.

http://developer.android.com/tools/support-library/features.html

IMHO si usted está planeando desarrollar para 4.0 solamente, recomendaría el ir con las bibliotecas nativas puesto que el ejecutable conseguirá más pequeño. Es cierto que usted podría encontrarse con problemas de bugs en versiones anteriores, pero creo que la mayoría de éstas deberían ser bastante triviales para trabajar. También se supone que la biblioteca de compatibilidad se correlaciona con los fragmentos nativos en caso de que se esté ejecutando en 4.0 y superior de todos modos. Así que podría terminar teniendo que luchar con este tipo de problemas de todos modos. El problema con las bibliotecas de soporte es que tienes muchas de las clases que aparecen 2x (una vez en la estructura del paquete de soporte y una vez en la estructura del paquete "nativo") lo que hace que el desarrollo sea un poco más engorroso.

Sin embargo, si también desea liberar su aplicación antes de 4.0, entonces no hay forma de evitar la biblioteca de soporte. También, ya que hay alrededor del 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 googles de soporte de la biblioteca ActionBar una vez que finalmente se libera).