2012-03-24 13 views
19

Estoy tratando de aprender Fragmentos en Android y de varios ejemplos he encontrado que parece haber diferentes formas de hacerlo y solo quería obtener algunos consejos sobre cuál es la forma correcta, o al menos bajo qué circunstancias de una manera debería usarse sobre otro.Fragmentos Android ¿Debería volver a utilizar 1 fragmento o crear nuevas instancias?

Un ejemplo creó un diseño que contenía un fragmento y un FrameLayout. En el código, cuando se selecciona un elemento de ListFragment, se crea un nuevo Fragment (con algunos datos que se requieren en el constructor) y FrameLayout se reemplaza con este nuevo Fragment (usando FragmentTransaction.replace()).

Otro ejemplo tiene un archivo de diseño que declara los 2 fragmentos uno al lado del otro. Ahora, en el código, cuando el usuario selecciona un elemento de la lista en un fragmento, se realiza una llamada al otro fragmento para actualizar los datos (en función del elemento seleccionado).

Así que me pregunto si se prefiere alguno de estos métodos sobre el otro o si hay ciertas circunstancias en las que se debe utilizar uno.

EDIT: aquí está el código para cada uno de los dos métodos que me refería:

1:

 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); 
     } 

2:

public void onListItemClick(ListView l, View v, int position, long id) { 
    String item = (String) getListAdapter().getItem(position); 
    DetailFragment fragment = (DetailFragment) getFragmentManager() 
      .findFragmentById(R.id.detailFragment); 
    if (fragment != null && fragment.isInLayout()) { 
     fragment.setText(item); 
    } else { 
     Intent intent = new Intent(getActivity().getApplicationContext(), 
       DetailActivity.class); 
     intent.putExtra("value", item); 
     startActivity(intent); 

    } 

} 

Respuesta

20

Así que estoy preguntando si se prefiere alguno de estos métodos sobre el otro o si hay ciertas circunstancias en las que se debe usar uno?

Si el fragmento real no tiene que cambiar (es decir, es la misma clase fragmento), me gustaría tener la actividad llamar a un método en el que el fragmento en lugar de reemplazarla (el escenario 2 #), suponiendo que existe Eso es mucho menos costoso en tiempo de ejecución, y probablemente también sea más simple codificar.

Si, sin embargo, el fragmento puede ser que necesite ser uno diferente (por ejemplo, dependiendo de lo que se hace clic, puede haber diferentes fragmentos de diferentes tipos de objetos de modelos representados en la lista), luego de reemplazo será necesario el fragmento (su escenario # 1). Puede optimizar el caso donde el fragmento pasa para este evento para ser de la misma clase, aunque me centraría primero en hacerlo funcionar simplemente reemplazando el fragmento y me preocuparía la optimización si/cuando tiene el tiempo y la inclinación .

Aunque no soy fanático de su código n. ° 2 estructuralmente. En mi humilde opinión, los fragmentos no deberían estar hablando con otros fragmentos directamente. Mi patrón preferido es que los fragmentos "se adhieran a sus tejidos", centrándose únicamente en las cosas dentro de sus propios widgets y modelos. Para los eventos que afectan a otras partes de la IU (por ejemplo, clic de lista), haga que el fragmento notifique la actividad (por ejemplo, a través de una interfaz de escucha). La actividad es la que sabe qué fragmentos deberían estar presentes, ya que es el que los creó en primer lugar. La actividad puede entonces hablar con el otro fragmento (si existe), crear el otro fragmento (si hay espacio) o iniciar otra actividad. Si prefiere su enfoque # 2, puede usarlo, no es lo que haría en su circunstancia.

Cuestiones relacionadas