First off, thanks for all the great work that went into this repo.
I just wanted some clarification with the purpose of @PerActivity. To explain further, after a configuration change the BrowseBufferoosViewModel instance returned by the framework will be the same one (same memory location) as before the config change happened (i.e. the instance is retained across configuration changes). This is one of the benefits of using the new ViewModel Architecture Component. It may be desired for other objects that are not tied to the Android framework to have this same behavior (i.e. an object that prevents the user to move to another screen if a network request is ongoing while a config change is happening). Dagger can be leveraged to achieve this by using scoping. Is this what you are trying to achieve with @PerActivity or are you just indicating that the module is providing Activity specific dependencies?
P.S. I realize that if we want an object to be retained across config changes, we can make it a dependency of the ViewModel in question, but this may lead to overly complicated constructors.
First off, thanks for all the great work that went into this repo.
I just wanted some clarification with the purpose of
@PerActivity. To explain further, after a configuration change theBrowseBufferoosViewModelinstance returned by the framework will be the same one (same memory location) as before the config change happened (i.e. the instance is retained across configuration changes). This is one of the benefits of using the newViewModelArchitecture Component. It may be desired for other objects that are not tied to the Android framework to have this same behavior (i.e. an object that prevents the user to move to another screen if a network request is ongoing while a config change is happening). Dagger can be leveraged to achieve this by using scoping. Is this what you are trying to achieve with@PerActivityor are you just indicating that the module is providingActivityspecific dependencies?P.S. I realize that if we want an object to be retained across config changes, we can make it a dependency of the
ViewModelin question, but this may lead to overly complicated constructors.