android - fragments - Dilema: cuándo usar Fragmentos vs Actividades:

activity vs fragment

Question

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 UI reutilizables con lógica incrustada en ellos.

Hasta hace poco, desarrollé una aplicación que 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 . Rara vez he creado un ListFragment u otra UI que pueda reutilizarse varias veces.

Recientemente me topé con un proyecto que contiene solo 2 Activities una es SettingsActivity y la otra es MainActivity . El diseño de MainActivity se rellena con muchos fragmentos ocultos de IU 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 , permanece intacta y no se mueve con la animación de cambio de pantalla, que es lo que sucede con el cambio de Activity . Esto le da una sensación más fluida a esas transiciones de pantalla.

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

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

A partir de mi experiencia personal en los últimos meses, descubrí 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 Activity . Básicamente, tendrá la misma cantidad de Activities en su aplicación que la cantidad 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 que tiene mucho sentido. Como afirma Eric Burke y también me he dado cuenta, la filosofía de usar la menor cantidad de Activities posible no es aplicable a todas las situaciones porque crea un desastre en lo que él llama la actividad "Dios".

Answer 1

¡No olvide que una actividad es un bloque / componente de la aplicación que se puede compartir y comenzar a través de Intent! Por lo tanto, cada actividad en su aplicación debería resolver solo un tipo de tarea. Si solo tiene una tarea en su aplicación, entonces 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á claro y lógico de separación de tareas. Y no necesita mantener una actividad con diferentes parámetros de filtro de intento para diferentes conjuntos de fragmentos. Las tareas se definen en la etapa de diseño del proceso de desarrollo en función de los requisitos.

Answer 2

Bueno, de acuerdo con las conferencias de Google (quizás here , no lo recuerdo), debe considerar el uso de 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 debe navegar / comunicarse entre ellos.

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

He creado una publicación sobre este dillema here , si desea leer un poco más.

Answer 3

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

• ActionBar y menú: cuando 2 fragmentos tienen diferentes títulos, menús,
  será difícil de manejar. Ejemplo: cuando agrega un nuevo fragmento, puede cambiar el título de la barra de acción, pero cuando lo backstack de backstack no hay manera de restaurar el título antiguo. Es posible que necesite una barra de herramientas en cada fragmento para este caso, pero créanme, eso le llevará 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 acción, menú, startActivityForResult , animación, ...

Answer 4

Depende de lo que quieras construir realmente. Por ejemplo, el navigation drawer utiliza fragmentos. Las pestañas también usan fragments . Otra buena implementación, es donde tienes una vista de 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.

Answer 5

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

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

El uso principal de los fragmentos es la creación de actividades múltiples, lo que lo hace perfecto para aplicaciones sensibles a tabletas / teléfonos.

Answer 6

Eres libre de usar uno de esos.
Básicamente, tienes que 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 acerca de cómo los fragmentos almacenan datos de basura. Cuando implementa el fragmento, tiene una raíz de actividad para rellenar con el (los) fragmento (s). Entonces, si está intentando implementar muchas actividades con demasiados fragmentos, debe considerar el rendimiento de su aplicación, porque está manipulando (habla en términos generales) el ciclo de vida de dos contextos, recuerde la complejidad.

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

Saludos.

Answer 7

Hay más en esto de lo que te das cuenta, debes recordar que una actividad que se inicia no destruye implícitamente la actividad de llamada. Claro, puedes configurarlo de modo que tu usuario haga clic en un botón para ir a una página, comiences la actividad de esa página y destruyas la actual. Esto provoca una gran cantidad de gastos generales. La mejor guía que te puedo dar es:

** Comience 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 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.

Answer 8

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

Answer 9

Los expertos le dirán: "Cuando vea la interfaz de usuario, sabré si usar una Activity o un Fragment ". Al principio esto no tendrá ningún sentido, pero con el tiempo, realmente podrá saber si necesita 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, imagina una caja que representa una pantalla. ¿Puedes cargar otra pantalla en este cuadro? Si usa un nuevo cuadro, ¿tendrá que copiar varios elementos del primer cuadro? Si la respuesta es Sí, entonces debería usar Fragments , ya que la Activity raíz puede contener todos los elementos duplicados para ahorrarle tiempo al crearlos, y simplemente puede reemplazar partes de la caja.

Pero no olvide que siempre necesita un contenedor de caja ( Activity ) o sus partes estarán dispersas. Así que una caja con partes dentro.

Tenga cuidado de no abusar de la caja. Los expertos en Android UX aconsejan (puedes encontrarlos en YouTube) cuando deberíamos 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 te sientas cómodo con Fragments , puedes ver todos sus videos. Aún más son material obligatorio.

¿Puedes ahora mismo mirar tu UI y descubrir si necesitas una Activity o un Fragment ? ¿Conseguiste una nueva perspectiva? Creo que lo hiciste.

Answer 10

Mi filosofía es esta:

Cree una actividad solo si es absolutamente necesario. Con el backstack disponible para realizar un montón de transacciones de fragmentos, trato de crear el 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 entre actividades.

Las transiciones de actividad son caras, ¿verdad? Al menos eso creo, ya que la actividad anterior se destruye / pausa / se detiene en la pila y luego se debe crear / iniciar / reanudar la nueva actividad.

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

Answer 11

Por eso prefiero Fragmento a Actividad en TODOS LOS CASOS.

• La actividad es cara. En Fragmento, las vistas y los estados de propiedad se separan, siempre que un fragmento se encuentre en el backstack , sus vistas se destruirán. Así que puedes apilar mucho más Fragmentos que Actividad.

• Manipulación del 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 y cuando la actividad de acogida no sea reciclada. Los Fragmentos en el backstack no serán reciclados. Por lo tanto, es posible usar FragmentManager::getFragments() para encontrar Fragmentos específicos (no se recomienda).

Answer 12

Uso Fragmentos para una mejor experiencia de usuario. Por ejemplo, si tiene un botón y desea ejecutar, digamos un servicio web cuando haga 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 manera 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.

Answer 13

use una actividad por aplicación para proporcionar una base para el uso de fragment para la pantalla, los fragments tienen un peso liviano en comparación con los fragmentos de activites que son reutilizables, son más adecuados para aplicaciones que admiten teléfonos y tabletas