LoaderCallbacks jako statyczna klasa wewnętrzna (w celu obsługi wielu programów ładujących z różnymi typami danych zwróconych)

Question

Mam działanie, które używa dwóch programów ładujących. Każdy z nich zwraca inny typ danych. Aby pobrać dane z jednego programu ładującego, wystarczy wdrożyć LoaderCallbacks<D> w działaniu. Chyba mógłbym zaimplementować LoaderCallbacks<Object> i sprawdzić typ obiektu, a następnie zdecydować, który z dwóch LoaderCallbacks jest, ale wydaje mi się, że to hack (głównie ze względu na brak bezpieczeństwa typu tutaj).

Więc pomyślałem o zrobieniu LoaderCallbacks obiekt statyczny klasę wewnętrzną, coś takiego:

private static class geocoderLoaderCallbacks implements LoaderCallbacks<List<Address>>{ 

    @Override 
    public Loader<List<Address>> onCreateLoader(int arg0, Bundle arg1) { 
     GeocoderTask loader = new GeocoderTask(context, ""); 
     return loader; 
    } 

    @Override 
    public void onLoadFinished(Loader<List<Address>> loader, List<Address> data) { 
     // TODO Auto-generated method stub 

    } 

    @Override 
    public void onLoaderReset(Loader<List<Address>> loader) { 
     // TODO Auto-generated method stub 

    } 


} 

a następnie za lm.initLoader(0, null, geocoderLoaderCallbacks).

Powstaje dwa pytanie: czy można to zrobić, czy raczej powinienem trzymać się realizacji funkcji LoaderCallbacks w działaniu? I w jaki sposób bezpiecznie przekazać kontekst do onCreateLoader? Czy powinienem po prostu stworzyć konstruktora w geocoderLoaderCallbacks i przekazać kontekst tak jak ten lm.initLoader(0, null, geocoderLoaderCallbacks(this))?

Jest podobne pytanie tutaj LoaderManager with multiple loaders: how to get the right cursorloader, ale nie wyjaśnia ono sposobu zarządzania dwoma ładowarkami o różnych typach danych.

Answer 1

Zawsze jest dobrze, aby przenieść kod z potencjalnie gigantycznej klasy i jest o wiele czystszy, aby zrobić to z różnymi klasami, niż z tymi, które mogą obsłużyć wszystko. Możesz nawet chcieć uczynić je prawdziwymi klasami zewnętrznymi zamiast klasami wewnętrznymi, jeśli uważasz, że Twoja Aktywność ma za dużo kodu wewnątrz. LoaderCallbacks to interfejs, dzięki któremu można go w większości wdrożyć w swojej klasie.

Przekazywanie Context w konstruktorze jest w porządku, o ile nie zachowujesz statycznych lub w inny sposób zapisanych w pamięci podręcznej odwołań do niego.