android - loaders - getloadermanager() deprecated

¿Cuál es el alcance de un LoaderManager?

Question

Al identificar los cargadores en su LoaderManager, utiliza identificadores únicos. Estoy preguntando qué tan únicas deben ser esas identificaciones.

¿Cada actividad y fragmento tiene su propio LoaderManager? ¿Los fragmentos usan el LoaderManager de la actividad a la que están vinculados? ¿Hay solo un LoaderManager que posee la aplicación?

Puntos de bonificación si puedes decirme cómo es posible cambiar qué LoaderManager estás usando. Si quiero que todos los fragmentos de mi Actividad utilicen el mismo LoaderManager (algunos de ellos están obteniendo los mismos datos y compartir los Cargadores estaría bien), ¿es posible?

Answer 1

Sí. Funciono para mi Tengo 3 fragmentos diferentes en un cajón de navegación donde los mismos datos se rellenan en diferentes ListViews. (Todos los fragmentos son parte de la MISMA actividad).

Mi AsyncTaskLoader:

public class MyTaskLoader extends AsyncTaskLoader<HashMap<String, Integer>> {
public MyTaskLoader(Context context) {
super(context);
}
@Override
public HashMap<String, Integer> loadInBackground() {
...
return hashMap;
}
...
}

Use la misma ID del cargador en todos los fragmentos.

Fragmento 1:

public class Fragment1 extends BaseFragment implements LoaderManager.LoaderCallbacks<HashMap<String, Integer>> {
@Override
public void onCreate(Bundle savedInstanceState) {
//initialize adapter
getActivity().getSupportLoaderManager().initLoader(0, null, this);
}
@Override
public Loader<HashMap<String, Integer>> onCreateLoader(int arg0, Bundle arg1) {
// TODO Auto-generated method stub
return new MyTaskLoader(getActivity());
}
@Override
public void onLoadFinished(Loader<HashMap<String, Integer>> arg0,
HashMap<String, Integer> data) {
// TODO Auto-generated method stub
listAdapter.setData(data.keySet());
}
@Override
public void onLoaderReset(Loader<HashMap<String, Integer>> arg0) {
// TODO Auto-generated method stub
listAdapter.setData(null);
}
}

Utilice la misma ID para Fragment2:

public class Fragment2 extends BaseFragment implements LoaderManager.LoaderCallbacks<HashMap<String, Integer>> {
@Override
public void onCreate(Bundle savedInstanceState) {
//initialize adapter
getActivity().getSupportLoaderManager().initLoader(0, null, this);
}
@Override
public Loader<HashMap<String, Integer>> onCreateLoader(int arg0, Bundle arg1) {
// TODO Auto-generated method stub
return new MyTaskLoader(getActivity());
}
@Override
public void onLoadFinished(Loader<HashMap<String, Integer>> arg0,
HashMap<String, Integer> data) {
// TODO Auto-generated method stub
listAdapter.setData(data.keySet());
}
@Override
public void onLoaderReset(Loader<HashMap<String, Integer>> arg0) {
// TODO Auto-generated method stub
listAdapter.setData(null);
}
}

El adaptador debe inicializarse antes de inicializar el cargador. Funciona hasta ahora. Pero, ¿es este el camino correcto? ¿Existe un método mejor para usar un cargador común para varios fragmentos?

Answer 2

Actualmente estoy portando mi aplicación al paquete de compatibilidad de Android (principalmente para CursorLoader y Fragmentos). Actualmente estoy intentando compartir un CursorLoader entre dos fragmentos para guardar una consulta en mi ContentProvider. ¡Bienvenido a mi mundo! ;)

Un caso de uso simple:

- DummyActivity extiende FragmentActivity / Log.d (Constants.LOGTAG, "DummyActivity.onCreate" + getSupportLoaderManager (). ToString ());

- DataFragment extiende Fragment implementa LoaderManager.LoaderCallbacks / Log.d (Constantes.LOGTAG, "DataFragment.onCreate" + getLoaderManager (). ToString ());

