[WinRT] Breaking Changes: Support for View first as well as View Model first

Topics: Getting Started, UI Architecture
Oct 28, 2012 at 2:00 AM

There's been a number of requests for enabling view model first support as well as the already implemented view first approach for the WinRT version. It was also one of the last features we wanted to get integrated before rolling out a nuget version as this introduces some breaking changes.

All the breaking changes as of commit #e23acecba6bb are isolated to App.xaml.cs. 

As well as introducing support for both composition approaches it's also been reworked to do less work in CaliburnApplication to better enable you to add features such as Search, Launch arguments etc.

I've posted a full discussion of the changes at View or View Model first in Caliburn Micro WinRT.

The WinRT sample also has this article included, and as an example of using these methods shows implementing the Search and Share Target contracts.

Oct 28, 2012 at 9:37 AM

Great work :-)

In your article you speak about the bootstrapper ("Caliburn will ensure then ensure the Bootstrapper is initialized"). But there is no bootstrapper class in WinRT version of Caliburn.Micro. This is a bit confusing to me.

The bootstrapper is backed into the CaliburnApplication class on WinRT. This is different to the other platforms. Also there is now a bit of code duplication between the Bootstrapper class and the CaliburnApplication class.

Would it be possible to harmonize this across the platforms?

Oct 28, 2012 at 9:44 AM

Slip the tongue there sorry, I meant Application (though it's doing the same job as the Bootstapper).

The reason a Bootstrapper doesn't make sense in WinRT is almost none of the Application functionality is exposed as events, but rather method overrides. For instance in Windows Phone the Application has a Started event that the Bootstrapper can attach to and trigger behavior such as setting the default view. This event doesn't exist on the Application object in WinRT, all you get is the OnLaunched method to override. Because of this it makes sense for the Bootstrapper to BE the Application for WinRT.

Oct 28, 2012 at 10:09 AM
Edited Oct 28, 2012 at 10:15 AM

Thanks for the quick response.
Now it's more clear to me.

But I still prefer the bootstrapper,
e.g. the Application can hold the bootstrapper as instance member and calls into it if needed:

protected override void OnLaunched(LaunchActivatedEventArgs args)

I know this makes it a little more complex as you have now two classes methods to override.
For me the benefit is the separation of concerns (bootstrapping the framework vs. application lifecycle) and the harmonized API to the other platforms.

Maybe a bit of the complexity/extra work can be covert by nuget.

Oct 29, 2012 at 3:30 AM

I like that version better, thanks :-)

How about the OnSuspending and OnResuming events, how can we use those events with Caliburn ? 

Oct 29, 2012 at 3:41 AM

Both those events are still exposed by the application, although there's already some methods on CaliburnApplication hooked up to them for you to override. Right now there's nothing in the WinRT version to assist you there yet, but in this latest version there shouldn't be anything to get in your way either.

Regarding the Bootstrapper and the Application, at this point it's six of one, half dozen of the other. Personally I don't think the extra friction adding a Bootstrapper entails is worth it.