Dilema: cuándo usar fragmentos frente a actividades:

Sé que Activitiesestán diseñados para representar una sola pantalla de mi aplicación, mientras que Fragmentsestán diseñados para ser diseños de interfaz de usuario reutilizables con lógica incrustada dentro de ellos.

Hasta no hace mucho, desarrollé una aplicación que decía que debían desarrollarse. Creé un Activitypara representar una pantalla de mi aplicación y usé Fragmentos para ViewPagero Google Maps. Rara vez he creado una ListFragmentinterfaz de usuario u otra que pueda reutilizarse varias veces.

Recientemente me encontré con un proyecto que contiene solo 2, Activitiesuno es ay SettingsActivityotro es MainActivity. El diseño de MainActivityestá lleno de muchos fragmentos de IU de pantalla completa ocultos y solo se muestra uno. En la Activitylógica hay muchos FragmentTransitionsentre las distintas pantallas de la aplicación.

Lo que me gusta de este enfoque es que debido a que la aplicación usa un ActionBar, permanece intacto y no se mueve con la animación de cambio de pantalla, que es lo que sucede con el Activitycambio. Esto le da una sensación más fluida a esas transiciones de pantalla.

Así que supongo que lo que estoy pidiendo es que comparta su forma de desarrollo actual con respecto a este tema, sé que puede parecer una pregunta basada en opiniones a primera vista, pero la veo como una pregunta de diseño y arquitectura de Android ... uno basado en la opinión.

