Как получить контекст в Android MVVM ViewModel

вы можете получить доступ к контексту приложения из getApplication().getApplicationContext() из ViewModel. Это то, что вам нужно для доступа к ресурсам, настройкам и т. д.

Дело не в том, что модели ViewModels не должны содержать специфический для Android код, чтобы упростить тестирование, поскольку это абстракция, которая упрощает тестирование.

Причина, по которой модели представления не должны содержать экземпляр контекста или что-то вроде представлений или других объектов, которые хранятся в контексте, заключается в том, что у него отдельный жизненный цикл, чем у действий и фрагментов.

Я имею в виду, что вы меняете ротацию в своем приложении. Это приводит к тому, что ваша активность и фрагмент разрушаются, поэтому они воссоздают себя. ViewModel предназначен для сохранения в этом состоянии, поэтому есть вероятность сбоев и других исключений, если он все еще удерживает View или Context для уничтоженной Activity.

Что касается того, как вы должны делать то, что хотите делать, MVVM и ViewModel действительно хорошо работают с компонентом привязки данных JetPack. Для большинства вещей, для которых вы обычно храните String, int и т. д., Вы можете использовать привязку данных, чтобы представления отображали ее напрямую, поэтому не нужно хранить значение внутри ViewModel.

Но если вам не нужна привязка данных, вы все равно можете передать контекст внутри конструктора или методов для доступа к ресурсам. Просто не храните экземпляр этого контекста внутри своей модели просмотра.

TL; DR: вставьте контекст приложения через Dagger в ваши модели просмотра и используйте его для загрузки ресурсов. Если вам нужно загрузить изображения, передайте экземпляр View через аргументы из методов привязки данных и используйте этот контекст View.

MVVM - хорошая архитектура, и это определенно будущее Android-разработки, но есть пара вещей, которые все еще остаются зелеными. Возьмем, к примеру, обмен данными между уровнями в архитектуре MVVM. Я видел, как разные разработчики (очень известные разработчики) использовали LiveData для связи различных уровней по-разному. Некоторые из них используют LiveData для связи ViewModel с пользовательским интерфейсом, но затем они используют интерфейсы обратного вызова для связи с репозиториями, или у них есть Interactors / UseCases, и они используют LiveData для связи с ними. Дело здесь в том, что не все на 100% определяют еще.

При этом мой подход к вашей конкретной проблеме заключается в наличии контекста приложения, доступного через DI для использования в моих ViewModels, чтобы получить такие вещи, как String из моего strings.xml

Если я имею дело с загрузкой изображений, я пытаюсь передать объекты View из методов адаптера привязки данных и использовать контекст View для загрузки изображений. Почему? потому что некоторые технологии (например, Glide) могут столкнуться с проблемами, если вы используете контекст приложения для загрузки изображений.

Надеюсь, поможет!

Вы не должны использовать объекты, связанные с Android, в своей ViewModel, поскольку мотивом использования ViewModel является разделение кода Java и кода Android, чтобы вы могли тестировать свою бизнес-логику отдельно, и у вас будет отдельный уровень компонентов Android и бизнес-логика. и данные, у вас не должно быть контекста в вашей ViewModel, так как это может привести к сбоям

has a reference to the application context, however that contains android specific code

Хорошие новости, вы можете использовать Mockito.mock(Context.class) и заставить контекст возвращать все, что вы хотите, в тестах!

Поэтому просто используйте ViewModel, как обычно, и дайте ему ApplicationContext через ViewModelProviders.Factory, как обычно.

То, что я в итоге сделал, вместо того, чтобы иметь контекст непосредственно в ViewModel, я создал классы провайдеров, такие как ResourceProvider, которые предоставили бы мне необходимые ресурсы, и эти классы провайдеров были введены в мою ViewModel.

Вы можете использовать контекст Application, который предоставляется AndroidViewModel, вы должны расширить AndroidViewModel, который является просто ViewModel, который включает ссылку на Application.

Для модели представления компонентов архитектуры Android,

Не рекомендуется передавать контекст действия в ViewModel действия, поскольку это утечка памяти.

Следовательно, чтобы получить контекст в вашей ViewModel, класс ViewModel должен расширять класс Модель просмотра Android. Таким образом вы можете получить контекст, как показано в примере кода ниже.

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

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

    //... ViewModel methods 

}

