I’m taking the first steps into the MvvmCross framework and I’m trying to decide the best approach in terms of project and classes structure. My biggest concern now is to decide how should I organize my viewmodels in order to share data between them and at the same time to follow the mvvm guidance.
I have simple example with to views and respective viewmodels (Main and Configuration). The main view has some controls binded to properties in the viewmodel. The configuration view enables the user to change text color, number of items in the list, etc... When the user changes the configuration, this should be reflected in the main view.
My first approach was to create separate view and viewmodels. But how could I notify the main view that the configuration was changed? I saw the Sphero project under Github/Slodge and I realized that a viewmodel has direct references to other views. In this way, it is fairly easy to notify the main view each time the configuration changed. But isn't this a deviation of the decoupled viewmodels that mvvm recommends?
Could I get some insights on the best way to approach this type of class structuring?
the best way to approach this type of class structuring
In my opinion, the most important measure for "the best way" is to choose a way that means your app works.
The example you've looked at - sphero ball control - has examples both of independent view models (home, gangnam, about, sphero, etc), and it has an example of some view models that know about each other - the sphero view model and it's sub view models.
In this particular case, the reason those view models all know about each other is because they are all part of a single display - they are designed to sit together inside a single grid, pivot, or tabbed UI. To assist with them cooperating I've given them references to each other via IParent and IChild interfaces.
isn't this a deviation of the decoupled viewmodels that mvvm recommends?
I admit this does mean that the design isn't perfectly decoupled, and that if I need to move or reuse those child vm's in the future, then I might need to do a little code refactoring - but right now the design works well for me, and I personally am happy do that refactoring in the future if I need to.
My biggest concern now is to decide how should I organize my viewmodels in order to share data between them and at the same time to follow the mvvm guidance
If you are building a composite (tabbed) view and you're not happy using aggregated view models (like the sphero vm and it's subviews), then please don't.
I'm sure the same effect could have been achieved in sphero using one big view model, using multiple view models communicating via a messenger or using multiple view models communicating via one or more custom services.
For the particular example you give - of a configuration and main view, I don't think this fits the tabbed scenario - and I would probably code this using a messenger - that would provide me with a flexible mechanism for broadcasting and receiving change notifications around various parts of the app.
However, other designs are definitely available and viable - eg you could easily just ask the view model to refresh its configuration each time its shown (doing this would require hooking into onnavigatedto, viewwillapear and on resume calls in the views).
In summary: