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


158

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?


¿Puedes explicar por qué crees que la respuesta es no? No estoy de acuerdo, pero es más fácil abordar las preocupaciones que pueda tener sobre ese enfoque si sabemos cuáles son esas preocupaciones.
Alexander Lucas

1
@AlexanderLucas La respuesta que di no porque hacerlo hace que su código sea menos modular, aumenta la complejidad.
Vineet Shukla

@Ski Te estás concentrando más en que tu respuesta sea aceptada, por favor concéntrate en lo que se te pregunta y cuál debería ser la mejor respuesta que puedas proporcionar.
Vineet Shukla

3
Para cualquiera que encuentre esto, detuve el refactorizador porque las cosas se complicaron realmente rápido.
theblang

18
Esta es una buena pregunta y no debería haberse cerrado.
Jim In Texas

Respuestas:


94

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


66
Hay settargetfragmenty podrías manejar la actividad como un startforresultprocedimiento.
Lalith B

1
En mi opinión, las actividades existen solo porque es el viejo sistema. Fragmento no existía antes. Realmente no hay nada que las actividades puedan y los fragmentos no puedan, además de las formalidades. Incluso podría imaginar que en algún momento se eliminan las actividades y todo es un fragmento.
Ixx

1
Resumiendo los contras de los fragmentos que solo das, en realidad no hay ninguno. startActivityForResult como dice Lalith B tiene una contraparte, y los mapas tampoco son un problema. Además de eso, todo (estado de ahorro, etc.) se puede manejar con los métodos de ciclo de vida del fragmento.
Ixx

85

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

1
no estaba seguro de tener demasiados fragmentos y solo ahora actividad ... cualquier problema en la producción, ¡y la culpa es tuya! :)
Shahar

1
@Dinash no permita que el sistema operativo reinicie su actividad. maneja la orientación, cámbiate tú mismo. Lea más aquí: stackoverflow.com/questions/5913130/…
Tamas

1
@Tamas ¿Tenía alguna pantalla de fragmentos múltiples (por ejemplo, detalle maestro) y, de ser así, ¿cómo manejó eso?
theblang

77
@Tamas Este enfoque es muy anti Android. Terminas con la clase de DIOS. El sistema Android está diseñado para trabajar con actividades, por ejemplo, no tiene una buena manera de manejar las barras de herramientas dentro de múltiples fragmentos. No tiene un fragmento de inicio para el resultado y muchos más no tienen. Eso significa que tienes que reescribir toda la lógica que ya está allí. ¿Qué pasa con los receptores de transmisión local, servicios y otros componentes de Android? Para iniciar un servicio, debe hacer lo siguiente: getActivity ()! = Null ... esto es realmente feo. También la comunicación entre fragmentos es muy extraña si tienes mucho fr.
Teodor

9
700 lineas !!!! "bien"???? Las clases son gratis.
beplaya

16

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?


Hm ... la conexión entre crear instancias de una vista como una mala práctica y findViewById () public no está clara. Si bien estoy de acuerdo con la creación de instancias de vistas, también considero que llamar a findViewById desde otra clase (por ejemplo, la actividad que aloja un fragmento lo llama en el fragmento) una mala práctica. Realmente no sé por qué esto es público, ya que, al menos en los casos en que puedo pensar, esto da como resultado un código desordenado y no un diseño modular.
Ixx

En mi humilde opinión: si pasa una actividad a su vista y presentador (llamando a los 2 combinados como "módulo"), puede volver a utilizar ese módulo con otras actividades. Si ayuda, puede ser mejor pasar la actividad como una intrfce que exponga solo los cambios necesarios. Si odias encontrar vistas fuera de la actividad, entonces podrías inyectar todas las vistas, a través de esa interfaz, en la vista / pres. El punto principal es que creo que la codificación de Android debe hacerse fuera del concepto de Actvities and Frags, por lo que cambiar entre los 2 es fácil. Entonces, queda claro qué es lo mejor y no estás atrapado con uno u otro dentro de una red de código.
beplaya

3
Suelta el MVP, estarás mejor sin él con Android. Puede pasar mucho tiempo tratando de colocar un determinado bloque de forma a través de un orificio que tiene una forma diferente, seguro que es un desafío, pero probablemente haya requisitos funcionales en los que sería más sabio pasar el tiempo.
straya

12

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.


2

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.


1

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.


Para la orientación, no es necesario utilizar diferentes diseños basados ​​en xml.
Vineet Shukla

@VineetShukla es cierto, pero es una opción, al igual que el uso de diferentes diseños xml en función del tamaño de la pantalla. Por ejemplo, la pantalla de inicio de mi teléfono Android tiene un diseño diferente cuando la veo en orientación horizontal versus vertical.
Ski

0

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.


"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". -> No es comprensible lo que quieres decir exactamente, pero ni las pestañas ni el menú lateral son un problema en una aplicación de una sola actividad (tableta / teléfono).
Ixx

-1

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.


44
No creo que esto sea cierto. De la documentación del ciclo de vida del fragmento ( developer.android.com/guide/components/fragments.html#Lifecycle ): "El ciclo de vida de la actividad en la que vive el fragmento afecta directamente el ciclo de vida del fragmento, de modo que cada devolución de llamada del ciclo de vida para la actividad da como resultado una devolución de llamada similar para cada fragmento. Por ejemplo, cuando la actividad recibe onPause (), cada fragmento de la actividad recibe onPause () ".
Ski
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.