Come ottenere il contesto in Android MVVM ViewModel

Sto cercando di implementare il pattern MVVM nella mia app Android. Ho letto che ViewModels non dovrebbe contenere codice specifico per Android (per semplificare i test), tuttavia ho bisogno di usare il contesto per varie cose (ottenere risorse da xml, inizializzare le preferenze, ecc.). Qual è il modo migliore per farlo? Ho visto che AndroidViewModelha un riferimento al contesto dell'applicazione, tuttavia contiene codice specifico di Android, quindi non sono sicuro che dovrebbe essere nel ViewModel. Anche quelli si collegano agli eventi del ciclo di vita dell'attività, ma sto usando il pugnale per gestire l'ambito dei componenti, quindi non sono sicuro di come ciò lo influenzerebbe. Sono nuovo nel pattern MVVM e nel Dagger, quindi qualsiasi aiuto è apprezzato!

Puoi usare un Applicationcontesto fornito da AndroidViewModel, dovresti estendere AndroidViewModelche è semplicemente un ViewModelche include un Applicationriferimento.

Per il modello di visualizzazione dei componenti dell'architettura Android,

Non è una buona pratica passare il contesto dell'attività al ViewModel dell'attività poiché è una perdita di memoria.

Quindi, per ottenere il contesto nel tuo ViewModel, la classe ViewModel dovrebbe estendere la classe del modello di visualizzazione Android . In questo modo puoi ottenere il contesto come mostrato nel codice di esempio qui sotto.

class ActivityViewModel(application: Application) : AndroidViewModel(application) {

    private val context = getApplication<Application>().applicationContext

    //... ViewModel methods 

}

Non è che ViewModels non debba contenere codice specifico per Android per rendere i test più facili, poiché è l'astrazione che rende i test più facili.

Il motivo per cui ViewModels non dovrebbe contenere un'istanza di Context o qualcosa di simile a Views o altri oggetti che trattengono un Context è perché ha un ciclo di vita separato rispetto a Activities e Fragments.

Ciò che intendo con questo è, diciamo che fai un cambio di rotazione sulla tua app. Questo fa sì che la tua attività e il tuo frammento si autodistruggano in modo da ricrearsi. ViewModel è pensato per persistere durante questo stato, quindi ci sono possibilità che si verifichino arresti anomali e altre eccezioni se sta ancora mantenendo una vista o un contesto per l'attività distrutta.

Per quanto riguarda il modo in cui dovresti fare quello che vuoi fare, MVVM e ViewModel funzionano molto bene con il componente Databinding di JetPack. Per la maggior parte delle cose per cui in genere si memorizza una stringa, un int o così via, è possibile utilizzare Databinding per fare in modo che le viste lo visualizzino direttamente, quindi non è necessario memorizzare il valore all'interno di ViewModel.

Ma se non si desidera l'associazione dati, è comunque possibile passare il contesto all'interno del costruttore o dei metodi per accedere alle risorse. Basta non tenere un'istanza di quel contesto all'interno del tuo ViewModel.

Risposta breve: non farlo

Perché ?

Sconfigge l'intero scopo dei modelli di visualizzazione

Quasi tutto ciò che puoi fare nel modello di visualizzazione può essere fatto in attività / frammento utilizzando istanze di LiveData e vari altri approcci consigliati.

Quello che ho finito per fare invece di avere un contesto direttamente nel ViewModel, ho creato classi provider come ResourceProvider che mi avrebbero dato le risorse di cui avevo bisogno e ho inserito quelle classi provider nel mio ViewModel

TL; DR: Inietta il contesto dell'applicazione tramite Dagger nei tuoi ViewModels e usalo per caricare le risorse. Se è necessario caricare immagini, passare l'istanza View tramite argomenti dai metodi Databinding e utilizzare tale contesto View.

