Interesting, thanks for the feedback. 🙂

Could you clarify in what way would you suggest leveraging polymorphism?

The I’ve found the Sealed Class approach useful in these certain situations when supporting a finite set of states. These states all map to actions on the framework, but we don’t want to be tied to the Android framework in our ViewModel.

By using the Sealed Class approach we ensure that the “switch statement” handles every state in the set, even if we add states later. Because we are isolating that switch statement to a single location, the 1:1 growth of branches to states doesn’t feel like a terrible tradeoff.

I could see the argument for a function on the BaseState class that could be overridden and thereby avoid the switch statement theoretically, but in doing so I believe would require the states to become aware of the Android framework to interact with the UI