¿Cuántas actividades vs fragmentos?

Intro:

El patrón básico de "Fragmentos Tutorial" es algo como esto:

  1. En una tableta, tiene una lista a la izquierda, los detalles a la derecha.
  2. Ambos son Fragments y ambos residen en la misma Activity .
  3. En un teléfono, tenga una lista Fragment en una Activity .
  4. Inicie una nueva Activity con los detalles Fragment .

(Por ejemplo, la API de fragmentos de Android 3.0 de Dianne Hackborn y la Guía de la API de fragmentos )

En ambos dispositivos, la funcionalidad está en los Fragments . (sencillo)

En el Tablet , toda la aplicación es 1 Activity , en el teléfono , hay muchas Activities .


Preguntas:

  • ¿Hay alguna razón para dividir la aplicación del teléfono en muchas Activities ?

Un problema con este método, es que se duplica una gran parte de la lógica en la actividad principal de Tablet, y en las Activities teléfono por separado.

  • ¿No sería más fácil retener el modelo de 1 Actividad en ambos casos, usando la misma lógica de cambiar Fragments dentro y fuera (simplemente usando un diseño diferente)?

De esta manera la mayor parte de la lógica reside en los Fragments sí, y sólo hay una sola Activity – menos duplicación de código.

También lo que he leído sobre el ActionBarSherlock es que parece funcionar mejor con Fragments lugar de Activities (pero no he trabajado con él todavía).

¿Son los tutoriales demasiado simplificados, o he perdido algo importante en este enfoque?


Hemos probado ambos enfoques con éxito en la oficina – pero estoy a punto de iniciar un proyecto más grande y quiero hacer las cosas lo más fácil para mí como sea posible.

Algunos enlaces a preguntas relacionadas:

  • Dilema: cuándo utilizar Fragmentos vs Actividades:
  • Patrones de uso de la actividad Transición vs Fragmentos dinámicos
  • Android – necesito algunas aclaraciones de fragmentos vs actividades y vistas
  • Actividades o fragmentos en Android?
  • Diseño de interacción de múltiples fragmentos y actividades
  • ¿Cuáles son las ventajas exactas de Fragments en Android 3.0?

Actualizaciones

Comenzó la recompensa en cuestión – todavía no está convencido de por qué tengo que duplicar la lógica de mi aplicación en la actividad de mi tablet y en cada actividad de teléfono.

También encontramos un interesante artículo de los chicos de Square, que vale la pena leer:

  • Abogando contra Fragmentos de Android

Estoy de acuerdo en que los tutoriales son muy simplificados. Simplemente introducen Fragments pero no estoy de acuerdo con el patrón sugerido.

También estoy de acuerdo en que no es una buena idea duplicar la lógica de su aplicación a través de muchas actividades (ver Principio DRY en wikipedia ).


Yo prefiero el patrón utilizado por la aplicación de demostración ActionBarSherlock Fragments ( descargar aquí y código fuente aquí ). La demo que más se aproxima al tutorial mencionado en la pregunta es la que se llama "Layout" en la aplicación; O FragmentLayoutSupport en el código fuente.

En esta demostración, la lógica se ha movido fuera de la Activity y en el Fragment . El TitlesFragment contiene la lógica para cambiar Fragments. De esta manera, cada Actividad es muy simple. Para duplicar muchas actividades muy simples, donde ninguna de las lógicas está dentro de las Actividades, lo hace muy simple.

