This takes the old flag-based state management in Screen, and replaces it
with one based on a ScreenState enum. This also gives a way for
interested parties to query the current state, and for an event which
notifies of any state transition.
This meant combining IActivate, IDeactivate, and IClose. This is a sensible
move: these interfaces were inextricably linked anyway, and separating
them had no advantages and a few disadvantages. If external parties are
using these interfaces directly, then migration is necessary, but these
are usually only used by Conductors
Instead, it has an abstract RootViewModel property, which bootstrapper
overrides to return an instance of TRootViewModel from the container.
This means that the root ViewModel is treated a singleton by the bootstrapper,
regardless of whether it's singleton in the container
The previous behaviour was to raise an exception unless Execute.Dispatcher
had been explicitly defined. This was to detect cases where the user hadn't
set up Execute correctly, and treat them as errors rather than simply going
ahead with some possibly-unexpected behaviour.
However, since BootstrapperBase sets Execute.Dispatcher automatically, it's
highly unlikely that itwould ever not be set when it needed to be. Exceptions
are design mode and unit tests, both of which want (or can cope with) a
synchronous dispatcher.
Hence the behaviour change. Execute.Dispatcher is a synchronous dispatcher
by default, but is overridden to one that uses Application.Current.Dispatcher
by the bootstrapper if we're in a real application.
This is because PropertyChanged events can be async - WPF handles the
marshalling. However if CollectionChanged events are async, then the
thing listening to the event can still be iterating the collection while
the user's editing it, leading to irritating little exceptions
Having it as an extension method is good architecturally, but make it harder
to change its behaviour. This way, users can override it easily if they wish.
This also means that the WindowManager does not depend on the IoC service
locator, insteady accepting a Func<IMessageBoxViewModel>