onattach - navegar entre fragments android studio
¿Por qué usar Fragments? (6)
Esta pregunta ya tiene una respuesta aquí:
¿Cuál es la ventaja de usar Fragment s sobre el uso de View personalizadas que se reutilizan en diferentes diseños?
En la publicación original del blog que presenta fragmentos , Dianne Hackborn dice que
[Fragmentos] hace que sea más fácil para los desarrolladores escribir aplicaciones que pueden escalar en una variedad de tamaños de pantalla, más allá de las instalaciones ya disponibles en la plataforma.
y luego explica Fragmentos en el contexto de hacer un diseño de tableta para una aplicación que combina la interfaz de usuario de dos actividades desde la versión de teléfono de la misma aplicación.
Pero parece que la misma reutilización podría lograrse utilizando vistas personalizadas. La principal diferencia entre Fragments y Views parece ser que tienen diferentes ciclos de vida ...
El ciclo de vida de Fragment es:
onAttach() , onCreate() , onCreateView() , onActivityCreated() , onStart() , onResume() , onPause() , onStop() , onDestroyView() , onDestroy() , onDetatch() .
El ciclo de vida de View es:
ctor , onFinishInflate() , onAttachedToWindow() , onMeasure() , onLayout() , onDetatchedFromWindow()
Me gustaría escuchar a los desarrolladores con experiencia en la escritura de grandes aplicaciones sobre los beneficios (si hay alguno) que han visto al usar Fragmentos frente a Vistas personalizadas para dividir la IU en piezas reutilizables.
Alguna descripción:
Imagine Activity como un plato que contiene una gran torta. Fragmento sería un contenedor que corta la misma torta en pedazos. Cada sector contiene sus propias lógicas (oyentes, etc.). Y en total, casi no son diferentes con el gran pastel.
El beneficio:
Cuando plateas no puedes sostener un gran pastel. (La pantalla es pequeña) Puede usar fácilmente unas pocas placas (Actividad) para sostener cada una de ellas SIN la necesidad de mover sus lógicas a la nueva actividad.
Mejor reutilización. Tengo algunos casos en los que podría reutilizar un fragmento por completo en otra aplicación. Puede reclamar que una vista personalizada también lo haga. Pero refiérase al punto 1, podría reutilizarlo con solo unas pocas líneas de cambios de diseño, pero para una vista personalizada, tiene que encontrar la manera de conectarlo en el diseño y el código.
Es, en cierto sentido, una forma más OO de organizar sus lógicas de UI en la programación de Android. Cuando tiene una función (una nueva partición en la pantalla, por ejemplo), crea una nueva clase Fragment, con modificaciones menores a la clase de actividad existente. Sin embargo, si está programando solo con actividad, necesitará agregar lógicas y hacer grandes modificaciones en la clase probada.
Solo mis 2 centavos. :)
La razón principal es que los fragmentos son más reutilizables que las vistas personalizadas.
A veces no puede crear un componente de interfaz de usuario completamente encapsulado confiando solo en vistas. Esto se debe a que hay cosas que le gustaría poner en su vista, pero no puede porque solo una Actividad puede manejarlas, forzando así el acoplamiento entre una Actividad y una Vista.
Aquí hay uno de esos ejemplos. Supongamos que quiere crear un componente UI reutilizable que, entre otras cosas, desee capturar una foto y hacer algo con ella. Tradicionalmente dispararías un intento que inicia la cámara y regresa con la imagen capturada.
Tenga en cuenta que su componente de IU personalizado no puede encapsular por completo esta funcionalidad, ya que tendrá que confiar en la actividad de acogida StartActivityForResult porque las vistas no aceptan resultados de actividad (pueden generar indirectamente un intento a través del contexto).
Ahora, si quisiera reutilizar su componente de IU personalizado en diferentes actividades, estaría repitiendo el código para Activity.startActivityForResult.
Fragmento, por otro lado, resolver limpiamente este problema.
De forma similar, su fragmento puede contribuir elementos a su menú de opciones, algo que tradicionalmente solo una Actividad podría hacer. De nuevo, esto podría ser importante si el estado de su vista personalizada determina qué incluye el menú.
Las vistas personalizadas son mucho más trabajo que simplemente usar fragmentos en lugar de tus actividades. si decide usar Actividades y Vistas personalizadas, debe crear su vista personalizada, y luego debe implementar los mismos métodos de ciclo de vida de actividad en su actividad (se usa un ciclo de vida muy similar para los fragmentos).
Usar Fragmentos también le permite separar componentes en sus propias clases (Fragmentos), en lugar de tener demasiada lógica en una sola Actividad. Déjame refrenarlo con un ejemplo:
Supongamos que está implementando una aplicación de lector de revistas. con fragmentos, puede crear un fragmento: ArticleList, que muestra una lista de artículos, y otro fragmento: ArticleDisplay, que maneja la lógica para mostrar contenido. a continuación, puede especificar cómo deben interactuar estos fragmentos utilizando las herramientas de fragmentos, de modo que en un dispositivo móvil, puede utilizar el espacio de pantalla completa para el artículo en pantalla, mientras que en una tableta, puede mostrar los fragmentos uno al lado del otro.
Si intentaras esto con una vista de Actividad / personalizada, tendrías la lógica para ambos Fragmentos en tu Actividad monolítica, tendrías que escribir una vista personalizada, y tendrías que depurar este monstruo difícil de manejar.
Los fragmentos son, en general, una forma más sofisticada y poderosa de escribir sus aplicaciones. Pueden hacer todo lo que una Actividad puede hacer, y más. Si no necesita la funcionalidad adicional, los valores predeterminados probablemente lo llevarán a donde necesita ir, y con menos trabajo.
Los métodos del ciclo de vida son probablemente su mayor pista. Si lo piensas, se correlacionan estrechamente con el ciclo de vida de la actividad (con algunos ganchos en la actividad y las vistas). De hecho, en el artículo que vinculó, Hackborn dice:
En cierto modo, puedes pensar en un Fragmento como una mini actividad
Al igual que con muchas cosas en el diseño / desarrollo de software, hay una multitud de formas de hacer las cosas. Hay muchos lugares diferentes donde puedes poner tu código. Sí, probablemente podrías poner mucho en una visión, pero guardar preocupaciones diferentes en diferentes clases es una buena cosa. El patrón clásico de esto es MVC y se aplica en este escenario. No quiere hornear demasiada lógica de controlador en su vista. Es mejor mantenerlo en clases tipo controlador que son la actividad y ahora el fragmento. Esta es la razón por la cual el ciclo de vida del fragmento se parece más a la actividad que a la vista: se hizo para facilitar este tipo de organización.
Toqué Fragmentos una vez y no los encontré muy útiles (ver esta publicación ). Por lo que he leído, Un fragmento es realmente una palabra elegante para un objeto con acceso al contexto de la actividad . Me gusta ignorar Fragmentos en mi trabajo, y simplemente crear estos Objetos por mi cuenta. Creé aplicaciones muy grandes y muy exigentes al pasar una Activity a los constructores, en lugar de a Context . Un beneficio importante, sin embargo, para usar Fragments es que son compatibles con el sistema de diseño de Vista, por lo que puede agregarlos fácilmente a Android xml (si lo usa para sus diseños).
Un fragmento es mucho más que solo una vista. De hecho, incluso puede ser totalmente sin vista. Puede tener todo tipo de cosas, incluidas AsyncTasks, varios Listeners, acceso a archivos y bases de datos, y así sucesivamente.
Piense en ello como una actividad pequeña, pero puede tener varios de ellos en la pantalla y trabajar con todos ellos, incluida la comunicación entre ellos mientras estén visibles.
Por ejemplo, podría tener una lista del carrito de la compra que se muestra en un fragmento y el carro actualmente seleccionado en detalle en otro fragmento. Entonces, por ejemplo, puede cambiar la cantidad de un artículo en la vista de detalles y la vista de lista podría ser notificada al respecto y actualizar el precio total en la vista de lista. Puede orquestar totalmente las interacciones de esa manera, mientras que, por ejemplo, aún tener solo una de ellas visible en un dispositivo de pantalla más pequeña.
He rediseñado una gran aplicación de negocios (> 15 actividades) de actividades a fragmentos para obtener una buena compatibilidad con tabletas y nunca comenzaría una nueva aplicación sin fragmentos.
Actualización de febrero de 2016 : Si bien lo anterior aún es cierto, existen complejidades con fragmentos que hicieron que muchas personas evitaran usarlas por completo. Patrones más nuevos como el uso de enfoques MVC y vistas más potentes ofrecen alternativas. Como dicen ... YMMV.