Cuántas Actividades vs Fragmentos?

Introducción:

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

  1. En una tablilla, tenga una lista a la izquierda, detalles a la derecha.
  2. Ambos son Fragments y ambos residen en el mismo Activity.
  3. En un teléfono, tener un list Fragment in one Activity.
  4. Lanza un nuevo Activity con los detalles Fragment.

(por ejemplo, Android 3.0 Fragments API de Dianne Hackborn y la Guía Fragments API )

En ambos dispositivos, la funcionalidad está en el Fragments. (simple)

En el Tablet, el conjunto de la aplicación es 1 Activity, en el teléfono hay muchos Activities.

Preguntas:

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

Un problema con este método, es que duplicar una gran cantidad de la lógica {[61] } en la Tableta principal Activity, y en el Teléfono separado Activities.

  • ¿No sería más fácil mantener el modelo de actividad 1 en ambos casos, ¿usando la misma lógica de cambiar Fragments de entrada y salida (solo usando un diseño diferente)?

De esta manera la mayor parte de la lógica reside en los Fragments mismos, y solo hay una única Activity - menos duplicación de código.

También lo que he leído sobre el {[15] } es que parece funcionar mejor con Fragments en lugar de Activities (pero no he trabajado con él aun).

¿Están los tutoriales simplificados, o me he perdido algo importante en este enfoque?

Hemos intentado ambos enfoques con éxito en la oficina, pero estoy a punto de comenzar un proyecto más grande y quiero hacer las cosas lo más fáciles posible para mí.

Algunos enlaces a preguntas relacionadas:

Actualizaciones

Comenzó bounty en la pregunta-todavía no está convencido de por qué necesito duplicar la lógica de mi aplicación en mi tableta actividad y en cada actividad del teléfono.

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

Author: Community, 2012-09-11
Source

5 answers

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 a través de muchas Actividades (ver Principio SECO en wikipedia).

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

En esta demo, la lógica ha sido movida fuera de Activity y dentro de Fragment. El TitlesFragment en realidad contiene la lógica para cambiar Fragmentos. De esta manera, cada Actividad es muy simple. Duplicar muchas Actividades muy simples, donde ninguna de la 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; es disponible sin importar en qué Actividad se coloque 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 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 conducir 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 cuando quieras.

En general, no piense que se ve obligado a usar muchas actividades. Piense en ello como tener la oportunidad de dividir su código en muchos fragmentos y ahorrar memoria al usarlos.

 41
Author: Stephen Asherson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-09-21 10:06:46

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

En un diseño de tableta, puede usar una sola actividad e intercambiar fragmentos de entrada y salida (en múltiples 'paneles'). Mientras esté en un diseño de teléfono, puede usar una nueva actividad para cada fragmento.

Así:

introduzca la descripción de la imagen aquí

Puede parecer mucho trabajo extra, pero al usar múltiples actividades para teléfonos, habilita el ciclo de vida de la actividad básica y el paso de la intención. Esto también permite que el marco para maneja todas las animaciones y el back-stack.

Para ayudar a reducir el código se puede utilizar un BaseActivity y ampliar a partir de eso.

Entonces, si el usuario tiene una tableta, usaría MyMultiPaneFragActivity o algo similar. Esta actividad es responsable de administrar las devoluciones de llamada de los fragmentos y enrutar las intents al fragmento correcto (como una intent de búsqueda)

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

La parte difícil es enrutar las intenciones y demás. *(Edit: ver más abajo).

Creo que la razón por la que esta es la forma recomendada es para ahorrar memoria y reducir la complejidad y el acoplamiento. Si está intercambiando Fragmentos, el FragmentManager mantiene una referencia a ese Fragmento para el back-stack. También simplifica lo que debería estar 'corriendo' 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 (de dos paneles), o en una Actividad de tres paneles, etc.

*Uno de los beneficios de tener enrutamiento de intención regular es que puede iniciar una actividad explícitamente desde cualquier lugar de la pila de respaldo. Un ejemplo podría ser en el caso de los resultados de búsqueda. (MySearchResults.clase).

Tenga una lectura aquí para más:

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

Podría ser un poco más de trabajo inicial, porque cada fragmento debe funcionar bien a través de actividades separadas, pero generalmente vale la pena. Esto significa que puede usar archivos de diseño alternativos que definen diferentes combinaciones de fragmentos, mantienen el código de fragmentos modular, simplifican la administración de la barra de acciones y permiten que el sistema maneje todo el trabajo de back stack.

 17
Author: pjco,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-09-11 07:40:29

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

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

  • Tener una sola actividad monolítica aumenta la complejidad de su código, haciendo que sea difícil de leer, probar y mantener.
  • Hace que crear y administrar filtros de intención sea mucho más difícil.
  • Aumenta la riesgo de acoplamiento estrecho de componentes independientes.
  • Hace que sea mucho más probable introducir riesgos de seguridad si la actividad individual incluye tanto información confidencial como información que es segura para compartir.

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

 6
Author: Aditya Naique,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-05-14 05:32:58

Un problema con este método, es que duplica una gran cantidad 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 "detail" 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 lógica de detalle entre actividades the la actividad de detalle simplemente muestra el fragmento de detalle, tal vez pasando datos de un Intent extra.

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

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

 4
Author: CommonsWare,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-09-24 12:30:42

Refiriéndose a la 1a pregunta de "¿Hay una 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 puedes hacer con 1 pantalla grande en una tableta, es algo que puede tener que extenderse a través de múltiples pantallas en un teléfono, porque no hay suficiente espacio para todos los fragmento.

 0
Author: EFlisio,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-05-24 17:18:28