ground-android
ground-android copied to clipboard
google
Should FieldViewModels exist?
We always re-create *FieldViewModel as a screen can have multiple fields of same type. Does it mean that ViewModel shouldn't exist and all the logic should live in the views instead?
@scolsen @gino-m Wdyt?
We always re-create
*FieldViewModelas a screen can have multiple fields of same type. Does it mean that ViewModel shouldn't exist and all the logic should live in the views instead?
From my understanding the VM are useful regardless. Their benefit comes from reduced complexity since they let us keep low-level Android-specific view logic (View) separate from app-specific UI behavior and state (ViewModel), and from the increased testability that comes with doing so. Besides, the fact that VMs usually have a longer lifecycle than views is opaque to those views, since we must always assume they can be destroyed as well.
I was trying to replace the custom view model factory with the androidx provided solution. Turns out, the api doesn't provide a way to force create a new VM instance. It always returns the last created one. That made me wonder whether we are using VMs correctly or not.
I was trying to replace the custom view model factory with the androidx provided solution. Turns out, the api doesn't provide a way to force create a new VM instance. It always returns the last created one. That made me wonder whether we are using VMs correctly or not.
Iiuc ViewModelProviders returns the last instance for a given Fragment or FragmentActivity. I was thinking about this last night; should anything with its own ViewModel be defined as a Fragment? In that case the androidx helpers would make sense, and they would get their own lifecycle hooks.
Hi @dturner! Qq - if individual form fields have their own ViewModels, is it advisable to implement individual form components as Fragments? Or is that too heavyweight for things like form fields?
This isn't relevant anymore due to migration to tasks. (since tasks have both fragment and viewmodel)