This class exists so you can provide Android dependencies to the abstractions you're using in the ViewModel, without having to rely on a dependency injection framework.
Because like it or not, on Android you always end up needing a Context as dependency as soon as you need to access file paths, resources or services for example.
Passing the Application gives maximum flexibility while guaranteeing that the Context is an Application context and will not leak the Activity.
I personally don't end up with Context in projects I'm developing.
Device-specific stuff should be passed from classes which already has access to the context. This applies for resources, too. If I really need to decide some resources, I can use resource ids and then get that resource from an Activity.
It's indeed a good practice to remove Context from all the public APIs of our components, at least to make them easier to test. However, internally at the bottom level, many components in an Android app always end up needing a Context because Android requires it for so many things: accessing a system service, starting a component, connecting to a MediaSession, connecting to the Firebase SDK, ... or just simply accessing the file system!
So let's take an example: you have a ViewModel that needs to call a repository that internally uses a Room database for storage. Room needs a Context to be initialized. If you're not using dependency injection (like many Android apps back in 2017) and you want to lazily initialize this repository the first time you access it, then you'll have no choice but to pass a Context to it. AndroidViewModel was created to provide the application Context for that usage, so you don't have to pass an Activity Context manually from the View layer and risk creating a leak.
Of course today using dependency injection is the recommended way and injecting components with the right Context into a ViewModel constructor is easy with a library like Dagger Hilt.
Now I get what you are saying. You're right, of course. I didn't mean to pass repository to ViewModel. That'd be chaos 😀
The main reason I've written this article is because you don't get any warnings in Android Studio when using AndroidViewModel, even though it is clearly said not to be used in documentation.
Google deprecates functions aggressively, and sometimes to "direct" people to use good practices. However, it seems that this doesn't apply to AndroidViewModel.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This class exists so you can provide Android dependencies to the abstractions you're using in the ViewModel, without having to rely on a dependency injection framework.
Because like it or not, on Android you always end up needing a Context as dependency as soon as you need to access file paths, resources or services for example.
Passing the Application gives maximum flexibility while guaranteeing that the Context is an Application context and will not leak the Activity.
I personally don't end up with Context in projects I'm developing.
Device-specific stuff should be passed from classes which already has access to the context. This applies for resources, too. If I really need to decide some resources, I can use resource ids and then get that resource from an Activity.
It's indeed a good practice to remove
Contextfrom all the public APIs of our components, at least to make them easier to test. However, internally at the bottom level, many components in an Android app always end up needing aContextbecause Android requires it for so many things: accessing a system service, starting a component, connecting to aMediaSession, connecting to the Firebase SDK, ... or just simply accessing the file system!So let's take an example: you have a
ViewModelthat needs to call a repository that internally uses a Room database for storage. Room needs aContextto be initialized. If you're not using dependency injection (like many Android apps back in 2017) and you want to lazily initialize this repository the first time you access it, then you'll have no choice but to pass aContextto it.AndroidViewModelwas created to provide the applicationContextfor that usage, so you don't have to pass an ActivityContextmanually from the View layer and risk creating a leak.Of course today using dependency injection is the recommended way and injecting components with the right
Contextinto aViewModelconstructor is easy with a library like Dagger Hilt.Now I get what you are saying. You're right, of course. I didn't mean to pass repository to ViewModel. That'd be chaos 😀
The main reason I've written this article is because you don't get any warnings in Android Studio when using AndroidViewModel, even though it is clearly said not to be used in documentation.
Google deprecates functions aggressively, and sometimes to "direct" people to use good practices. However, it seems that this doesn't apply to AndroidViewModel.