I've been using ViewModels from Android Architecture for some time now, and abide by never exposing the ViewModel to Context/Views (Android Framework/UI). However, recently I have run into an interesting problem.
When making a timer app, when a timer is started, a Service is run in the background running the timer. This way, when the application is closed, the timer still runs in the foreground in the notification bar until all timers have ceased. However, this means that all of my Timer objects and state are contained in this Service. My UI needs to be updated on each tick, but the Model doesn't necessarily need updated How do ViewModels fit in with this scenario?
Should the Activity receive LocalBroadcasts and notify the ViewModel every time? Should the UI state be read from Service->Activity->VM? It almost seems like the Service is the ViewModel, but this doesn't seem efficient.
After some toying with different structures, the Service has found it's place in MVVM. What was throwing me off in this situation was thinking a Service shouldn't be started from a ViewModel and the fact that two repositories were necessary: Room Database to store Timers and a Service to represent the state of ongoing timers (onTick, play/pause status, etc). A ViewModel should not have any reference to views, but application context is OK. So starting the Service from a ViewModel is doable by extending the AndroidViewModel class. Here is the final structure:
Model Layer
ViewModel
UI