Una actividad y todos los demás fragmentos [cerrado]

Estoy pensando en implementar una pantalla con Activityy todas las demás pantallas con Fragmentsy managing all the fragments thru the activity.

¿Es una buena idea? y mi respuesta es NO, pero aún quiero saber más claramente sobre este pensamiento.

¿Cuáles son los pros y los contras de la idea?

Nota:

No me des el enlace para el fragmento y la actividad.

EDITAR:

Aquí hay algo sobre Fragmentos y actividad:

Pros:

1. Los fragmentos están destinados a ser utilizados con actividades como una sub-actividad.
2. Los fragmentos no son el reemplazo de las actividades.
3. Los fragmentos están destinados a la reutilización (es necesario saber de qué manera se puede lograr la reutilización).
4. Los fragmentos son la mejor manera de escribir código para admitir tanto tabletas como teléfonos.

Contras:

1. Necesitamos implementar la interfaz para obtener los datos de los fragmentos.
2. Para el diálogo tenemos que recorrer un largo camino para mostrarlo.

¿Por qué deberíamos usar fragmentos si no estamos considerando tabletas? ¿Cuál es la diferencia de tiempo de inicio entre actividad y fragmento?

Depende de la aplicación que esté creando. He creado varias aplicaciones usando ambos enfoques y no puedo decir que una forma siempre es mejor que la otra. La última aplicación que creé usé el Activityenfoque único y una navegación al estilo de Facebook. Al seleccionar elementos de la lista de navegación, actualizo un solo Fragmentcontenedor para mostrar esa sección.

Dicho esto, tener un single Activitytambién introduce muchas complejidades. Digamos que tiene un formulario de edición, y para algunos de los elementos que el usuario necesita seleccionar o crear, requiere que vayan a una nueva pantalla. Con las actividades simplemente llamaríamos a la nueva pantalla, startActivityForResultpero Fragmentsno existe tal cosa, por lo que terminas almacenando el valor en Activityy haciendo que el fragmento de edición principal verifique Activitysi los datos se han seleccionado y deberían mostrarse al usuario.

Lo que dice Aravind acerca de estar atrapado en un solo Activitytipo también es cierto, pero en realidad no es tan limitante. Su actividad sería una FragmentActivity y, mientras no la necesite MapView, no existen limitaciones reales. Sin embargo, si desea mostrar mapas, puede hacerlo, pero deberá modificar la Biblioteca de compatibilidad de Android para FragmentActivityampliarla MapActivityo usar el android-support-v4-googlemaps disponible públicamente .

En última instancia, la mayoría de los desarrolladores que conozco que fueron por una Activityruta han vuelto a múltiples Actividades para simplificar su código. En cuanto a la interfaz de usuario, en una tableta, a veces te quedas atascado usando una sola Activitypara lograr la interacción loca que tus diseñadores inventan :)

- EDITAR -

Google finalmente ha lanzado MapFragmenta la biblioteca de compatibilidad para que ya no tenga que usar el hack de android-support-v4-googlemaps. Lea sobre la actualización aquí: Google Maps Android API v2

- EDITAR 2 -

Acabo de leer esta gran publicación sobre el estado moderno de los fragmentos (2017) y recordé esta vieja respuesta. Pensé que compartiría: Fragmentos: la solución a todos los problemas de Android

Estoy a punto de terminar un proyecto (5 meses en desarrollo), que tiene 1 actividad y 17 fragmentos, todos a pantalla completa. Este es mi segundo proyecto basado en fragmentos (el anterior era de 4 meses).

Pros

• La actividad principal es 700 líneas de código, que gestionan muy bien el orden de la navegación de fragmentos.
• Cada fragmento está muy bien separado en su propia clase, y es relativamente pequeño (~ un par de cientos de líneas de material de interfaz de usuario).
• La gerencia puede decir, "oye, ¿qué tal si cambiamos el orden de esas pantallas", y puedo hacerlo muy fácilmente, ya que esos fragmentos no dependen el uno del otro, todos se comunican a través de la actividad. No tengo que buscar actividades individuales para encontrar dónde se llaman entre sí.
• mi aplicación tiene muchos gráficos y nunca funcionaría como 1 pantalla 1 actividad. Todas esas actividades secundarias en la memoria harían que la aplicación se quedara sin memoria todo el tiempo, por lo que tendría que hacer finish()todas las actividades no visibles y hacer la misma lógica de control para la navegación, como lo haría con los fragmentos. También podría hacerlo con fragmentos solo por esto.
• si alguna vez hacemos una aplicación de tableta, nos será más fácil refactorizar, porque todo ya está bien separado.