ACTUALIZACIÓN (01.05.2014): Después de esta presentación de Eric Burke de Square , (que debo 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/

De mi experiencia personal durante los últimos meses, descubrí que la mejor manera de construir mis aplicaciones es crear grupos de fragmentos que lleguen a representar un flujo en la aplicación y presenten todos esos fragmentos en uno Activity. Entonces, básicamente, tendrá el mismo número de Activitiesen su aplicación que el número de flujos. De esa manera, la barra de acción permanece intacta en todas las pantallas del flujo, pero se recrea al cambiar un flujo, lo que tiene mucho sentido. Como afirma Eric Burke y como también me he dado cuenta, la filosofía de utilizar la menor cantidad Activitiesposible no es aplicable a todas las situaciones porque crea un lío en lo que él llama la actividad de "Dios".

Los expertos le dirán: "Cuando vea la interfaz de usuario, sabré si usar una Activityo una Fragment". Al principio, esto no tendrá ningún sentido, pero con el tiempo podrás saber si lo necesitas Fragmento no.

Hay una buena práctica que me resultó muy útil. Se me ocurrió mientras intentaba explicarle algo a mi hija.

Es decir, imagine un cuadro que representa una pantalla. ¿Puedes cargar otra pantalla en este cuadro? Si usa una caja nueva, ¿tendrá que copiar varios elementos de la primera caja? Si la respuesta es Sí, entonces debe usar Fragments, porque la raíz Activitypuede contener todos los elementos duplicados para ahorrarle tiempo al crearlos, y simplemente puede reemplazar partes de la caja.

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

Tenga cuidado de no hacer un mal uso de la caja. Los expertos de Android UX aconsejan (puede encontrarlos en YouTube) cuando deberíamos cargar explícitamente otro 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. Más aún son material obligatorio.

¿Puedes ahora mirar tu interfaz de usuario y averiguar si necesitas una Activityo una Fragment? ¿Obtuviste una nueva perspectiva? Creo que lo hiciste.

Mi filosofía es esta:

Cree una actividad solo si es absolutamente necesario. Con la pila de actividades disponible para realizar un montón de transacciones de fragmentos, trato de crear la menor cantidad posible de actividades en mi aplicación. Además, comunicarse entre varios fragmentos es mucho más fácil que enviar datos entre actividades.

Las transiciones de actividad son caras, ¿verdad? Al menos eso creo, ya que la actividad anterior debe ser destruida / pausada / detenida, empujada a la pila, y luego la nueva actividad debe ser creada / iniciada / reanudada.

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

Bueno, de acuerdo con las conferencias de Google (tal vez aquí , no recuerdo), debería considerar usar Fragments 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 volverse 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 ¿Por qué fragmentos y cuándo utilizar fragmentos en lugar de actividades? , si desea leer más.

Desde Jetpack , la aplicación de actividad única es la arquitectura preferida. Útil especialmente con el componente de arquitectura de navegación .

fuente

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

• La actividad es cara. En Fragmento, las vistas y los estados de propiedad están separados; siempre que un fragmento esté dentro backstack, sus vistas se destruirán. Por lo que puede apilar muchos más fragmentos que actividad.

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

• Un ciclo de vida mucho más predecible . Siempre que la actividad del host no se recicle. los Fragmentos del backstack no se reciclarán. Por lo tanto, es posible usarlo FragmentManager::getFragments()para encontrar un fragmento específico (no se recomienda).

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

1. con qué frecuencia vas a reutilizar partes de la interfaz de usuario (menús, por ejemplo),
2. ¿La aplicación también es para tabletas?

El uso principal de fragmentos es crear actividades multipane, lo que lo hace perfecto para aplicaciones de respuesta de tableta / teléfono.

¡No olvide que una actividad es el bloque / componente de la aplicación que se puede compartir e iniciar a través de Intent! Por lo tanto, cada actividad de 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 resuelvan otras tareas. Este enfoque será una separación clara y lógica de tareas. Y no es necesario mantener una actividad con diferentes parámetros de filtro de intención para diferentes conjuntos de fragmentos. Defina tareas en la etapa de diseño del proceso de desarrollo según los requisitos.

Hay más en esto de lo que te imaginas, debes recordar que una actividad que se inicia no destruye implícitamente la actividad de llamada. Claro, puede configurarlo de manera 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 mucha sobrecarga. La mejor guía que puedo darte es:

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

Un gran ejemplo de cuándo tiene sentido tener varias 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 quizás incluso abrir otro documento en paralelo al primero.

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

• ActionBar& Menú: cuando 2 fragmentos tienen un título, menú diferente,
  será difícil de manejar. Ej .: al agregar un nuevo fragmento, puede cambiar el título de la barra de acción, pero cuando lo saca backstackno hay forma de restaurar el título anterior. Es posible que necesite una barra de herramientas en cada fragmento para este caso, pero créanme, eso les llevará más tiempo.
• Cuando lo necesitamos startForResult, la actividad tiene pero el fragmento no.
• No tiene animación de transición de forma predeterminada

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

La gran ventaja de una fragmentsobreactividad es que el código que se usa para el fragmento se puede usar para diferentes actividades. Por lo tanto, proporciona reutilización de código en el desarrollo de aplicaciones.

use una actividad por aplicación para proporcionar una base para fragment usar fragmenten la pantalla, fragmentstienen un peso ligero en comparación con los activites fragmentos son fragmentos reutilizables son más adecuados para aplicaciones que admiten teléfonos y tabletas

Eres 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 los fragmentos almacenan los datos basura. Cuando implementa el fragmento, tiene una raíz de actividad para llenar con fragmento (s). Entonces, si está tratando de implementar muchas actividades con demasiados fragmentos, debe considerar el rendimiento en su aplicación, porque está manipulando (habla groseramente) dos ciclos de vida de contexto, recuerde la complejidad.

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

Saludos.

Utilizo 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 esa forma el usuario no tendrá que moverse en otra actividad.

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

Depende de lo que quieras construir realmente. Por ejemplo, los navigation drawerusos fragmentos. Las pestañas también se utilizan fragments. Otra buena implementación es donde tienes un listview. Cuando gira el teléfono y hace clic en una fila, la actividad se muestra en la mitad restante de la pantalla. Personalmente, utilizo fragmentsy fragment dialogs, ya que es más profesional. Además, se manejan más fácilmente en rotación.