Como outros mencionaram, há o AndroidViewModel
que você pode derivar para obter o aplicativo, Context
mas pelo que reuni nos comentários, você está tentando manipular @drawable
s de dentro do seu, o ViewModel
que anula o propósito do MVVM.
Em geral, a necessidade de ter um Context
em seu ViewModel
quase universalmente sugere que você deve considerar repensar como você divide a lógica entre seus View
e ViewModels
.
Em vez de ViewModel
resolver drawables e alimentá-los para a Activity / Fragment, considere fazer com que o Fragment / Activity faça malabarismos com os drawables com base nos dados possuídos pelo ViewModel
. Digamos que você precise que diferentes drawables sejam exibidos em uma visualização para o estado ativado / desativado - é o ViewModel
que deve manter o estado (provavelmente booleano), mas é a View
função do drawable selecionar o drawable de acordo.
Isso pode ser feito de forma bastante fácil com DataBinding :
<ImageView
...
app:src="@{viewModel.isOn ? @drawable/switch_on : @drawable/switch_off}"
/>
Se você tiver mais estados e drawables, para evitar lógica complicada no arquivo de layout, você pode escrever um BindingAdapter personalizado que traduz, digamos, um Enum
valor em R.drawable.*
(por exemplo, naipes)
Ou talvez você precise do Context
para algum componente que usa dentro do seu ViewModel
- então, crie o componente fora do ViewModel
e passe-o. Você pode usar DI, ou singletons, ou criar o Context
componente -dependente antes de inicializar o ViewModel
in Fragment
/ Activity
.
Por que se preocupar: Context
é uma coisa específica do Android, e depender daqueles em ViewModel
s é uma prática ruim: eles atrapalham o teste de unidade. Por outro lado, suas próprias interfaces de componente / serviço estão totalmente sob seu controle para que você possa simular facilmente para teste.
AndroidViewModel
mas conseguindoCannot create instance exception
, você pode consultar minha esta resposta stackoverflow.com/a/62626408/1055241