¿Por qué usar fragmentos de Android?


15

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:

  1. Permitir el Activityuso de muchos fragmentos, cambiar entre ellos, reutilizar estas unidades ... ==> Fragmentdepende totalmente de la Contextactividad, 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.

  2. 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 ?

  3. 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 (?) ...

  4. 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?


1
No está claro lo que está preguntando, ¿podría resumir la pregunta, tal vez debajo de la enumeración de supuestas ventajas y su crítica de cada una?
logc

Agregué una pregunta detallada.
ahmed_khan_89

Estoy perdido como @logc. ¿Cómo manejarías estos casos sin Fragments?
neontapir

Di lo que haría sin Fragmentos: (1) crear controles genéricos personalizados y reutilizarlos donde quiera (2) usar 2 Actividades y navegar con startActivityForResult, o simplemente cambiar entre vistas (mostrar / ocultar, inflar / eliminar ...) sin codificar tanto ... (3) puede usar una devolución de llamada incluso en Actividades con vistas (4) Es una respuesta abstracta que siempre obtengo cuando discuto este tema ... que necesita más explicación ...
ahmed_khan_89

1
Hmm Este Q&A muestra la limitación del diseño de stackexchange donde el póster original elige la "mejor" respuesta. (A diferencia de slant.co, donde todos votan). No es ideal para una pregunta amplia como esta. Aquí, una pregunta vaga obtiene una respuesta aceptada que obviamente está de acuerdo con lo que el autor de la pregunta quería escuchar. Si no ves ninguna razón para usar fragmentos en tu situación, entonces no lo hagas. Una mejor pregunta sería preguntar por los pros / contras del fragmento vs actividad . Y hay muchos hilos sobre ese tema exacto.
ToolmakerSteve

Respuestas:


5

Fragment es una sección modular de una actividad que tiene su propio ciclo de vida, recibe sus propios eventos de entrada, que puede agregar o eliminar mientras se ejecuta la actividad (algo así como una "sub-actividad" que puede reutilizar en diferentes actividades)

Además de la ventaja obvia de usar fragmentos, la optimización de la interfaz de usuario en diferentes pantallas, le permite administrar el procesamiento en segundo plano de la actividad sin un componente de interfaz de usuario visible.

Ahora...

====> ¿Por qué complicaría mi vida, codificando más ... ??

Aunque se recomienda, no es necesario a menos que planee controlar el ciclo de vida de elementos individuales y / o reutilizar el estado de pila o el historial de vistas anteriores.


5

Si hay un caso de uso de "puerta de enlace" para los escépticos de fragmentos, probablemente sean diálogos. Los métodos obsoletos largo showDialog(...), onCreateDialog(...)etc., estaban bien en que el marco de los llamaría para destruir y volver a crear los cuadros de diálogo cuando la actividad de alojamiento se destruye y vuelve a crear automáticamente. Si crea sus propios cuadros de diálogo directamente, debe administrar todo eso usted mismo. Pero si usa un DialogFragment, puede dejar que el marco los administre por usted. En este caso, los fragmentos pueden simplificar enormemente su codificación.


1

Hice esta pregunta hace más de un año.

Estoy usando fragmentos todos los días y lo recomendaría.

En primer lugar, quiero decir que usar fragmentos es solo una opción y será un reflejo considerarlo una vez que comience a usarlos.

Ventajas:

1 / ayuda a modularizar el código donde puede tener un flujo completo en una Actividad, en fragmentos separados. Ejemplo: + lista / cuadrícula y detalles, + inicio de sesión y registro y olvidar contraseña, + etc. Esto es increíble para obtener un código reutilizable, que siempre puede copiar y pegar en diferentes proyectos.

2 / tienes un nuevo ciclo de vida, lleno de problemas, es cierto, pero también con ventajas. Ejemplo: el fragmento de instancia retenido es impresionante porque resuelve el problema de la orientación.

3 / puede administrar el flujo de sus fragmentos por eventos y oyentes desde la Actividad.

4 / una pila de tus fragmentos en tu Actividad.

5 / use la misma barra de acción en muchas pantallas.

Y muchos otros...

A veces sigo usando la Actividad como único contenedor, especialmente para el estuche de la cámara. Algunas API de Android y algunas bibliotecas de terceros no son fáciles de implementar en fragmentos.

Bueno, es como cualquier herramienta, tienes que considerarla y juzgar por ti mismo si es mejor usarla en un caso u otro.

¡¡¡Espero que esto pueda ayudar!!!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.