Jak ustawić i uzyskać obiekt Singleton klasy modelu za pomocą narzędzia dagger2?

Question

Jakie mam opcje utworzenia pojedynczej instancji wszystkich klas modeli w aplikacji na Androida?

dodałem poniżej jednej próbki klasach modelowych

public class User 
{ 
    private String email; 
    private String name; 
    public String getEmail()   { return this.email; } 
    public void setEmail(String email) { this.email = email; } 
    public String getName()   { return this.name; } 
    public void setName(String name) { this.name = name; } 
} 

Chcę że kiedyś dane są przechowywane w klasie modelu, może być pobrana w jakiejkolwiek działalności, klasy lub fragmentu. Czy powinienem użyć singletonu, czy jest dostępne jakieś lepsze podejście?

Czy sztylet2 działa w tym scenariuszu? Czy sztylet2 jest alternatywą do tworzenia singletonu?

Dzięki

Answer 1

============ Pytanie 1 - Jakie mam opcje ... ===============

Istnieje wiele pułapek na używanie Singletonów w systemie Android. Największym z nich jest to, że Android zarządza cyklem życia aplikacji. Tak więc każda działalność może zostać zniszczona w dowolnym momencie. Lub Android może nawet zabić twój proces, jeśli pamięć jest potrzebna do innych celów. Android przywróci twoją aplikację/aktywność, ale jeśli nic nie zrobisz, stan zostanie utracony. W scenariuszu kill procesu masz nową instancję maszyny wirtualnej i utracono dowolny stan obiektów Singleton. Oczywiście, jeśli kodujesz ostrożnie, możesz upewnić się, że są one odpowiednio odtworzone z prawidłowym stanem. Może to być trudne i podatne na błędy.

Jeśli potrzebujesz tych klas modeli dostępnych od jakiejkolwiek aktywności w aplikacji, istnieje kilka nieco lepiej podejść można podjąć:

Wariant 1.

ja. Przekaż obiekty z działania do aktywności, używając Intents. Rozwiązuje to problem "globalnie dostępny". Będzie to również wymagało utworzenia klas modelu Parcelable lub serializacji. ii. Użyj metody onSaveInstanceState, aby zapisać stan obiektów w swojej aktywności. Przywróć stan w metodzie onCreate. Ten proces jest opisany here.

To, co może być niezręczne w tym podejściu, to dodatkowy i dodatkowy kod wymagany do tego, aby zawsze zapisywać i odczytywać zamiar przy każdej zmianie aktywności.

Wariant 2

Rozważ swoje singletons utrzymują ich dane dotyczące każdego zapisu i odczytu z uporem na każdym odczycie. Masz do dyspozycji wiele mechanizmów trwałości, w tym: SharedPreferences, Basic File I/O i SQL Database. Te opcje są omówione tutaj: http://developer.android.com/guide/topics/data/data-storage.html. Jeśli wybierzesz tę trasę, osobiście odkryłem, że program SharedPreferences jest najłatwiejszy w obsłudze.

Oto przykład, jak może to być zrobione

public class User { 

    //--------------------- 
    // Singleton implementation. Note this is just one of several styles 
    // of this pattern. 
    private static User instance = new User(); 
    private User() {} // prevent instantiation 
    public User getUserInstance() { return instance; } 
    //--------------------- 

    private String category = "user_bean_settings"; 
    private String emailKey = "email"; 
    private String nameKey = "name"; 

    public String getEmail() { 
     return readStringProperty(emailKey); 
    } 
    public void setEmail(String email) { 
     writeStringProperty(emailKey, email); 
    } 
    public String getName() { 
     return readStringProperty(nameKey); 
    } 
    public void setName(String name) { 
     writeStringProperty(nameKey, name); 
    } 

    private String readStringProperty(String prop) { 
     Context context = getApplicationContext(); 
     SharedPreferences prefs = context.getSharedPreferences(category, Context.MODE_PRIVATE); 
     return prefs.getString(prop, null); 
    } 

    private void writeStringProperty(String prop, String value) { 
     Context context = getApplicationContext(); 
     SharedPreferences prefs = context.getSharedPreferences(category, Context.MODE_PRIVATE); 
     SharedPreferences.Editor editor = prefs.edit(); 
     editor.putString(prop, value); 
     editor.commit(); 
    } 
} 

Ten niezgrabny częścią tego jest to, że trzeba będzie mieć odniesienie kontekstowe poręczny, aby uzyskać dostęp SharedPreferences. Jak najlepiej to zrobić, to twój telefon. Pamiętaj, że same Działania są Kontekstami, więc zawsze możesz je przekazać. Istnieje wiele różnych sposobów radzenia sobie z tym.

======= Pytanie 2 - Czy dagger2 alternatywą dla tworzenia pojedyncza ... ==========

Spojrzałem na Dagger 2 i zobaczyć, że? jest to schemat wtrysku zależności. Istnieje wiele korzyści z korzystania z frameworka DI (luźne sprzężenie, testowalność, ...). Możesz użyć Daggera (lub innej struktury DI, takiej jak RoboGuice) do zarządzania swoimi singletonami. Jeśli to jest twój cel, ja osobiście nie sądzę, że jest wart dodatkowego wysiłku integracji. Jeśli jednak chcesz czerpać przyjemność z innych wymienionych wyżej korzyści, to może być warta twojego czasu. Należy pamiętać, że te nie są dostarczane za darmo, nadal trzeba przestrzegać dobrych praktyk kodowania. Anways, wydaje się, że wykracza to nieco poza zakres pytania.

Answer 2

A bound service byłby dobrym rozwiązaniem. Klient powiązałby go z kontekstem aplikacji, aby to samo wystąpienie było dostępne przez "dowolną aktywność, klasę lub fragment".

To rozwiązanie pozwoli uniknąć narzutów na konieczność serializowania do/z intencji. Pozwoli to również uniknąć napięć trwałych, jeśli ich nie potrzebujesz.