Context in MVVM in android

Question

I have started working on MVVM architecture for android application.I have a doubt that is it right to pass the context to view model ? If not then how can my view model can access the context if needed.

I am doing the following things:

1. Feed data using some EditText.
2. Send this data to View model.
3. View model send this data to repository
4. Repository storing this data to shared preferences of the device.

As shared preferences required context to instantiate the object.

I am new to this architecture any guidance would be helpful for me, thanks in advance.

Answer 1

You should use AndroidViewModel() in the ViewModel, pass application:Applicatoin, and use getApplication() to get the context.

ViewModel Example:

class MainTrendsViewModel (application: Application) : AndroidViewModel(application) {
    // ViewModel must extend AndroidViewModel(), and pass application to it. 
    // Code here and
    // use getApplication() to get context
}

Other anwer that work for me that you could reference: reference answer that works for me

Answer 2

UPDATE 2019

I don't want to mislead anyone with my old post, so figured I better update it.

With the latest release of the architectural components and JetPack, MVVM is now a real competitor for actual proper structure of breaking apart the code base in a very clean way.

The View is the Activity or Fragment along with the xml that is inflated basically (that's a bit of a weird MVVM, I know, but let's roll with it).

The ViewModel is the actual ViewModel classes offered now with lifecycle scopes and observers. Due to these new features, and life cycle management tools, the ViewModel is very nice at maintaining the data for the view while accessing the Repository Layer of Room DB or Retro API for fetching appropriate LiveData, Observable Data or just standard Models.

I'll leave this here as I feel it was very relevant during the earlier pre Architecture Implementation Days, but if you are not using the Architecture Components and JetPack, Boy are you missing out lol. Code is getting so much cleaner and smaller. :)

OLD REPLY

This is a long debated discussion among the Android community. When we refer to MVC it is obvious that Models (aka data holding objects) are the M, Controllers = C for the Activity classes (in iOS they actually call them UIViewControllers) and the V for the View in Android is the XML file itself. Now some would argue the architectural breakdown of what represents what. However, let's move past this and discuss MVVM.

MVVM has been around for many years now. There have been a few attempts in the past to bring it to Android through 3rd party binding tools, but it ends up more hacky then it is worth.

Recently with the release of native Data Binding Android is finally capable of doing a somewhat clean implementation of MVVM. So there are a couple options here. You can do

M = Models (data holding objects)

V = Views (the XML file itself representing the UI)

VM = This is where debates occur.

Some say in order to be a "true" ViewModel one must have true separation from the Presentation layer and the Activity class itself has lifecycle callbacks thus making it unworthy of being known as the ViewModel.

Others would point out that in order to handle most of the actions triggered from the ViewModel one must have an awareness of onActivityResult, onNewIntent, onBroadcastReceived, onPause or other life cycle handlings to appropriately manage the user experience. So On my team we consider the Activity as the ViewModel. Otherwise you are passing the activity down to a viewmodel and tightly coupling the two anyways, making a giant hideous maintenance nightmare of code.

So you if you want my opinion, stick to treating the Activity as your ViewModel. Get your data to the ViewModel just like any other binding technology like INotifyPropertyChanged in WPF. You do it through your Binding.

I do two things to make this happen. One I have an Activity variable in the XML layout to inject in the onCreate for the binding setup which gives the XML direct binding rights to any observable properties in the viewModel aka the activity. Then I inject whatever variables I need to make use of as well for example you may have a WeatherModel that populates a forecast that lives within the Activity that you would also set in the onCreate to allow the XML access to both it's ViewModel (aka activity) and it's viewModel's Objects.

The other alternative is to make a ViewModel object and inject it in the XML in the onCreate of your Activity and then continue to call back and forth from the activity to the viewmodel for handling actions and lifecycles and feel free to manage that nightmare haha, I did an entire project this way and by the end of it, I redid it all to avoid all the duplication of coding efforts and hideous back and forths.

Goodluck and I hope that helps.

Answer 3

I use MVVM in my application. I always try not to use Context inside my View Model. I also encountered the problem with SharedPreferences requiring a context to access the preference files. One of my solutions without using Dagger is to create a Preference utility class that will have reference to the application context. You initialize this utility class in you Application class. You get reference to the shared preference through a public static method provided by the utility class. You can directly call the utility class from your repository class. I prefer to contain all logic related to data storage in the repository class that's why i call the sharedpreference utility class in my repository class.

PreferenceManager.java

public class PreferenceManager {
private static SharedPreferences mSharedpreferences;
private PreferenceManager() {}
public static void initialize(Context context) {
    mSharedpreferences= context.getSharedPreferences(context.getPackageName(), 
    Context.MODE_PRIVATE);
}
public static SharedPreferences getSharedPreferences() {
    return mSharedpreferences;
}
}

App.java

public class App extends Application {
@Override
public void onCreate() {
    PreferenceManager.initialize(this);
}
}

Repository.java

public class Repository {
public void someMethod() {
    PreferenceManager.getSharedPreferences.edit.putBoolean("sample", true).apply();
}

Answer 4

Look into Dagger 2!

That's true , you definitively shouldn't pass Activity to your xml or ViewModel. It will make your ViewModel no better than these 2000-line activities that we are trying to move away from with this architecture. The solution we have in our MVVM project is to inject SharedPreferences with Dagger. You can of corse use ApplicationContext as well but do you need multiple instances of SharedPreferences in the project??

We a have a utility class for SharedPreferences and it is nice to keep it a singleton and inject wherever you need it.

Answer 5

I think the use of ApplicationContext is ok, You can extend your ViewModel from AndroidViewModel and whenever you need a reference to the context use getApplication() methods.

Even better, if your using dagger, you don't need this at all, you just inject your ApplicationContext where ever you need it. It can be in your view model or a utility class that handles shared preference, etc.

Answer 6

A very good question, and it is not as simple as it seems! You can see an example from Google team here.

They solved the problem with the help of the factory. There it is pass (of course) the Application context (not Activity context !).

A small problem - and so much boilerplate code!

My decision:

public class MainApplication extends Application {
public void onCreate() {
AppSharedPref sharedPref = AppSharedPref.getInstance(PreferenceManager.getDefaultSharedPreferences(this));
AppRepository.getInstance(sharedPref);

Repository is singltone (a lot of code is skipped for brevity):

public class AppRepository implements AppDataSource {
public static AppRepository getInstance(@NonNull AppSharedPref sharedPref) {
if (INSTANCE == null) {
   INSTANCE = new AppRepository(sharedPref);
}
return INSTANCE;
}

In ViewModel call:

public class MyViewModel extends AndroidViewModel {

// constructor
public MyViewModel(@NonNull Application application) {
   repository = AppRepository.getInstance(.....);
}

Answer 7

You should use AndroidViewModel class or keep reference to Application context in yours ViewModel implementation in this case. ViewModel class was designed to keep data persistent between different instances of Activity through its lifecircle and storing reference to one of Activity instance context really doesn't make sense.