we have forms where we collect some details from u...
# android-architecture
r
we have forms where we collect some details from users. the form spams to 4 screen. Data is different in each screen. So one of my colleagues used different viewmodels for each of them. I am against it. I asked them to move the validation and other application logic to usecase. Do you think my suggestion was right?. After the last step we will need to send details to server via api. Is there a better way to handle this?.
g
I think different view models make more sense, you just need some shared repository to allow save data from each VM before proceeding to next screen I think you would be fine with one VM if each step would be configured (so like config of fields) and managed dynamically by VM, but if each screen has own logic and it doesn't make sense to make more generic form configuration logic, in this case separate VMs looks as better, more scalable and clean solution
r
Hmmm. Makes sense now. So having different viewmodels and one shared respository for saving data should work. What about if ui states depend on some validation in view models ( next and back button common to all screens. Enable disable based on each screen validation). Have a separate class for yo state shared between view models
g
You can pass data explicitly from one VM to another, or just use repository to share it, so check on init what kind of data is there
Shared logic/UI of course should be extracted, to top level VM, or some use cases
👍 1
c
I had a similar scenario, and the approach which made sense and became easier to maintain in the long run is the the multiple VM as @gildor advises.
r
Thanks guys for the input. it boils down to the point of segregation of logic.