Maybe I'm doing wrong in ArcGIS Pro, because I've started the first application/Extension with the old good habits from pure WPF applications.
But usually, you connect the View model in XAML like this:
<Grid x:Name="main" >
<Grid.DataContext>
<local:GfxViewModel/>
</Grid.DataContext>
(Where Grid may be any control in the page, not necessary the root, and the ViewModel may not be the main one handeled by the DockPaneManager.)
This approach, with proper techniques, let the page function in DesignMode as well using the Inversion Of Control pattern (somehow, injecting a corresponding model for RealTime, another for DesignMode and some more for unit tests...))
The problem is that if you associate the same ViewModel with another page in this way, each page creates its own instance, so the data you want to share is different in each instance.
What the above code references in line 3 is actually the parameter-less constructor of the ViewModel. You cannot add a parameter, refer a Singleton or a a static reference (although a static resource does the job...)
This is where the VMLocator comes. It is actually a static reference that manages VMs. It needs however a place where to instantiate its Singleton.
DockPanelManager is not a very good place, because you may need the VM instance in a Tool as well for example!
GalaSoft's MVVM Light may instantiate singletons managed by the static resource VMLocator in a top page named APP.XAML.
VMLocator is a very complex piece of code - I dare not reproduce it, mostly because of the testing involved.
It is a manager that can manage multiple VMs, singletons or not.
I already have a solution in the code behind, but I ask for a professional solution if somebody already have put it in ArcGIS Pro.
In my extension I have a DockingPanel that handle the main work with the above VM. I open it with a Ribbon Button.
I have another DockPanel that I open with another button (in a split of another ribbon button) that displays a Pie Chart (the beginning of a Dashboard,) with the data from the first Panel's VM.
Users may activate these buttons in any order, but obviously one of them is wrong.
My code behind in the Chart Panel check the instance of the Main Panel and give up if was not instantiated: the panel comes blank.
Could come better if it could make the instance first: could display a pie with four equal sectors (Eventually a message) which are the defaults of the DataSource. Will cange as soon as the VM will get notifications (Property Changed) from the first page.
But this solution would require instantiating the (same) VM of the Working Panel also in code. This makes the Design Time complicated... (And I don't have a general-enough place where to put the singleton.)
(Blocking the button of the Pie Panel until the Working panel opens also works, but then the ToolTip of the button - not mentioning the panel itself - won't come and I'll have to write a manual or help, which makes the User Experience gross...)
Note that instantiating VMs in the code behind, which is technically the View, breaks the MVVM pattern, making the design difficult and the testing incomplete!
Note also that a DockpaneViewModel is not exactly a ViewModel: it contains an internal static class for the button to open it, with override methods, which you have to trust - not to test...
