Okej, dzięki za odpowiedź. Ale jezeli jest to aplikacja składająca się z jednej aktywności i np. 5 fragmentów to czy mogę tak zrobić? Jak opisałem, w aplikacji występuje jedna aktywność, a w niej kilka fragmentów.
Możesz tak zrobić nawet w aplikacji, która ma setki widoków. Pytanie czy chcesz pisać aplikację, którą da się rozwijać i utrzymać czy nie. Zapytałeś czy to jest poprawne. No to odpowiedź jest taka, że to nie jest poprawne. Ja bym tak nie zrobił nawet jakby to była aplikacja składająca się z 2 fragmentów. Dla małej aplikacji bez warstw prezentacji stworzyłbym jakąś klasę, która byłaby odpowiedzialna za przechowywanie danych, utworzył jej jedną instancję poza cyklem życia i przekazywał tam gdzie trzeba. Na przykład w ten sposób.
public final class MyApplication extends Application {
private MyDataStorage myDataStorage;
@Override public void onCreate() {
super.onCreate();
myDataStorage = new MyDataStorage(this);
}
public static MyDataStorage myDataStorage(Context context) {
return ((MyApplication) context.getApplicationContext()).myDataStorage;
}
}
Założyłem, że MyDataStorage
potrzebuje kontekstu do utworzenia dlatego nie jest polem finalnym i jest tworzone w onCreate
. Jeżeli nie byłoby takiej potrzeby, to najlepiej zrobić z tego pole finalne. Potem mógłbyś się dostać do MyDataStorage
z każdej aktywności i z każdego fragmentu. Byłoby to bardzo ubogie rozwiązanie, ale dla małych aplikacji wystarczające. Zwłaszcza takich, gdzie nie tworzy się warstwy prezentacji. W tym rozwiązaniu pojawia się problem związany ze śmiercią aplikacji, ale nie da się go uniknąć, jeżeli nie zapisujemy niczego na trwałe na urządzeniu.