L'MVVM è una buona architettura ed è sicuramente il futuro dello sviluppo di Android, ma ci sono un paio di cose che sono ancora verdi. Prendiamo ad esempio la comunicazione dei livelli in un'architettura MVVM, ho visto diversi sviluppatori (sviluppatori molto noti) utilizzare LiveData per comunicare i diversi livelli in modi diversi. Alcuni di loro usano LiveData per comunicare ViewModel con l'interfaccia utente, ma poi usano interfacce di callback per comunicare con i repository, oppure hanno Interactors / UseCases e usano LiveData per comunicare con loro. Il punto qui è che non tutto è ancora definito al 100% .

Detto questo, il mio approccio con il tuo problema specifico è avere il contesto di un'applicazione disponibile tramite DI da utilizzare nei miei ViewModels per ottenere cose come String dal mio strings.xml

Se ho a che fare con il caricamento delle immagini, provo a passare attraverso gli oggetti View dai metodi dell'adattatore Databinding e utilizzo il contesto della vista per caricare le immagini. Perché? perché alcune tecnologie (ad esempio Glide) possono incorrere in problemi se utilizzi il contesto dell'applicazione per caricare le immagini.

Spero che sia d'aiuto!

Come altri hanno già detto, c'è da AndroidViewModelcui puoi derivare per ottenere l'app, Contextma da quello che raccolgo nei commenti, stai cercando di manipolare @drawablei messaggi di posta elettronica dall'interno del tuo ViewModelche sconfigge lo scopo MVVM.

In generale, la necessità di avere una Contextnella vostra ViewModelsuggerisce quasi universalmente si dovrebbe considerare ripensare come si divide la logica tra le Views e ViewModels.

Invece di dover ViewModelrisolvere i drawable e fornirli all'attività / frammento, considera che il frammento / attività manipoli i drawables in base ai dati posseduti dal file ViewModel. Supponiamo che tu abbia bisogno di diversi drawable da visualizzare in una vista per lo stato on / off - è lo stato ViewModelche dovrebbe contenere lo stato (probabilmente booleano) ma è Viewcompito di selezionare il drawable di conseguenza.

Può essere fatto abbastanza facilmente con DataBinding :

<ImageView
...
app:src="@{viewModel.isOn ? @drawable/switch_on : @drawable/switch_off}"
/>

Se hai più stati e drawables, per evitare logiche ingombranti nel file di layout puoi scrivere un BindingAdapter personalizzato che traduca, ad esempio, un Enumvalore in R.drawable.*(ad esempio semi di carte)

O forse hai bisogno Contextdi qualche componente che usi all'interno del tuo ViewModel- quindi, crea il componente all'esterno di ViewModele passalo dentro. Puoi usare DI, o singleton, o creare il Contextcomponente -dependent subito prima di inizializzare l' ViewModelin Fragment/ Activity.

Perché preoccuparsi: Contextè una cosa specifica di Android e dipendere da quelli in ViewModels è una cattiva pratica: ostacolano i test unitari. D'altra parte, le interfacce dei tuoi componenti / servizi sono completamente sotto il tuo controllo, quindi puoi facilmente deriderle per i test.

ha un riferimento al contesto dell'applicazione, tuttavia che contiene codice specifico di Android

Buone notizie, puoi usare Mockito.mock(Context.class)e fare in modo che il contesto restituisca quello che vuoi nei test!

Quindi usa ViewModelcome faresti normalmente e dagli ApplicationContext tramite ViewModelProviders.Factory come faresti normalmente.

è possibile accedere al contesto dell'applicazione getApplication().getApplicationContext()dall'interno di ViewModel. Questo è ciò di cui hai bisogno per accedere a risorse, preferenze, ecc.

Non dovresti utilizzare oggetti correlati ad Android nel tuo ViewModel poiché il motivo dell'utilizzo di un ViewModel è separare il codice java e il codice Android in modo da poter testare la tua logica aziendale separatamente e avrai un livello separato di componenti Android e la tua logica aziendale e dati, non dovresti avere contesto nel tuo ViewModel in quanto potrebbe causare arresti anomali

