tutorial studio navegar fragments example entre ejemplo dinamicos desde activity abrir android android-layout android-activity android-fragments android-lifecycle

android - studio - Una actividad y todos los demás fragmentos



java android fragment (8)

Pros

Puede controlar sus fragmentos de una sola actividad, ya que todos los fragmentos son independientes entre sí. Los fragmentos tienen un ciclo de vida ( onPause , onCreate , onStart ...) propio. Al tener un ciclo de vida, los fragmentos pueden responder de forma independiente a los eventos, guardar su estado en onSaveInstanceState y regresar (es decir, cuando se reanuda después de una llamada entrante o cuando el usuario hace clic en el botón Atrás).

Contras

  1. Crea complejidad en tu código de actividad.
  2. Tienes que administrar el orden de los fragmentos.

No obstante, es una buena idea, como si necesitara crear una aplicación, donde desea mostrar varias vistas. Con esta idea, podrás ver varios fragmentos en una sola vista ...

Estoy pensando en implementar una pantalla con Activity y todos los otros sreens con Fragments y managing all the fragments thru the activity .

¿Es una buena idea? y mi respuesta es NO, pero aún así quiero saber más claramente sobre este pensamiento.

¿Cuáles son los pros y los contras de la idea?

Nota:

Por favor no me des el enlace para fragmento y actividad.

EDITAR:

Aquí hay algo sobre Fragmentos y actividad:

Pros:

  1. Los fragmentos están destinados a ser utilizados con actividades como una sub-actividad.
  2. Los fragmentos no son el reemplazo de las actividades.
  3. Los fragmentos están destinados a la reutilización (Necesidad de saber de qué manera se puede lograr la reutilización).
  4. Los fragmentos son la mejor forma de escribir código para admitir tabletas y teléfonos.

Contras:

  1. Necesitamos implementar la interfaz para obtener los datos de los fragmentos.
  2. Para el diálogo tenemos que recorrer un largo camino para mostrarlo.

¿Por qué deberíamos usar fragmentos si no estamos considerando tabletas? ¿Cuál es la diferencia de tiempo inicial entre la actividad y el fragmento?

Depende de la aplicación que está creando. He creado varias aplicaciones usando ambos enfoques y no puedo decir que una sea siempre mejor que la otra. La última aplicación que creé utilicé el enfoque de Activity única y una navegación de estilo de Facebook. Al seleccionar elementos de la lista de navegación, actualizo un único contenedor de Fragment para mostrar esa sección.

Dicho esto, tener una sola Activity también presenta muchas complejidades. Supongamos que tiene un formulario de edición, y para algunos de los elementos que el usuario necesita seleccionar o crear, necesita que vaya a una nueva pantalla. Con actividades, simplemente llamaríamos a la nueva pantalla con startActivityForResult pero con Fragments no existe tal cosa, así que terminas almacenando el valor de la Activity y teniendo el fragmento de edición principal revisando la Activity para ver si los datos han sido seleccionados y deberían mostrarse para el usuario.

Lo que dice Aravind acerca de estar atrapado en un solo tipo de Activity también es cierto, pero no tan limitante. Su actividad sería una FragmentActivity y siempre que no necesite MapView entonces no existen limitaciones reales. Sin embargo, si desea mostrar los mapas, puede hacerlo, pero deberá modificar la Biblioteca de compatibilidad de Android para que FragmentActivity amplíe MapActivity o use los android-support-v4-googlemaps disponibles públicamente.

En última instancia, la mayoría de los desarrolladores que conozco que fueron la única ruta de Activity han regresado a múltiples actividades para simplificar su código. En lo que respecta a la interfaz de usuario, en una tableta, algunas veces estás atrapado usando una sola Activity solo para lograr la loca interacción que tus diseñadores idean :)

- EDITAR -

Google finalmente ha lanzado MapFragment a la biblioteca de compatibilidad por lo que ya no tiene que usar el hack de android-support-v4-googlemaps. Lea sobre la actualización aquí: Google Maps Android API v2

- EDITAR 2 -

Acabo de leer esta gran publicación sobre el estado de fragmentos moderno (2017) y recuerdo esta vieja respuesta. Pensé que podría compartir: Fragmentos: la solución a todos los problemas de Android

Depende del diseño de su aplicación. Suponga que si usa las pestañas en ActionBar en el diseño, entonces en la Actividad única de la aplicación se pueden cambiar los fragmentos al hacer clic con la tecla Tab. Entonces ahora tiene una Actividad y supongamos que tres Pestañas en la Barra de Acción y la vista para las pestañas que están siendo provistas por los Fragmentos, lo que hace que sea más fácil de administrar también es factible también. Entonces, todo depende del esquema de diseño de tu aplicación y de cómo tomes la decisión de construir para ella.

