Dilema: cuándo usar Fragmentos vs Actividades:

Sé que las Activities están diseñadas para representar una sola pantalla de mi aplicación, mientras que los Fragments están diseñados para ser diseños de IU reutilizables con lógica integrada dentro de ellos.

Hasta no hace mucho tiempo, desarrollé una aplicación porque decía que deberían desarrollarse. ViewPager una Activity para representar una pantalla de mi aplicación y utilicé Fragmentos para ViewPager o Google Maps . Raramente creo un ListFragment u otra IU que pueda reutilizarse varias veces.

Recientemente me encontré con un proyecto que contiene solo 2 Activities una es una actividad de SettingsActivity y otra es la MainActivity . El diseño de MainActivity se rellena con muchos fragmentos ocultos de UI de pantalla completa y solo se muestra uno. En la lógica de Acitivty hay muchas FragmentTransitions entre las diferentes pantallas de la aplicación.

Lo que me gustó de este enfoque es que, debido a que la aplicación usa una ActionBar , se mantiene intacta y no se mueve con la animación de cambio de pantalla, que es lo que sucede con el cambio de Activity . Esto da una sensación más fluida a esas transiciones de pantalla.

Así que supongo que lo que estoy pidiendo es que compartas tu actual forma de desarrollo con respecto a este tema, sé que podría parecer una pregunta basada en opinión a primera vista, pero lo veo como una cuestión de diseño y architecture de Android … No es realmente una basado en opinión.

ACTUALIZACIÓN (01.05.2014): Después de esta presentación de Eric Burke de Square , (que tengo que decir que es una gran presentación con muchas herramientas útiles para desarrolladores de Android. Y no estoy relacionado de ninguna manera con Square)

http://www.infoq.com/presentations/Android-Design/

Desde mi experiencia personal en los últimos meses, encontré que la mejor manera de construir mis aplicaciones es crear grupos de fragmentos que representen un flujo en la aplicación y presentar todos esos fragmentos en una sola Activity . Entonces, básicamente, tendrá la misma cantidad de Activities en su aplicación que el número de flujos. De esta forma, la barra de acciones permanece intacta en todas las pantallas de flujo, pero se recrea al cambiar un flujo que tiene mucho sentido. Como dice Eric Burke, y como también me he dado cuenta, la filosofía de usar el menor número posible de Activities no es aplicable a todas las situaciones porque crea un desorden en lo que él llama la actividad “Dios”.

Los expertos le dirán: “Cuando veo la interfaz de usuario, sabré si utilizar una Activity o un Fragment “. Al principio, esto no tendrá sentido, pero con el tiempo, podrás saber si necesitas un Fragment o no.

Hay una buena práctica que encontré muy útil para mí. Se me ocurrió mientras intentaba explicarle algo a mi hija.

A saber, imagine una caja que representa una pantalla. ¿Puedes cargar otra pantalla en esta casilla? Si usa una nueva caja, ¿tendrá que copiar varios artículos de la 1ra casilla? Si la respuesta es Sí, entonces debe usar Fragments , porque la Activity raíz puede contener todos los elementos duplicados para ahorrarle tiempo al crearlos, y puede simplemente reemplazar partes del cuadro.

Pero no olvide que siempre necesita un contenedor de caja ( Activity ) o sus partes se dispersarán. Entonces una caja con partes adentro.

Tenga cuidado de no hacer mal uso de la caja. Los expertos en UX de Android aconsejan (puedes encontrarlos en YouTube) cuando debemos cargar explícitamente otra Activity , en lugar de usar un Fragment (como cuando tratamos con el Cajón de navegación que tiene categorías). Una vez que se sienta cómodo con Fragments , puede ver todos sus videos. Aún más son material obligatorio.

¿Puedes mirar ahora tu UI y averiguar si necesitas una Activity o un Fragment ? ¿Obtuviste una nueva perspectiva? Creo que lo hiciste

Mi filosofía es esta:

Crea una actividad solo si es absolutamente necesario. Con el backstack disponible para cometer un montón de transacciones de fragmentos, trato de crear un mínimo de actividades en mi aplicación como sea posible. Además, la comunicación entre varios fragmentos es mucho más fácil que enviar datos de ida y vuelta entre actividades.

Las transiciones de actividad son costosas, ¿verdad? Al menos eso creo, dado que la actividad anterior se destruyó / pausó / detuvo, se empujó a la stack y luego la nueva actividad se debe crear / iniciar / reanudar.

Es solo mi filosofía desde que se introdujeron los fragmentos.

Bueno, de acuerdo con las conferencias de Google (tal vez aquí , no lo recuerdo), debería considerar usar Fragmentos siempre que sea posible, ya que hace que su código sea más fácil de mantener y controlar.

Sin embargo, creo que en algunos casos puede ser demasiado complejo, ya que la actividad que aloja los fragmentos necesita navegar / comunicarse entre ellos.

Creo que deberías decidir por ti mismo qué es lo mejor para ti. Por lo general, no es tan difícil convertir una actividad en un fragmento y viceversa.

He creado una publicación sobre este dillema aquí , si desea leer más.

