¿Por qué usar Fragmentos?
He leído la documentación y otras preguntas sobre este tema y no me siento realmente convencido; No veo claramente los límites de uso de esta técnica.
Los fragmentos se ven ahora como una mejor práctica ; Cada actividad debe ser básicamente un soporte para uno o más fragmentos y no llamar a un diseño directamente.
- ¿Por qué el perro String.format de android es lento?
- KitKat tarda 6 segundos más que Froyo para reaccionar a TextToSpeech.speak () en primera llamada
- Android: rendimiento de gson
- Cómo configurar el color de fondo para Textview de forma programática para otro archivo xml?
- Android, cálculo del hash SHA-1 desde el archivo, el algoritmo más rápido
Se crean fragmentos para:
-
Permitir que la
Activity
utilice muchos fragmentos, cambiar entre ellos, reutilizar estas unidades … ==> elFragment
es totalmente dependiente delContext
de una actividad, así que si necesito algo genérico que pueda reutilizar y manejar en muchas Actividades , Puedo crear mis propias disposiciones o vistas personalizadas … No me importará esta capa de desarrollo de complejidad adicional que añadirían fragmentos. -
Un mejor manejo a diferentes resoluciones ==> OK para tabletas / teléfonos en caso de 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 fragmentos siempre ?
-
Manejo de devoluciones de llamada para navegar entre Fragmentos (es decir: si el usuario es Logged-in, muestro un fragmento si no muestro otro fragmento). ===> Sólo intenta ver cuántos bugs facebook SDK Log-in tiene debido a esto, para entender que es realmente (?) …
-
Considerando que una Aplicación de Android se basa en Actividades … Añadir otros ciclos de vida en la Actividad sería mejor diseñar una Aplicación … Quiero decir que los módulos, los escenarios, la gestión de datos y la conectividad estarían mejor diseñados, camino. ===> Esta es una respuesta de alguien que está acostumbrado a ver el Android SDK y Android Framework con una visión Fragments. 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, en usarlos siempre? De lo contrario, ¿por qué es una buena práctica si es sólo una herramienta para algunos casos? ¿Cuáles son estos casos?
Lo siento si escribí demasiado, y gracias por su tiempo. Espero conseguir su atención, porque realmente necesito ideas y experiencias sobre este tema.
Saludos cordiales, Ahmed
- Apache Commons NET: ¿Debo crear un nuevo objeto FTPClient en cada conexión o reutilizar uno?
- Forma preferida de actualizar sqlite db en android
- Iónicos 2 problemas de rendimiento de desplazamiento
- Rendimiento ORM: ¿es greenDAO más rápido que ORMLite?
- Anidado recylerview lag mientras que los primeros rollos y luego se desplaza suavemente?
- Mi aplicación cordova webview es realmente más lento que en el navegador android en el mismo teléfono
- ¿Por qué Xamarin.Forms es tan lento al mostrar algunas etiquetas (especialmente en Android)?
- ¿Qué significa realmente el estado del hilo de Java?
No debes usar siempre fragmentos. Los fragmentos tienen sus usos, por ejemplo, cuando desea insertar y eliminar partes de la pantalla o cuando desea cambiar drásticamente la interfaz de usuario en diferentes orientaciones. Cuando tengan sentido, úsalos. Cuando no lo hacen, saltarlos. Me parece que tienen sentido en tal vez alrededor del 10-20% de las aplicaciones, rara vez veo la necesidad.
Si hay un cierto aspecto positivo aparte de la reutilización más simple de la lógica a través de diferentes diseños, es la capacidad de los fragmentos de ser mantenidos vivos por el sistema en el cambio de orientación, aka mientras que una actividad se reconstruye a partir de cero, un fragmento puede retener su instancia y Por lo tanto el uso de ellos es más estable que una actividad. Además, cambiar entre fragmentos es más rápido.
Personalmente, si no necesito molestarme con diferentes orientaciones y tamaños de diseño, todavía prefiero usar Fragmentos y una actividad de contenedor singular alrededor de ella, para una estabilidad y un cambio sin fisuras entre las diferentes pantallas.
Es una cuestión bastante general y no está directamente relacionada con un problema de programación específico. Pero en mi opinión un buen software se basa en un buen diseño y por lo tanto un buen entendimiento y mejores prácticas. Así que su pregunta es buena para stackoverflow.
Entonces, ¿qué pasa con los fragmentos. Me tomó un tiempo entender por qué usted podría o incluso debería usarlos. Como dijo @pskink, usted puede vivir fácilmente sin ellos. Pero si usted está planeando lanzar su software en diversos dispositivos, usted debe definitivamente pensar en fragmentos.
La resolución de la pantalla y la densidad no es el único problema. Piense en un teléfono inteligente. La pantalla es mucho más pequeña, por lo que no puede presentar su aplicación de la misma forma que puede en una tableta. Por ejemplo un flujo de detalle maestro. Izquierda, una lista de elementos y al hacer clic en un elemento, verá detalles de ese elemento en el lado derecho. Fácil de hacer en una tableta. Pero en un teléfono inteligente se pondría la vista maestra en un fragmento y la vista de detalle en otra.
Tienes dos opciones para realizar ese escenario. O programm diferentes actividades para smartphone y tableta, pero porque están haciendo la misma lógica, es mejor práctica para poner la lógica en fragmentos y reutilizar esos fragmentos en dos diseños (teléfono / tableta).
- Divide por error cero en archivo .xml
- RecyclerView & SnapHelper -> obtener una vista rápida / segmentada