- ReportFragment extiende Fragment implementa LoaderManager.LoaderCallbacks / Log.d (Constants.LOGTAG, "ReportFragment.onCreate" + getLoaderManager (). ToString ());

DummyActivity crea una instancia del DataFragment y la instancia posterior crea el ReportFragment. La salida logcat muestra diferentes direcciones para cada LoaderManager. Como primera conclusión, cada fragmento parece tener un LoaderManager adecuado ...

Continuaré y actualizaré si puedo responder a su pregunta (nuestra;)). Si ha realizado algún progreso, comparta sus valiosos conocimientos.

Actualizar:

Supongo que los identificadores del cargador solo están asociados con el alcance local de un LoaderManager para un fragmento específico para permitir que varios cargadores locales se asocien con el fragmento (de modo que puede devolver un cargador diferente en onCreateLoader según el id int arg y el llamadas a initLoader).

Hasta ahora he logrado "reutilizar" un cargador (... o no):

- Primero, he habilitado la depuración de getSupportLoaderManager().enableDebugLogging(true); con getSupportLoaderManager().enableDebugLogging(true); en el método onCreate de onCreate .

- Luego llamé a getActivity().getSupportLoaderManager().initLoader(78, null, this); desde los métodos onCreate tanto de DataFragment como de ReportFragment.

- DataFragment expone el CursorLoader creado por el método onCreateLoader través de un configurador en un miembro privado de mCursorLoader.

- ReportFragment onCreateLoader devuelve el DataFragment CursorLoader (después de recuperar el Fragmento con findFragmentByTag ).

La salida de logcat filtrada (y ligeramente ofuscada):

 DummyApp D DummyActivity.onCreate
DummyApp D DataFragment.newInstance
DummyApp D ReportFragment.newInstance
DummyApp D DataFragment.onCreate
LoaderManager V initLoader in LoaderManager{405a19d0 in SpecificAction{4059ee98}}: args=null
DummyApp D DataFragment.onCreateLoader
LoaderManager V Created new loader LoaderInfo{405a2298 #78 : CursorLoader{405a22e0}}
DummyApp D DataFragment.onCreate
DummyApp D DataFragment.onActivityCreated
DummyApp D ReportFragment.onCreate
LoaderManager V initLoader in LoaderManager{405a19d0 in DummyActivity{4059ee98}}: args=null
LoaderManager V Re-using existing loader LoaderInfo{405a2298 #78 : CursorLoader{405a22e0}}
DummyApp D SpecificActionReportFragment.onCreate
DummyApp D SpecificActionReportFragment.onActivityCreated
LoaderManager V Starting in LoaderManager{405a19d0 in DummyActivity{4059ee98}}
LoaderManager V Starting: LoaderInfo{405a2298 #78 : CursorLoader{405a22e0}}
DummyProvider D query called
DummyProvider D […]
DummyProvider D [end of query]
LoaderManager V onLoadComplete: LoaderInfo{405a2298 #78 : CursorLoader{405a22e0}}
LoaderManager V onLoadFinished in CursorLoader{405a22e0 id=78}: CursorWrapperInner{405afb20}
DummyApp D ReportFragment.onLoadFinished
DummyApp D ReportFragment.displayActionReport
DummyApp D DummyActivity.setReportViewsVisibility
DummyApp D ReportFragment.setSaveReportImageViewVisibility

Los dos fragmentos se agregan del método DummyActivity onCreate (diferente del caso de uso descrito, pero eso no cambia nada al problema en el que estamos trabajando). Desafortunadamente, el cargador se reasigna al último fragmento que lo llama (aquí, ReportFragment) ... y nunca se llama a DataFragment.onLoadFinished. Como consecuencia, ReportFragment se ve bien, pero DataFragment no está actualizado ya que la actualización se llama desde el onLoadFinished de esta clase.

Supongo que hay una llamada de desregistro subyacente y luego una llamada de registro en el CursorLoader.

Continuará…