Hello guys 👋 , i have a question. (sorry, my English is not that great. 🥲) is it okay use view’s context in viewModel like this? I don’t think I should use it. • UI xml

...
<Button
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:onClick="@{(view) -> viewModel.onClickButton(view)}"
    ... />
...

• ViewModel

...
fun onClickButton(view: View) {
	val context = view.context
	// work on something use context
}
...

No, for example when the user rotates the screen you can get a crash

thanks for the answer 🙂 i agree, but unfortunately my partner use like this luckily our app is fixed vertically, so the crash has not occurred yet. 🫠

that depends on how the user uses the app, but you will get them for sure 🙃

rotation is just the easiest way to get a configuration change, there are many others

I used to have an app where I passed the context to the ViewModel. It led to stale configuration. Specifically, I was using the Application context in the ViewModel, not the Activity context. I don't remember the exact details but I think language changes were not picked up by the UI because the ViewModel held on to the "old" context. Now I try to write code such that whatever I need the context for, I resolve that just-in-time when I display it (i.e, in my View).

thanks for the advices 💪

I just needed to write to file system in my VM which requires a context so I would know the files dir. Since I use hilt I just injected @ApplicationContext context: Context into my VM and it doesn't feel too bad. I'm assuming that makes my VM non-testable though...? 🤷

pass the file from the view to the vm instead of passing a string path and use context in the vm

You could make it more testable if, instead Context, you’ll receive an

interface

that does return directories. The implementation of context would be injected at runtime via DI, while in tests, you provide a fake implementation

@Javier i considered that, but there wasn't a good spot to do that IMO because the event that triggers the file save doesn't come from a user interaction... but yeah I considered that approach and @krzysztof approach. both are good but i tend to lean towards krzysztofs approach

直接还是在activity中写点击事件，然后用viewModel操作数据

rotation is just the easiest way to get a configuration change, there are many others

@ephemient I found the easiest way is to use the quick setting tile to toggle dark mode, especially when testing behavior in apps that have fixed orientation.

I find that changing split/window mode requires a bit less stretching (my phone's too tall, the notification bar is so far away!) but honestly they're both pretty easy :)

Isn’t it okay to pass in a

Context

as long as the view model doesn’t hold on to it in any way? i.e. if the method is called on the main thread and all the work using the

Context

is done synchronously (e.g. no reference is passed to another thread)?

It depends on how you pass in that context to the ViewModel. If you use constructor injection then the context is not reactive enough. When config changes happen your ViewModel doesn't know about it and it doesn't resolve resources for example. If you're using the context for other things like getSystemService it could be fine. But I argue that such code should belong in the data layer anyway.

I mean specifically the example given. Passing it into a method. Config changes shouldn’t be an issue because the code is running on the main thread and so will block the config change no?

You're right. In this specific example the ViewModel doesn't seem to be holding on to the context so this should be fine.