Как уже упоминали другие, есть AndroidViewModel, от которого вы можете получить приложение Context, но из того, что я собираю в комментариях, вы пытаетесь манипулировать @drawable из своего ViewModel, что побеждает цель MVVM.

В общем, необходимость иметь Context в вашем ViewModel почти всегда предполагает, что вам следует подумать о переосмыслении того, как вы разделяете логику между вашими View и ViewModels.

Вместо того, чтобы ViewModel разрешал чертежи и передавал их Activity / Fragment, подумайте о том, чтобы Fragment / Activity манипулировал чертежами на основе данных, которыми обладает ViewModel. Скажем, вам нужны разные чертежи, которые будут отображаться в представлении для состояния включения / выключения - это ViewModel, который должен удерживать (возможно, логическое) состояние, но задача View - выбрать соответствующий чертеж.

DataBinding делает это довольно просто:

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

Если у вас есть больше состояний и чертежей, чтобы избежать громоздкой логики в файле макета, вы можете написать собственный BindingAdapter, который переводит, скажем, значение Enum в ссылку R.drawable.*, например:

enum class CatType { NYAN, GRUMPY, LOL }

class CatViewModel {
    val catType: LiveData<CatType> = ...

// View-tier logic, takes the burden of knowing
// Contexts and R.** refs from the ViewModel
@BindingAdapter("bindCatImage")
fun bindCatImage(view: ImageView, catType: CatType) = view.apply {
    val resource = when (value) {
        CatType.NYAN -> R.drawable.cat_nyan
        CatType.GRUMPY -> R.drawable.cat_grumpy
        CatType.LOL -> R.drawable.cat_lol
    }
    setImageResource(resource)
}

<ImageView
    bindCatType = "@{vm.catType}"
    ... />

Если вам нужен Context для некоторого компонент, который вы используете в вашего ViewModel - тогда создайте компонент вне ViewModel и передайте его. Вы можете использовать DI или синглтоны, или создать зависимый от Context компонент прямо перед инициализацией ViewModel в Fragment / Activity.

Зачем беспокоиться

Context - это специфическая вещь для Android, и в зависимости от нее в ViewModels он громоздок для модульных тестов (конечно, вы можете использовать AndroidJunitRunner для специфичных для Android вещей, но имеет смысл иметь более чистый код без дополнительной зависимости). Если вы не зависите от Context, имитировать все для теста ViewModel проще. Итак, практическое правило: не используйте Context во ViewModels, если у вас нет для этого веской причины.

Краткий ответ - не делайте этого

Почему ?

Это сводит на нет всю цель просмотра моделей

Практически все, что вы можете сделать в модели представления, можно сделать в действии / фрагменте, используя экземпляры LiveData и различные другие рекомендуемые подходы.

Я создал это так:

@Module
public class ContextModule {

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

А затем я просто добавил в AppComponent ContextModule.class:

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

А затем я ввел контекст в свою ViewModel:

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

Используйте следующий шаблон:

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

У меня возникли проблемы с получением SharedPreferences при использовании класса ViewModel, поэтому я последовал совету из ответов выше и сделал следующее, используя AndroidViewModel. Теперь все выглядит отлично

Для 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>"));
    }

}

А в 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;
    }
}

Проблема с внедрением контекста в ViewModel заключается в том, что контекст может измениться в любое время, в зависимости от поворота экрана, ночного режима или языка системы, и любые возвращенные ресурсы могут измениться соответствующим образом. Возврат простого идентификатора ресурса вызывает проблемы с дополнительными параметрами, такими как подстановки getString. Возврат высокоуровневого результата и перенос логики рендеринга в Activity затрудняют тестирование.

Мое решение состоит в том, чтобы ViewModel генерировал и возвращал функцию, которая позже запускалась через контекст Activity. Синтаксический сахар Kotlin делает это невероятно простым!

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)
  }
}

Это позволяет ViewModel хранить всю логику для вычисления отображаемой информации, проверенной модульными тестами, при этом Activity является очень простым представлением без внутренней логики для скрытия ошибок.

Использование рукояти

@Module
@InstallIn(SingletonComponent::class)
class AppModule {

    @Singleton
    @Provides
    fun provideContext(application: Application): Context = application.applicationContext
}

Затем передайте его через конструктор

class MyRepository @Inject constructor(private val context: Context) {
...
}