Contras

• tienes que aprender a usar fragmentos

Primero, hagas lo que hagas, asegúrate de tener un diseño modular que utilice el modelo, la vista y el presentador que no dependan mucho de una actividad o un fragmento.

¿Qué proporcionan realmente las actividades y los fragmentos?

1. Eventos del ciclo de vida y backstack
2. Contexto y recursos

Por lo tanto, úselos para eso, SOLO . Tienen suficiente responsabilidad, no los compliques demasiado. Yo diría que incluso la inmovilización de TextView en una actividad o fragmento es una mala práctica. Hay una razón por la cual los métodos como Public View findViewById (int id) son PUBLIC .

Ahora la pregunta se simplifica: ¿Necesito múltiples eventos de ciclo de vida independientes y backstacks? Si piensas que sí, tal vez, usa fragmentos. Si piensas que nunca jamás, no uses fragmentos.

Al final, podrías hacer tu propia pila y ciclos de vida. Pero, ¿por qué recrear la rueda?

EDITAR: ¿Por qué rechazar votar esto? Clases de un solo propósito personas! Cada actividad o fragmento debe ser capaz de crear una instancia de un presentador que instancia una vista. El presentador y la vista son un módulo que se puede intercambiar. ¿Por qué una actividad o fragmento debe tener la responsabilidad de un presentador?

Pros

Podrías controlar tus fragmentos desde una sola actividad, porque todos los fragmentos son independientes entre sí. Los fragmentos tienen un ciclo de vida ( onPause, onCreate, onStart...) de los suyos. Al tener un ciclo de vida, los fragmentos pueden responder de forma independiente a los eventos, guardar su estado onSaveInstanceStatey regresar (es decir, cuando se reanuda después de una llamada entrante o cuando el usuario hace clic en el botón Atrás).

Contras

1. Crea complejidad en tu código de actividad.
2. Tienes que gestionar el orden de los fragmentos.

Sin embargo, es una buena idea, ya que necesita crear una aplicación, donde desea mostrar varias vistas. Con esta idea, podrá ver varios fragmentos en una sola vista.

Depende del diseño de su aplicación. Suponga que si usa pestañas en ActionBar en el diseño de diseño, en la actividad individual de la aplicación se pueden cambiar fragmentos al hacer clic en Tab. Entonces, ahora tiene una actividad y, digamos, suponga que tres pestañas en la barra de acciones y la vista de las pestañas proporcionadas por los fragmentos, lo que hace que sea más fácil de administrar, también es factible. Por lo tanto, todo depende del esquema de diseño de su aplicación y de cómo toma la decisión de crearla.

Pros:

• Se puede utilizar para crear una interfaz única que se pueda utilizar con múltiples tamaños de pantalla y orientaciones a través de diseños xml.

Contras:

• Requiere código más complejo en su actividad.

Creo que es una buena idea, porque el uso de diferentes diseños xml basados ​​en el tamaño y la orientación de la pantalla actual puede hacer que la aplicación sea más útil y reducir la necesidad de lanzar múltiples versiones de su aplicación si planea lanzar su aplicación para teléfonos y tabletas. Si su aplicación nunca será utilizada por tabletas y teléfonos, probablemente no valga la pena.

Soy partidario de diferir toda la inflación de vistas a fragmentos para proporcionar una mejor flexibilidad. Por ejemplo, tener una única actividad de aterrizaje para una tableta que agrega múltiples fragmentos y reutiliza los mismos fragmentos en un teléfono para mostrar una pantalla por fragmento. Sin embargo, en la implementación del teléfono, tendría una actividad separada para cada pantalla. Las actividades no tendrían demasiado código, ya que diferirían inmediatamente a su contraparte fragmentada para ver la inflación.

Creo que es una mala idea que la implementación del teléfono tenga que cambiar a una sola actividad de aterrizaje cuando se introducen pestañas o un menú deslizable, ya que la navegación de pestañas o menús solo da como resultado una pantalla completamente nueva.

La razón más importante que daría por no usar el enfoque de actividad única es para que se pueda aprovechar el ciclo de vida de la actividad. Las actividades contienen el comportamiento contextual de una determinada porción de la aplicación y los fragmentos complementan ese comportamiento. Tener la capacidad de aprovechar los pasos reemplazables en el ciclo de vida de la actividad ayuda a separar el comportamiento de una actividad de otra con métodos como onPausey onResume. Este ciclo de vida también le permite volver al contexto anterior. Con el enfoque de actividad única, una vez que deja un fragmento, debe crear un mecanismo para volver a él.