Avevo problemi a ottenere SharedPreferencesquando usavo la ViewModelclasse, quindi ho seguito il consiglio dalle risposte sopra e ho fatto quanto segue usando AndroidViewModel. Tutto sembra fantastico adesso

Per il AndroidViewModel

import android.app.Application;
import android.content.Context;
import android.content.SharedPreferences;

import androidx.lifecycle.AndroidViewModel;
import androidx.lifecycle.LiveData;
import androidx.lifecycle.MutableLiveData;
import androidx.preference.PreferenceManager;

public class HomeViewModel extends AndroidViewModel {

    private MutableLiveData<String> some_string;

    public HomeViewModel(Application application) {
        super(application);
        some_string = new MutableLiveData<>();
        Context context = getApplication().getApplicationContext();
        SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(context);
        some_string.setValue("<your value here>"));
    }

}

E nel Fragment

import android.os.Bundle;
import android.util.Log;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.TextView;

import androidx.annotation.NonNull;
import androidx.annotation.Nullable;
import androidx.fragment.app.Fragment;
import androidx.lifecycle.Observer;
import androidx.lifecycle.ViewModelProviders;


public class HomeFragment extends Fragment {


    public View onCreateView(@NonNull LayoutInflater inflater,
                             ViewGroup container, Bundle savedInstanceState) {
        final View root = inflater.inflate(R.layout.fragment_home, container, false);
        HomeViewModel homeViewModel = ViewModelProviders.of(this).get(HomeViewModel.class);
        homeViewModel.getAddress().observe(getViewLifecycleOwner(), new Observer<String>() {
            @Override
            public void onChanged(@Nullable String address) {


            }
        });
        return root;
    }
}

L'ho creato in questo modo:

@Module
public class ContextModule {

    @Singleton
    @Provides
    @Named("AppContext")
    public Context provideContext(Application application) {
        return application.getApplicationContext();
    }
}

E poi ho appena aggiunto in AppComponent il ContextModule.class:

@Component(
       modules = {
                ...
               ContextModule.class
       }
)
public interface AppComponent extends AndroidInjector<BaseApplication> {
.....
}

E poi ho inserito il contesto nel mio ViewModel:

@Inject
@Named("AppContext")
Context context;

Usa lo schema seguente:

class NameViewModel(
val variable:Class,application: Application):AndroidViewModel(application){
   body...
}

Il problema con l'inserimento di un contesto nel ViewModel è che il contesto può cambiare in qualsiasi momento, a seconda della rotazione dello schermo, della modalità notturna o della lingua del sistema e qualsiasi risorsa restituita può cambiare di conseguenza. La restituzione di un semplice ID risorsa causa problemi per parametri aggiuntivi, come le sostituzioni getString. Restituire un risultato di alto livello e spostare la logica di rendering nell'attività rende più difficile il test.

La mia soluzione è fare in modo che ViewModel generi e restituisca una funzione che viene successivamente eseguita attraverso il contesto dell'attività. Lo zucchero sintattico di Kotlin lo rende incredibilmente facile!

ViewModel.kt:

// connectedStatus holds a function that calls Context methods
// `this` can be elided
val connectedStatus = MutableLiveData<Context.() -> String> {
  // initial value
  this.getString(R.string.connectionStatusWaiting)
}
connectedStatus.postValue {
  this.getString(R.string.connectionStatusConnected, brand)
}

Activity.kt  // is a Context

override fun onCreate(_: Bundle?) {
  connectionViewModel.connectedStatus.observe(this) { it ->
   // runs the posted value with the given Context receiver
   txtConnectionStatus.text = this.run(it)
  }
}

Ciò consente a ViewModel di contenere tutta la logica per il calcolo delle informazioni visualizzate, verificata da test unitari, con l'attività che è una rappresentazione molto semplice senza logica interna per nascondere i bug.