CODEWITHSUNDEEP
androidviewmodelandroid-mvvm
tommytucker7182
tommytucker7182

Reputation: 243

Android MVVM design - should i split my viewmodel class in two?

I have an app with 2 distinctly seperate modes, (setup and run timers).

The app allows multi factor inputs from a user on one fragment and once the user wants the timer started, the app switches to a running fragment to show information about their running timer and it's setup. I've designed an MVVM architecture for this, with my own class that extends ViewModel, my shared viewmodel has two distinctly different types of logic, setup logic (to check, parse and revise inappropriate user inputs), and running timer logic (to manage all the logic, data and state for a running timer from a user's inputs).

My shared viewmodel class is not small as the process of checking all permutations of user input is complex.  I'm wondering is it a bad idea to put all this logic into one viewmodel class? The setup portion is designed to be simple and all setup state is saved (so 10-20 seconds for the user to setup a timer seems appropriate), whereas the timer is designed to be allowed to run for hours, largely with the screen off.   Should I split the viewmodel logic into two different viewmodel classes to make a running timer more memory efficient?

I see a clear seperation of concerns and once I have my Room database designed and programmed, only the running timer will save data to the database. I want to keep the fragment classes as lightweight as possible.  If this is a sensible design choice, ill need to be careful with memory leaks between the two states, otherwise im defeating the purpose.

Edited to differentiate between the ViewModel object and a Shared viewmodel idea

Upvotes: 1

Views: 1033

Answers (1)

Jose Angel Maneiro
Jose Angel Maneiro

Reputation: 1316

As a_local_nobody says, it's up to you to decide how to design your app and distribute the responsibilities.

In case you are looking for our opinion about your philosophical doubts, I have to say that although the concept of the Shared ViewModels is very widespread, I am not a big fan.

In my projects, the most common and logical thing is that each ViewModel manages the logic of a single view. I always treat Shared ViewModels as an exception to the rule, since abusing them usually leads to a very tightly coupled code, very difficult to test and with unexpected side effects.

Upvotes: 2

Related Questions