trabajar - java android fragment

¿Cuántas actividades vs Fragmentos?

Question

Introducción:

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

1. En una tableta, tenga una lista a la izquierda, 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. Lanzar una nueva Activity con los detalles Fragment .

(por ejemplo, Android 3.0 Fragments API por Dianne Hackborn y la Fragments API Guide )

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

En la tableta , 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 duplica mucha de la lógica en la actividad principal de la tableta y en las actividades separadas del teléfono.

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

De esta manera, la mayor parte de la lógica reside en los propios Fragments , y solo hay una sola Activity : menos duplicación de código.

Además, lo que he leído sobre ActionBarSherlock es que parece funcionar mejor con Fragments lugar de Activities (pero aún no he trabajado con él).

¿Los tutoriales están simplificados demasiado, o me he perdido algo importante en este enfoque?

Hemos intentado con éxito ambos enfoques en la oficina, pero estoy a punto de comenzar un proyecto más grande y quiero que todo sea lo más fácil posible para mí.

Algunos enlaces a preguntas relacionadas:

• Dilema: cuándo usar Fragmentos vs Actividades:
• Patrones de cuándo utilizar la transición de actividad frente a los fragmentos dinámicos
• Android: necesito algunas aclaraciones sobre fragmentos, 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

Comencé a hacer preguntas generosas, todavía no estoy convencido de por qué necesito duplicar la lógica de mi aplicación en la actividad de mi tableta y en cada actividad del teléfono.

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

• Abogando contra los fragmentos de Android

Answer 1

Un problema con este método es que duplica mucha de la lógica en la actividad principal de la tableta y en las actividades separadas del teléfono.

En el patrón maestro-detalle, hay dos actividades. Uno muestra ambos fragmentos en pantallas más grandes y solo el fragmento "maestro" en pantallas más pequeñas. El otro 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 simplemente muestra el fragmento de detalle, tal vez al pasar datos de un Intent extra.

Además, lo que he leído sobre ActionBarSherlock es que parece funcionar mejor con Fragments en lugar de Activities (pero aún no he trabajado con él).

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

Answer 2

Aquí está la respuesta de Reto Meier con respecto a la misma, 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 única actividad monolítica aumenta la complejidad de su código, lo que dificulta su lectura, prueba y mantenimiento.
• Hace que crear y administrar filtros de intención sea mucho más difícil.
• Aumenta el riesgo de acoplar estrechamente componentes independientes.
• Hace que sea mucho más probable que se presenten riesgos de seguridad si la actividad individual incluye información delicada e información que es seguro compartir.

Una buena regla empírica es crear una nueva actividad cada vez que cambie el contexto. Por ejemplo, mostrar un tipo diferente de datos y al pasar de visualizar a ingresar datos.

Answer 3

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

En un diseño de tableta, puede usar una sola Actividad e intercambiar Fragmentos de entrada y salida (en múltiples "paneles"). Mientras estás en el diseño de un teléfono, puedes usar una nueva Actividad para cada Fragmento.

Al igual que:

Puede parecer mucho trabajo adicional, pero al utilizar múltiples actividades para teléfonos, habilita el ciclo de vida de actividad básico 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 usar una BaseActivity y ampliar desde allí.

Entonces, si el usuario tiene una tableta, debería usar MyMultiPaneFragActivity o algo similar. Esta actividad es responsable de gestionar las devoluciones de llamadas desde los fragmentos y las intenciones de enrutamiento hasta el fragmento correcto (como un intento de búsqueda)

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

La parte engañosa es intenciones de enrutamiento y otras cosas. * (Editar: vea más abajo).

Creo que la razón por la cual esta es la forma recomendada es para ahorrar memoria y reducir la complejidad y el acoplamiento. Si está intercambiando Fragmentos, FragmentManager mantiene una referencia a ese Fragmento para la pila de respaldo. También simplifica lo que debería estar ''ejecutándose'' 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 forma, 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 intención regular es que puedes iniciar una Actividad explícitamente desde cualquier lugar en la pila de respaldo. Un ejemplo podría ser en el caso de los resultados de búsqueda. (MySearchResults.class).

Lea aquí para obtener más información:

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

Puede ser un trabajo un poco más adelantado, porque cada fragmento debe funcionar bien en actividades separadas, pero generalmente vale la pena. Significa que puede usar archivos de diseño alternativos que definen diferentes combinaciones de fragmentos, mantener el código de fragmentos modular, simplificar la administración de la barra de acciones y dejar que el sistema maneje todo el trabajo de la pila de respaldo.

Answer 4

En referencia a la primera pregunta de "¿Hay alguna razón para dividir la aplicación del teléfono en muchas actividades?" - Sí. simplemente se reduce al espacio disponible, una tableta 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 . Entonces, lo que puede hacer con 1 pantalla grande en una tableta, es algo que puede tener que extenderse a través de varias pantallas en un teléfono, porque no hay espacio suficiente para todos los fragmentos.

Answer 5

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

También estoy de acuerdo en que no es una buena idea duplicar la lógica de su aplicación en muchas actividades (consulte el principio DRY en wikipedia ).

Prefiero el patrón utilizado por la aplicación de demostración de fragmentos de ActionBarSherlock ( descargue aquí y el código fuente aquí ). La demostración que más se aproxima al tutorial mencionado en la pregunta es la llamada "Diseño" en la aplicación; o FragmentLayoutSupport en el código fuente.

En esta demostración, la lógica se ha movido de la Activity interior del Fragment . El TitlesFragment realmente contiene la lógica para cambiar Fragmentos. De esta manera, cada actividad es muy simple. Duplicar muchas actividades muy simples, donde ninguna lógica está dentro de las actividades, lo hace muy simple.

Al poner 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 lo convierte en un patrón más poderoso 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 de ABS es que no se termina con una actividad de tableta que contiene mucha lógica, y eso significa que se ahorra memoria. El patrón de 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 él en cualquier momento.

En general, no piense que se lo obliga a usar muchas actividades. Piense que tiene la oportunidad de dividir el código en muchos fragmentos y guardar la memoria al usarlos.