Estoy pensando en implementar una pantalla con Activity
y todas las demás pantallas con Fragments
y 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:
- Los fragmentos están destinados a ser utilizados con actividades como una sub-actividad.
- Los fragmentos no son el reemplazo de las actividades.
- Los fragmentos están destinados a la reutilización (es necesario saber de qué manera se puede lograr la reutilización).
- Los fragmentos son la mejor manera de escribir código para admitir tanto tabletas como teléfonos.
Contras:
- Necesitamos implementar la interfaz para obtener los datos de los fragmentos.
- 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?
Respuestas:
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
Activity
enfoque único y una navegación al estilo de Facebook. Al seleccionar elementos de la lista de navegación, actualizo un soloFragment
contenedor para mostrar esa sección.Dicho esto, tener un single
Activity
tambié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,startActivityForResult
peroFragments
no existe tal cosa, por lo que terminas almacenando el valor enActivity
y haciendo que el fragmento de edición principal verifiqueActivity
si los datos se han seleccionado y deberían mostrarse al usuario.Lo que dice Aravind acerca de estar atrapado en un solo
Activity
tipo también es cierto, pero en realidad no es tan limitante. Su actividad sería una FragmentActivity y, mientras no la necesiteMapView
, no existen limitaciones reales. Sin embargo, si desea mostrar mapas, puede hacerlo, pero deberá modificar la Biblioteca de compatibilidad de Android paraFragmentActivity
ampliarlaMapActivity
o usar el android-support-v4-googlemaps disponible públicamente .En última instancia, la mayoría de los desarrolladores que conozco que fueron por una
Activity
ruta 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 solaActivity
para lograr la interacción loca que tus diseñadores inventan :)- EDITAR -
Google finalmente ha lanzado
MapFragment
a 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
fuente
settargetfragment
y podrías manejar la actividad como unstartforresult
procedimiento.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
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.Contras
fuente
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?
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?
fuente
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 estadoonSaveInstanceState
y 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
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.
fuente
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.
fuente
Pros:
Contras:
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.
fuente
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.
fuente
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
onPause
yonResume
. 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.fuente