En primer lugar, haga lo que haga, asegúrese de tener un diseño modular con modelo, vista, presentador que no dependa en gran medida de una Actividad o un Fragmento.

¿Qué proporcionan realmente las Actividades y los Fragmentos?

  1. Eventos del ciclo de vida y backstack
  2. Contexto y recursos

Por lo tanto, ÚSELOS para eso, SOLAMENTE . Ellos tienen suficiente responsabilidad, no los compliques demasiado. Yo argumentaría que incluso intantar un TextView en una Actividad o Fragmento es una mala práctica. Hay una razón por la cual los métodos como public View findViewById (int id) son PÚBLICOS .

Ahora la pregunta es más simple: ¿Necesito múltiples eventos de ciclo de vida independientes y backstacks? Si crees que sí, tal vez, usa fragmentos. Si piensas que nunca, no uses fragmentos.

Al final, podrías hacer tu propio backstack y ciclos de vida. Pero, ¿por qué recrear la rueda?

EDITAR: ¿Por qué votar abajo esto? Las clases de propósito único personas! Cada actividad o fragmento debería ser capaz de crear instancias de un presentador que crea una instancia de una vista. El presentador y la vista son un módulo que puede intercambiarse. ¿Por qué una actividad o fragmento debe ser responsabilidad de un presentador?

Estoy por terminar un proyecto (5 meses en desarrollo), que tiene 1 actividad y 17 fragmentos, todos a pantalla completa. Este es mi segundo proyecto basado en fragmentos (el anterior tenía 4 meses).

Pros

  • La actividad principal es 700 líneas de código, administrando muy bien el orden de los fragmentos de navegación.
  • Cada fragmento está muy bien separado en su propia clase, y es relativamente pequeño (~ un par de cientos de líneas de material de interfaz de usuario).
  • La gerencia puede decir "hey, qué tal si cambiamos el orden de esas pantallas", y puedo hacerlo muy fácilmente, ya que esos fragmentos no dependen el uno del otro, todos se comunican a través de la actividad. No tengo que profundizar en las actividades individuales para encontrar dónde se llaman entre sí.
  • mi aplicación tiene muchos gráficos y nunca funcionaría como 1 actividad de pantalla 1. Todas esas actividades secundarias en la memoria harían que la aplicación se quedara sin memoria todo el tiempo, así que tendría que finish() todas las actividades no visibles y hacer la misma lógica de control para la navegación, como haría con los fragmentos. Bien podría hacerlo con fragmentos solo por esto.
  • si alguna vez hacemos una aplicación de tableta, tendremos un tiempo más fácil re-factorizando cosas, porque todo está bien separado ya.

Contras

  • tienes que aprender, cómo usar fragmentos

La razón más importante que daría para no utilizar el enfoque de actividad única es que se pueda aprovechar el ciclo de vida de la actividad. Las actividades contienen el comportamiento contextual de una cierta porción de la aplicación y los fragmentos complementan ese comportamiento. Tener la capacidad de aprovechar los pasos anulables en el ciclo de vida de la actividad ayuda a separar el comportamiento de una actividad de otra con métodos como onPause y onResume . Este ciclo de vida también le permite regresar al contexto anterior. Con el enfoque de actividad única, una vez que dejas un fragmento, debes crear un mecanismo para regresar a él.

Pros:

  • Se puede usar para crear una única interfaz utilizable por múltiples tamaños de pantalla y orientaciones a través de diseños xml.

Contras:

  • Requiere un código más complejo en su actividad.

Creo que es una buena idea, porque el uso de diferentes diseños de xml en función del tamaño y la orientación de la pantalla actual puede hacer que la aplicación sea más útil y reducir la necesidad de lanzar varias versiones de tu aplicación si planeas lanzar tu aplicación para teléfonos y tabletas. Si su aplicación nunca será utilizada tanto por tabletas como por teléfonos, probablemente no valga la pena.

Soy partidario de diferir toda la inflación de vista a fragmentos para proporcionar una mejor flexibilidad. Por ejemplo, tener una sola actividad de aterrizaje para una tableta que agrega múltiples fragmentos y reutilizar los mismos fragmentos en un teléfono para mostrar una pantalla por fragmento. Sin embargo, en la implementación del teléfono tendría una actividad separada para cada pantalla. Las actividades no tendrían demasiados códigos ya que de inmediato diferirían a su contraparte de fragmentos para ver la inflación.

Creo que es una mala idea que la implementación del teléfono tenga que cambiar a una sola actividad de aterrizaje cuando se introducen pestañas o un menú deslizable, ya que la pestaña o navegación del menú solo da como resultado una pantalla completamente nueva.