Good ViewModel!

I believe we all know keeping viewmodel size minimal by moving business logic to use cases or interactors is a recommended practise. It helps manage extensibility and reusability, making it easier to scale features. But it’s not always just interactors that we want to invoke or listen to. One might want to listen to hardware, trace performance, perform multiple calls to different domain/data layer modules, & finally merge the output to a ui state if needed. These are a few things a viewmodel does or delegates, but still quite a responsibility for a single class. So, how do you define a viewmodel that is clean, easier to understand, and make changes? Simply said, how to have a good viewmodel!

Let’s move such functionalities out of the viewmodel, refer to common examples classes below-

1. UseCases
   • You can simply use cases like
     • LoginUseCase
     • MenuItemsUseCase
     • PaymentUseCase
     • CheckoutUseCase
     • TrackOrderUseCase
2. Tracker
   • MenuScrollTracker
   • FeedTracker
3. Tracer
   • LoadMenuItemsTracer
   • PaymentsTracer
4. Converter
   • MenuItemToMenuDisplayConveter
   • OffersToOfferDisplayConverter
   • UserPageResponseConverter
5. Delegate
   • ClickDelegate
   • TrackOrderDelegate
6. Hardware-Manager
   • NetoworkManager
   • LocationManager
7. PaymentProcessor
   • requestInvoice
   • peformSale
   • performRefund
8. PrintingProcessor
   • printInvoice
   • checkActiveJob
9. SessionManager
   • checkActiveSession
   • isAuthorised

Now, wherever these classes are, be it your core or base modules, or within the feature modules, you can use a dependency injection framework like Hilt/Dagger2, Koin to inject them into your viewmodel. This will reduce the size of your viewmodel by many folds. Teams can work on these classes in parallel, which is another advantage, speeding up the overall delivery of features and bug fixes.