He leído la documentación y algunos hilos de otras preguntas sobre este tema y realmente no me siento convencido; No veo claramente los límites de uso de esta técnica.
Los fragmentos ahora se ven como una mejor práctica ; cada Actividad debería ser básicamente un soporte para uno o más Fragmentos y no llamar a un diseño directamente.
Se crean fragmentos para:
Permitir el
Activity
uso de muchos fragmentos, cambiar entre ellos, reutilizar estas unidades ... ==>Fragment
depende totalmente de laContext
actividad, por lo que si necesito algo genérico que pueda reutilizar y manejar en muchas Actividades, puedo crear mis propios diseños o Vistas personalizadas ... No me interesará esta Capa de Desarrollo de Complejidad adicional que agregarían fragmentos.un mejor manejo a una resolución diferente ==> OK para tabletas / teléfonos en caso de un proceso largo que podemos mostrar dos (o más) fragmentos en la misma Actividad en Tabletas, y uno por uno en los teléfonos. Pero, ¿por qué usaría fragmentos siempre ?
manejo de devoluciones de llamada para navegar entre Fragmentos (es decir: si el usuario ha iniciado sesión, muestro un fragmento; de lo contrario, muestro otro fragmento). ===> Solo trata de ver cuántos errores tiene Facebook SDK Log-in debido a esto, para entender que realmente es (?) ...
teniendo en cuenta que una aplicación de Android se basa en actividades ... Agregar otros ciclos de vida en la actividad sería mejor diseñar una aplicación ... Me refiero a que los módulos, los escenarios, la gestión de datos y la conectividad estarían mejor diseñados, en ese sentido camino. ===> Esta es una respuesta de alguien que solía ver el SDK de Android y el Marco de Android con una visión de Fragmentos. No creo que esté mal, pero no estoy seguro de que dé buenos resultados ... Y es realmente abstracto ...
====> ¿Por qué complicaría mi vida, codificando más, al usarlos siempre? De lo contrario, ¿por qué es una mejor práctica si es solo una herramienta para algunos casos? ¿Cuáles son estos casos?