Poniendo la lógica en los Fragmentos, no hay necesidad de escribir el código más de una vez ; Está disponible sin importar en qué actividad se encuentre el fragmento. Esto hace que sea un patrón más potente que el sugerido por el tutorial básico.

  /** * Helper function to show the details of a selected item, either by * displaying a fragment in-place in the current UI, or starting a * whole new activity in which it is displayed. */ void showDetails(int index) { mCurCheckPosition = index; if (mDualPane) { // We can display everything in-place with fragments, so update // the list to highlight the selected item and show the data. getListView().setItemChecked(index, true); // Check what fragment is currently shown, replace if needed. DetailsFragment details = (DetailsFragment) getFragmentManager() .findFragmentById(R.id.details); if (details == null || details.getShownIndex() != index) { // Make new fragment to show this selection. details = DetailsFragment.newInstance(index); // Execute a transaction, replacing any existing fragment // with this one inside the frame. FragmentTransaction ft = getFragmentManager() .beginTransaction(); ft.replace(R.id.details, details); ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE); ft.commit(); } } else { // Otherwise we need to launch a new activity to display // the dialog fragment with selected text. Intent intent = new Intent(); intent.setClass(getActivity(), DetailsActivity.class); intent.putExtra("index", index); startActivity(intent); } } 

Otra ventaja del patrón ABS es que no termina con una actividad de tableta que contiene mucha lógica, y eso significa que ahorra memoria. El patrón tutorial puede llevar a una actividad principal muy grande en una aplicación más compleja; Ya que necesita manejar la lógica de todos los fragmentos que se colocan en ella en cualquier momento.

En general, no pienses que está obligado a utilizar muchas actividades. Piense en él como teniendo la oportunidad de dividir su código en muchos fragmentos, y ahorrar memoria al usarlos.

Creo que estás en el camino correcto. (Y sí, los tutoriales están sobre-simplificados).

En un diseño de tableta, puede utilizar una única actividad y intercambiar fragmentos de entrada y salida (en varios paneles). Mientras que en una disposición del teléfono usted puede utilizar una nueva actividad para cada fragmento.

Al igual que:

Introduzca aquí la descripción de la imagen

Puede parecer un montón de trabajo adicional, pero al usar múltiples actividades para teléfonos, habilita el ciclo de vida básico de Actividad y el paso de Intención. Esto también permite que el marco maneje todas las animaciones y el back-stack.

Para ayudar a reducir el código, puede utilizar una BaseActivity y extender desde eso.

Así que si el usuario tiene una tableta que se utiliza MyMultiPaneFragActivity o algo similar. Esta actividad es responsable de gestionar las devoluciones de llamada de los fragmentos y las intenciones de enrutamiento al fragmento correcto (como una intención de búsqueda)

Si el usuario tiene un teléfono, puede usar una Actividad normal con muy poco código y hacer que extienda MyBaseSingleFragActivity o algo similar. Estas actividades podrían ser muy simples, 5-10 líneas de código (tal vez incluso menos).

La parte difícil es las intenciones de enrutamiento y lo que no. * (Editar: ver más abajo).

Creo que la razón de esto es la forma recomendada es ahorrar memoria y reducir la complejidad y el acoplamiento. Si está intercambiando Fragmentos, el FragmentManager mantiene una referencia a ese Fragmento para la pila posterior. También simplifica lo que debería ser 'correr' para el usuario. Esta configuración también desacopla las vistas y el diseño y la lógica en el fragmento del ciclo de vida de la actividad. De esta manera un fragmento puede existir en una sola actividad, junto con otro fragmento (dos paneles), o en una actividad de tres paneles, etc.

* Uno de los beneficios de tener un enrutamiento de intenciones regulares es que puede iniciar una Actividad explícitamente desde cualquier parte de la pila posterior. Un ejemplo podría ser en el caso de los resultados de búsqueda. (MySearchResults.class).

Lea aquí para más información:

http://android-developers.blogspot.com/2011/09/preparing-for-handsets.html

Podría ser un poco más trabajo inicial, porque cada fragmento debe funcionar bien a través de actividades separadas, pero por lo general vale la pena. Esto significa que puede utilizar archivos de diseño alternativos que definen diferentes combinaciones de fragmentos, mantener modular el código de fragmentos, simplificar la administración de la barra de acción y dejar que el sistema maneje todo el trabajo de la pila trasera.

Aquí está la respuesta de Reto Meier con respecto a lo mismo, tomada de este video del curso de Fundamentos de Android de Udacity .

Hay una serie de razones por las que sería mejor romper su aplicación en diferentes actividades.

  • Tener una sola actividad monolítica aumenta la complejidad de su código, por lo que es difícil de leer, probar y mantener.
  • Hace que la creación y gestión de filtros de intenciones sea mucho más difícil.
  • Aumenta el riesgo de acoplamiento de componentes independientes.
  • Hace mucho más probable que introduzca riesgos de seguridad si la actividad única incluye información sensible e información que es segura para compartir.

Una buena regla es crear una nueva actividad cada vez que cambie el contexto. Por ejemplo, mostrar un tipo diferente de datos y pasar de la visualización a la introducción de datos.

Un problema con este método, es que se duplica una gran parte de la lógica en la actividad principal de Tablet, y en las actividades de teléfono por separado.

En el patrón de detalle maestro, hay dos actividades. Uno muestra ambos fragmentos en pantallas más grandes y sólo el fragmento "maestro" en pantallas más pequeñas. La otra muestra el fragmento de "detalle" en pantallas más pequeñas.

Su lógica de detalle debe estar atada en el fragmento de detalle. Por lo tanto, no hay duplicación de código relacionada con la lógica de detalle entre actividades – la actividad de detalle muestra simplemente el fragmento de detalle, tal vez pasando los datos de un Intent extra.

También lo que he leído sobre el ActionBarSherlock es que parece funcionar mejor con Fragmentos en lugar de Actividades (pero no he trabajado con él todavía).

ActionBarSherlock no tiene más que ver con fragmentos que la barra de acción nativa, ya que ActionBarSherlock es puramente un backport de la barra de acción nativa.

Refiriéndose a la primera pregunta de "¿Hay una razón para dividir la aplicación de teléfono en muchas actividades?" – Sí. Simplemente se reduce al espacio disponible, un Tablet da más espacio a los desarrolladores, lo que permite a los desarrolladores poner más en una pantalla. Android nos dice que las actividades pueden proporcionar una pantalla . Así que lo que puede hacer con una pantalla grande en una tableta, es algo que puede tener que ser repartidos a través de múltiples pantallas en un teléfono, porque no hay suficiente espacio para todos los fragmentos.

  • ListFragment da ListView cuyo atributo id es 'android.R.id.list'
  • Cambiar la fuente del fragmento de lista en el fragmento de detalle
  • Android ListFragment: cómo tener tanto onListItemClick y onContextItemSelected?
  • Creación de un adaptador de cursor simple personalizado
  • Duplicación de filas listview en el fragmento de lista en el cambio de orientación
  • Pie de página fijo y siempre visible debajo de ListFragment
  • Cómo cambiar fragmento de forma programática en FragmentPagerAdapter?
  • Filtrar un ListFragment de la ActionBar en la actividad de los padres
  • Fragmento ya activo - Al intentar establecerArgumentos
  • No se ha encontrado ninguna vista para id en Android FragmentActivity con ListFragment
  • Android - ListFragment dentro DialogFragment (AlertDialog): Fragmento no tiene una vista
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.