Fragmentos parece ser excesivo? No es posible la arquitectura MVC?

Question

comencé con fragmentos hace unos días, pero parece cableado para mí. No veo la ventaja justificada para el gran aumento de la complejidad. No sé, si debería implementar la funcionalidad en mi Actividad o en mi Fragmento. Primero, traté de ponerlo en los fragmentos, pero a menudo parece que no es posible.

Por ejemplo: Tengo un cuadro de diálogo como entrada de usuario, después de hacer clic en el botón. Transfirí el botón clic a través del oyente de fragmento a actividad y en la actividad abrí el diálogo. En el diálogo comencé nuevas funciones (por lo que la implementación en la Actividad). dev Android da la pista para añadir un diálogo de alerta en un fragmento:

http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/FragmentAlertDialog.html

Pero este fragmento todavía se implementa y pesado junto con el (la acción del botón del cuadro de diálogo está en la actividad) activty.

Así que el modelo y la vista están mezclados. ¡No veo un valor adicional en un código estático tan difícil de mantener!

¿Cuál es su opinión y consejo acerca de los fragmentos?

Answer 1

Al utilizar Fragments, se puede pensar en ellos como el View y la Activity como el Controller . En mi opinión personal, Fragments fue la reacción instintiva de Google para admitir tabletas, y ahora estamos atrapados con ellas :(

Uso fragmentos todos los días, y ciertamente siento tu dolor. Cuando leí por primera vez sobre ellos, pensé en mí mismo , "esto es realmente genial", pero después de usarlos, se quedan cortos en lo que de muchas maneras, pero sobre todo porque usaría de forma incorrecta :(

Estas son algunas de las trampas que me encontré ...

1. No use onclick en el diseño de su fragmento, ya que es el Activity y NO el Fragment que manejará el clic. Si usa el atributo y luego usa el fragmento en otro Activity, entonces deberá recordar agregar el método onclick a ese Activity también. Por lo tanto, utilice un findViewById y luego coloque manualmente el manejador de clics en el fragmento onCreateView.

2. Al comunicarse con otros fragmentos, use Activity como el controlador para dirigir el mensaje. (Muchos ejemplos de cómo hacer esto usando interfaces). La clave aquí es que si está ejecutando múltiples fragmentos en un dispositivo donde un fragmento se comunicará directamente con otro fragmento, entonces se encontrará con un comportamiento extraño pero predecible. Por ejemplo, si el Fragmento A actualizó directamente una Vista en el Fragmento B, pero el Fragmento B no está visible (porque lo ha reemplazado, considere un teléfono), cuando el Fragmento B esté visible, entonces el View no podrá actualizarse, ya que View se recrea. Por lo tanto, si actualiza un Fragment asegúrese de actualizar los datos en un fragmento y luego actualice las porciones View en el onCreateView que se llama cuando el fragmento se vuelve a visualizar (es decir, ha reventado el fragmento actual, ahora muestra el anterior uno)

3. No cree una aplicación completa solo con fragmentos. En lugar de crear aplicaciones como lo haría normalmente, utilizando Actividades y luego tratar el Fragment tiene una vista glorificada (que es). es decir, diseña la aplicación de modo que tengas múltiples fragmentos y múltiples actividades, y algunas actividades pueden usar más de 1 fragmento.

Mi primer pensamiento con fragmentos fue uno en el que pensé que sería genial para construir una aplicación completa usando fragmentos y una actividad ... Finalmente he terminado la aplicación, pero me encontré con tantos problemas que utilizan enfoque. Mi siguiente enfoque fue utilizar múltiples fragmentos y múltiples actividades y fue mucho mejor.

El fondo es que los fragmentos son grandes si se utilizan como View, pero si comienza a tratar de utilizarlos como Actividades, entonces van a tener problemas :(Piense en el Activiy ->Fragment como el ser el Controller ->View.

también recomiendo que lea y entienda el Fragmento del ciclo de vida, además de la actividad del ciclo de vida (Pro Android 4 tiene una gran calidad de imagen que la represente) y se ahorrará horas de dolor :)

Answer 2

Los fragmentos proporcionan la lógica de vista para que sean portátiles para otras actividades. En su mayor parte, las actividades se están convirtiendo más en el papel de un verdadero controlador. En las arquitecturas anteriores de Android, la lógica de la vista y la lógica del controlador se fusionaron porque nadie subocluyó la Vista para implementar la mayor parte de su aplicación. Básicamente hicieron el diseño en los archivos de diseño XML, luego extrajeron los objetos de Vista directamente en la Actividad. Eso significaba que la Actividad estaba registrando oyentes de clics, oyentes clave, lógica de arrastre, etc. que normalmente es lo que harías en otra subclase de Vista en otros kits de herramientas. Debido a que lo hicieron, significó que el gesto multitáctil que arrastraba muy bien ListView que acababas de codificar estaba atascado en esa actividad. Ahora quiere usar eso nuevamente en otra Actividad. Bueno, eres S.O.L. Con los Fragmentos puedes mover más fácilmente esa lógica de la Actividad a un Fragmento. Ahora, técnicamente, podría moverlo a una vista de componente personalizada, pero los fragmentos proporcionan otra ventaja, que son los Fragmentos, que le permiten escribir aplicaciones que pueden ejecutarse en tabletas y dispositivos más pequeños al mismo tiempo que varían el diseño de cada una. Es complicado entender cómo funciona, pero una sola actividad puede contener varios fragmentos con diferentes diseños para cada factor de forma. Algo que un componente personalizado no puede lograr casi tan fácilmente. Además, los componentes personalizados no pueden usar archivos de diseño. Tienes que ir al código completo de Java, algo que no tienes que renunciar a los Fragmentos.

Creo que el ejemplo que proporcionó es un enfoque rápido y sucio para diseñar Fragmentos. De la misma manera, puede extraer fácilmente la referencia retrospectiva (alcance nido de esto) extrayendo una interfaz a la que delegue el Fragmento.

Answer 3

Ok, lo tengo funcionando con la arquitectura mv ...

public AlertDialog openLocInput() { 

    AlertDialog.Builder alert = new AlertDialog.Builder(getActivity()); 
    alert.setTitle("Login"); 
    alert.setMessage("Enter Pin :"); 

    // Set an EditText view to get user input 
    final EditText input = new EditText(getActivity()); 
    alert.setView(input); 

    alert.setPositiveButton("Ok", new DialogInterface.OnClickListener() { 
     public void onClick(DialogInterface dialog, int whichButton) { 
      jsonHandler.obtainMessage(1, input.getText().toString()) 
        .sendToTarget(); 
      dialog.dismiss(); 
      return; 
     } 
    }); 

    alert.setNegativeButton("Cancel", 
      new DialogInterface.OnClickListener() { 

       public void onClick(DialogInterface dialog, int which) { 
        dialog.dismiss(); 
        return; 
       } 
      }); 
    return alert.create(); 
} 

implementado en Fragmento ... a partir de este fragmento de alertdialog:

 fragment_userlocation_btn_addLocation.setOnClickListener(new OnClickListener() { 

     public void onClick(View v) { 
      openLocInput().setOwnerActivity(getActivity()); 
      openLocInput().show(); 
     } 
    }); 

también implementarse en fragmentos.

Pero todavía creo en la teoría exageración ...

creo < 5% de mi interfaz de usuario se volverá a utilizar, por lo que es recomendable mezclar fragmentos de las actividades de carga y actividades que incluyen la lógica de la interfaz de usuario sin fragmentos?

Creo que la ventaja real de los Fragmentos es la optimización de la tableta, pero el uso de tabletas en comparación con el uso de dispositivos móviles es muy pequeño en este momento. Además de que las tabletas no son tan "móvil", entonces los dispositivos móviles y no están en foco de contexto de desarrollo cuenta ...