Por qué prefiero Fragmento a Actividad en TODOS LOS CASOS.

  • La actividad es costosa En Fragment, las vistas y los estados de propiedades están separados; cada vez que un fragmento se encuentra en backstack , sus vistas se destruirán. Entonces puedes astackr muchos más Fragmentos que Actividad.

  • Manipulación de Backstack . Con FragmentManager , es fácil borrar todos los Fragmentos, insertar más que en Fragmentos y etc. Pero para Activity, será una pesadilla manipular esas cosas.

  • Un ciclo de vida mucho más predecible. Siempre que la actividad del anfitrión no sea reciclada. los Fragmentos en la backstack no serán reciclados. Por lo tanto, es posible utilizar FragmentManager::getFragments() para encontrar un Fragmento específico (no FragmentManager::getFragments() ).

En mi opinión, no es realmente relevante. El factor clave a considerar es

  1. con qué frecuencia reutilizará partes de la IU (menús, por ejemplo),
  2. es la aplicación también para tabletas?

El principal uso de los fragmentos es crear actividades multipane, lo que lo hace perfecto para aplicaciones sensibles a Tablet / Phone.

Hay más en esto de lo que cree, debe recordar que una actividad que se inicia no destruye implícitamente la actividad de llamada. Claro, puede configurarlo de modo que su usuario haga clic en un botón para ir a una página, inicie la actividad de esa página y destruya la actual. Esto causa una gran sobrecarga. La mejor guía que puedo darte es:

** Comience una nueva actividad solo si tiene sentido tener la actividad principal y esta abierta al mismo tiempo (piense en varias ventanas).

Un buen ejemplo de cuándo tiene sentido tener múltiples actividades es Google Drive. La actividad principal proporciona un explorador de archivos. Cuando se abre un archivo, se inicia una nueva actividad para ver ese archivo. Puede presionar el botón de aplicaciones recientes que le permitirá volver al navegador sin cerrar el documento abierto, y tal vez incluso abrir otro documento en paralelo al primero.

¡No olvide que una actividad es el bloque / componente de la aplicación que puede compartirse e iniciarse a través de Intent! Por lo tanto, cada actividad en su aplicación debe resolver solo un tipo de tarea. Si solo tiene una tarea en su aplicación, creo que solo necesita una actividad y muchos fragmentos si es necesario. Por supuesto, puede reutilizar fragmentos en actividades futuras que resuelven otras tareas. Este enfoque será la separación clara y lógica de las tareas. Y no es necesario mantener una actividad con diferentes parámetros de filtro de intención para diferentes conjuntos de fragmentos. Define tareas en la etapa de diseño del proceso de desarrollo según los requisitos.

Cosa que hice: usar menos fragmentos cuando sea posible. Desafortunadamente, es posible en casi casos. Entonces, termino con muchos fragmentos y un poco de actividades. Algunos inconvenientes que me he dado cuenta:

  • ActionBar & Menu: cuando 2 fragmento tiene un título, menú diferente,
    será difícil de manejar. Por ejemplo, al agregar un nuevo fragmento, puede cambiar el título de la barra de acciones, pero cuando lo backstack de la backstack no hay forma de restaurar el título anterior. Es posible que necesite una barra de herramientas en cada fragmento para este caso, pero créame, eso le hará perder más tiempo.
  • Cuando necesitamos startForResult , la actividad tiene pero el fragmento no.
  • No tiene animación de transición por defecto

Mi solución para esto es usar una Actividad para envolver un fragmento dentro. Así que tenemos una barra de acciones separada, menú, startActivityForResult , animación, …

La gran ventaja de un fragment sobre la actividad es que el código que se utiliza para el fragmento se puede usar para diferentes actividades. Por lo tanto, proporciona la reutilización del código en el desarrollo de la aplicación.

Uso Fragmentos para una mejor experiencia de usuario. Por ejemplo, si tiene un Botón y desea ejecutar digamos un servicio web cuando hace clic en él, adjunto un Fragmento a la Actividad principal.

 if (id == R.id.forecast) { ForecastFragment forecastFragment = new ForecastFragment(); FragmentManager fm = getSupportFragmentManager(); FragmentTransaction ft = fm.beginTransaction(); ft.replace(R.id.main_content, forecastFragment); ft.addToBackStack("backstack"); forecastFragment.setArguments(b); ft.commit(); } 

De esta forma, el usuario no tendrá que moverse en otra actividad.

Y en segundo lugar, prefiero Fragmentos porque puedes manejarlos fácilmente durante la rotación.

Depende de lo que quieras construir realmente. Por ejemplo, el navigation drawer usa fragmentos. Las tabs también usan fragments . Otra buena implementación es donde tienes una lista. Cuando gira el teléfono y hace clic en una fila, la actividad se muestra en la mitad restante de la pantalla. Personalmente, uso fragments y fragment dialogs , ya que es más profesional. Además, se manejan más fácilmente en rotación.

use una actividad por aplicación para proporcionar una base para el fragment uso de fragment para la pantalla, los fragments son ligeros en comparación con los fragmentos de activites fragmentos reutilizables son más adecuados para la aplicación que admite tanto el teléfono como la tableta

Usted es libre de usar uno de esos.
Básicamente, debes evaluar cuál es la mejor para tu aplicación. Piense en cómo administrará el flujo de negocios y cómo almacenar / administrar las preferencias de datos.

Piense en cómo Fragmentos almacena datos basura. Cuando implementa el fragmento, tiene una raíz de actividad para completar con fragmento (s). Por lo tanto, si intenta implementar muchas actividades con demasiados fragmentos, debe considerar el rendimiento en su aplicación, porque está manipulando (habla groseramente) el ciclo de vida de dos contextos, recuerde la complejidad.

Recuerde: ¿debería usar fragmentos? ¿Por qué no debería?

Saludos.