.NET & Funky Fresh : Caliburn, WP7

Durandal 1.2.0 and Caliburn.Micro 1.5.0 Released!

Rob Eisenberg — Tue, 19 Mar 2013 00:10:59 GMT

Two awesome releases in the last week! Much thanks to the great community surrounding both projects! Here’s what’s new:

Durandal 1.2.0

Tons of bug fixes.
Lots of improvements to the router.
Better support for integrating with Q, KendoUI and Dojo.
More docs.

Caliburn.Micro. 1.5.0

Nigel Sampson and Thomas Ibel are going to town these days! Some really cool stuff happening in this release. Here’s a few things:

Task and Async support (on all platforms except SL4 and WP71)
Task/Coroutine integration.
Actions can return tasks.
More async stuff in general.
Support for the WinRT Share Charm
Support for the WinRT Settings Charm
Various bug fixes and minor improvements throughout.

You can get the latest versions of both of these frameworks on Nuget.

Caliburn.Micro v1.4.1 Released

Rob Eisenberg — Sun, 20 Jan 2013 19:43:06 GMT

I’m labeling this the Thomas Ibel/Nigel Sampson release. Why? Because these two hardworking gentlemen have put great effort into bringing you the most mature version of Caliburn.Micro yet. In the two months since our 1.4 release they’ve dealt with almost every outstanding issue on our list. Great work guys! In addition to bug fixes, there’s been some minor enhancements, we’ve synced up the latest WUI library and added official support for WPF 4.5. You can get it on Nuget now. Enjoy!

Bring on the AWESOME!!! Caliburn.Micro v1.4 Released

Rob Eisenberg — Fri, 16 Nov 2012 03:28:00 GMT

Today I’m happy to announce the official release of Caliburn.Micro v1.4. This release brings a ton of bug fixes across all platforms, nuget fixes…and best of all…full support for WinRT and WP8. That means that Caliburn.Micro now supports WPF, SL4, SL5, WP7, WP8 and WinRT. AWESOME!!! You can get it on nuget.org or download the binaries directly from codeplex.

How did this happen you say? Well, not without generous help from the community who believed in this project and put in the hours to make it happen. Here’s a few people I’d like to mention:

Marco Amendola – A Caliburn veteran. Always working hard on bugs, features and community support.
Chin Bae – Master of our view location strategy.
Nigel Sampson – Monster WinRT port guru. He practically ported the entire thing himself. REALLY.
Thomas Ibel – Tons and tons of bug fixes and stability improvements.
Matt Hidinger – Did all the grunt work to get official WP8 support into this release.

I’d also like to thank all the community members who tested out this version, submitted feedback..and of course…thanks to everyone who submitted pull requests. It was a tremendous help!

Finally, I’d like to extend a special thank you to Scott Hanselman, Scott Hunter and the whole .NET team for supporting open source software and providing the necessary licenses I needed to actually build and release this version. It would not have been possible without their kindness and generosity.

For reference, here’s the full list of nuget packages and their descriptions:

Caliburn.Micro – The full framework compiled into an assembly.
Caliburn.Micro.Start - Includes Caliburn.Micro plus a starting bootstrapper, view model and view.
Caliburn.Micro.Container – The Caliburn.Micro inversion of control container (IoC); source code drop-in.
Caliburn.Micro.EventAggregator – The Caliburn.Micro event aggregator; source code drop-in.
Caliburn.Micro.INPC – The Caliburn.Micro INPC infrastructure: PropertyChangedBase, BindableCollection, Execute.OnUIThread and InDesignMode checking; source code drop-in.

Note: We have removed the starting bootstrapper, view and view model template code from the core package and added a new package, Caliburn.Micro.Start, which now has the core plus the startup files.

Go forth and build Xaml awesomeness! And stay tuned for an update on Durandal in the next few weeks too ;)

This community project is sponsored by Xceed, makers of Xceed DataGrid for WPF, the enterprise datagrid that provides a rich, fluid, and high performance user experience. 50% off any Xceed product with coupon code G00B8T. Xceed also offers Extended Silverlight Toolkit and Extended WPF Toolkit here on Codeplex.

Today….All Your Wildest Dreams Come True

Rob Eisenberg — Thu, 02 Aug 2012 20:07:00 GMT

If you fit into any one (or more) of these three categories…

You like tabletop RPGs
You build Xaml applications
You build Html/JS applications

1. RPGWithMe

For some time I’ve been cranking away building my company’s first real product. I’m very excited to officially announce to you today that RPGWithMe is live! RPGWithMe is a web-based platform centered around tabletop RPGs. If you play these games…you are going to like this a lot. RPGWithMe provides four main feature areas in its initial launch:

Character Sheets

The industry’s most beautiful character sheets, fully interactive and free: Use them at the gametable on your tablet or laptop. They’re also fully integrated into our play-by-post and virtual tabletop experience. It's as simple as uploading DDI or Hero Lab ^® files. Custom character creation is coming soon…

Campaign Management

We provide gorgeous home pages for your campaigns. Use our live-previewing editor to write wiki articles and pin them to your home page. Chronicle your adventure and automatically have your content indexed for later. Plus, access our enormous, high quality art library for use in your wiki or upload your own art.

Play-by-Post

We’ve built our system from the ground up to support PbP. It fully integrates your player’s character sheets and your campaign wiki. It snapshots roll, magic, power and feat data and provides multiple views over your campaign’s activity feed with the ability to bookmark and integrate your character’s journals too.

Virtual Tabletop

Build maps, play out combat and track NPC stats. Our virtual table can be used to enhance PbP beyond anything you’ve seen. Of course, you can always use it as a realtime virtual table on it's own and feel the power of integrated character sheets, rich activity feeds and campaign management.

RPGWithMe Teaser

2. Caliburn.Micro WinRT

Thanks to the fantastic work of Nigel Sampson and Keith Patton we now have support for the full Caliburn.Micro feature set on WinRT. This is he initial port…and its not an official release yet, so there’s bound to be bugs. But if you want to use CM to build your WinRT app, please start using this code and help us iron out the kinks….and naturally start enjoying the CM way of building apps on WinRT.

3. Durandal

Durandal is the essence of Caliburn.Micro re-imagined for HTML and Javascript. A very early version of the code is now available on github. It is a very small amount of code built on top of three existing and established Javascript libraries: jQuery, Knockout and Require. Features include:

Fully modularize your html and js the same way you would when building Caliburn.Micro applications. ie. Shell.js automatically locates Shell.html, binds and gets composed into the dom. Naturally you can change the conventions…
Leverage promises everywhere as the API uses no callbacks, but has CommonJS promises plumbed throughout
Experience the first html/js framework where Composition is embraced at the very core. The view/view-model composition features of Durandal are even more powerful than Caliburn.Micro.
A simple app model provides you with an app start lifecycle, modal dialogs, message boxes and an event aggregator.

This is a pre-pre-pre-alpha version. There are no docs and just one sample at the moment. But, I wanted to get it out there so you could dig into the code, start playing with it and give me feedback. Of course I’ll add docs, more samples, tests, etc. Just in case you are wondering though, Durandal is already being used in production as the framework for RPGWithMe’s virtual tabletop. Various versions/pieces of it are being used by some of my clients…details not available right now, but I hope to share more later.

Things I would like to do with Durandal in the future:

Remove the Knockout dependency. I don’t like how knockout bindings work in html and I don’t like how observables invade your model code. Both are ugly, tedious and obscure the readability of the code. I have a plan to fix both of these, but it’s non-trivial. I chose to put together this initial version based on knockout since it was already in heavy use and it was quick and easy. In the future I hope we can improve on that.
Remove the jQuery dependency. Durandal only uses a few features of jQuery. So, eventually, I’d like to have an alternate solution without an external dependency. You can always use jQuery if you want to, but in the long term, I don’t want to force it on developers.
Create a component model for building reusable controls. This should work similar to Xaml in that controls should have a distinct view written in html which can be replaced globally or on a per use basis. Controls should also support templated parts with the same characteristics.

Ok. That’s enough news for today. Enjoy. Now…I’m going to rest for a bit.

The Manifold Blunders of Xaml–Part 1: Version and Platform Hell

Rob Eisenberg — Wed, 18 Apr 2012 15:43:00 GMT

I started work with “Xaml-based” platforms in the pre-Beta days of WPF, so I’ve been working with this technology longer than most. Back then I was utterly awed and inspired by it’s capabilities. Today I’m frustrated and sometimes outraged. As I’ve traveled to various conferences, worked with various companies and interacted with the many Caliburn.Micro users, I’ve discovered that I’m not the only one who feels this way. This blog series attempts to catalog a number of the issues, some of which have been there from the very beginning; others creeping in over time. This is an aggregate of my own observations and those of the community.

Versions

Let’s take a brief stroll through the platform timeline:

2006 – WPF 3.0
2007 – Silverlight 1
2007– WPF 3.5
2008 – Silverlight 2
2008 – WPF3.5 sp1
2009 – Silverlight 3
2010 - Silverlight 4
2010 – WP7
2010 – WPF4.0
2011 – Silverlight 5
2011 – WP7 Mango
2011 – Lakeshore¹
2012 – WinRT/Metro²

If we focus on the platforms and ignore their various versions, we have something like this:

2006 – WPF
2007 Silverlight 1.0 (no CLR)
2008 – Silverlight 2.0 (CLR)
2010 – WP7
2011 – Lakeshore
2012 – WinRT/Metro

So, it appears that Microsoft has released a new UI platform at least every two years! Let’s contrast that to the timeline for pre-Xaml UI technologies:

1985?– Win16
1995 – Win32
2001 – WinForms
2006 – WPF

Interesting. We have at least 5 – 6 years between platforms prior to Xaml, but it’s actually about 10yrs due to the fact that WinForms is just making Win32 available to managed languages. It’s just a wrapper around existing APIs. Each of the Xaml platforms is actually a different runtime altogether. So as far as platforms go, we’ve gone from one every 10yrs to one every 2 years. But that’s not all, let’s look at Xaml itself:

2006 – Xaml 2006 Spec
2008 – Silverlight 1 Xaml
2009 – Xaml 2009 Spec
2011 – Silverlight 5 Xaml
2012 – WinRT/Metro Xaml

Aside from the actual platforms released, we have a parallel divergence in Xaml markup capabilities. In 2006 the first version of Xaml was released. It was formally defined and released as a spec shortly after. When Silverlight came along, Microsoft failed to create a Xaml language compatible with their own specification. In fact, even Silverlight 5 doesn’t comply with the Xaml 2006 spec. In 2009 Microsoft released a new version of Xaml that fixed several important shortcomings with the 2006 spec….but not a single platform implemented it. WP7 is still playing catch-up with Silverlight and WPF. WinRT/Metro Xaml has less Xaml features than any platform. Furthermore, it significantly changes some aspects of Xaml altogether, making it compatible with almost nothing. Furthermore, some of the changes they are making will prevent it from ever becoming compatible in the future.

When I step back and try to look at this information objectively, the most natural conclusion I can come to is that Microsoft UI technologies are, and have been for the last five years, in a state of complete instability…and it doesn’t show any signs of change (esp. with the rumors that WP8 will not use Silverlight, but some variant of WinRT). You can’t count on anything. If we forget about app developers for a moment, and think about the ecosystem, imagine the effect this has on third party products, control vendors, open source frameworks and tooling. Every time MS spits out a new platform or Xaml flavor, the entire ecosystem has to start over.

My own Experience

I first wrote Caliburn for WPF when there was no word on anything like Silverlight existing. When Silverlight was first announced, it was branded WPF/e so I thought my framework would port. Unfortunately, when SL2 was made available, there were so many differences that I had no choice but to completely re-write Caliburn. Then, when WP7 was announced, I started porting Caliburn to that, only to discover that it was not possible. So, I did another complete re-write resulting in Caliburn.Micro. Now we have WinRT/Metro. I think I can port it, albeit, with a ton of conditional code. But, I’m not 100% sure yet. If it looks like another re-write…I’m done with this game.

Maintenance and Innovation

There are lots of negative side-effects to this sort of instability. The one that hits me most is that it creates a battle between maintenance and innovation. Again, speaking of my own project, I have plenty of ideas about how to improve Caliburn.Micro. I think some of them are minor niceties, but others are more along the innovative lines. But, you will never see any of them come to fruition. Why? Because the instability of the underlying platform, the constant release of new platforms…has put my project into a state of perpetual maintenance. I can’t innovate because I’m still trying to deal with the differences in WP7.5 and I’ve got developers (who can blame them?) banging down my door wanting to know when WinRT/Metro version will be available. It’s been discussed much in recent years as to why innovation seams to happen in non-Microsoft open source and on other platforms like Mac…while very little happens in Windows software. Could it be because we are spending our time re-writing everything every two years? and don’t have time to develop anything forward thinking?

Careless and Arbitrary

Sadly, many of the API and Xaml differences were completely avoidable. I remember one particular bug I had in Caliburn. It resulted from the fact that List<T>.Remove was implemented differently between WPF and Silverlight. In a particular scenario it would work fine on one platform and crash your app on another. There are hundreds, probably thousands of such issues, from the BCL all the way up through the UI stack. We aren’t talking about missing features here. We are talking about the same features which exhibit different behavior or have altered APIs. Sure, Microsoft worked hard to improve this with successive releases of Silverlight. But then came WP7, which stepped us back in time. Now look at WinRT. There are a number of changes that are completely arbitrary. They serve no technical purpose and don’t improve the API. They just make more work for developers who want to port code. If you want another fine example, just try to write a cross-framework design mode check.

A Lack of Understanding

Sigh. This one perfectly ironic issue really troubles me sometimes. Through all of this, I’ve realized that Microsoft doesn’t understand their own platform. I’ve got more to say on this later, but let’s look at this from an API perspective here. Consider this: every control specific to WP7 development could have been built on top of Silverlight without a need for a modified runtime. Most controls could have been implemented simply by styling an existing control or applying a template. For example, the Pivot control can be implemented using a tab control with a custom template and some attached behaviors. In fact, wouldn’t it have been cool if you could just use a Tab control in WP7 and it just changed it’s appearance to work on the phone?! Wait, wasn’t that the idea behind templating and adaptive layout to begin with? Here’s another example: Behaviors. Perhaps you didn’t know that Microsoft built this twice? In WPF there were Triggers. In fact, in both WPF and the Blend behavior system, there is a class called TriggerBase. They have the same name! They do the same thing! But, you can’t create custom triggers or actions in WPF because the ctor is marked internal. Did it not occur to anyone that they should just remove that instead of re-inventing the wheel? As a result, we now have two methods of doing triggers, and you have to know which to use for what. It’s even true in Silverlight, which has limited support for “traditional” triggers, but does have some. Ridiculous. I could go on and on about the types of internal and cross-platform inconsistencies MS has created by not simply understanding the core capabilities of their own framework.

All of this get’s really interesting if you consider that Mac is the platform that is considered most cutting edge and innovative in terms of UX…and they’ve scarcely had any major breaking changes since 2002. Considering that their phone apps run on their tablet and they are porting a number iOS features back to OSX…it must be nice only having to worry about two platforms and knowing that the OS vendor is making a visible, tangible effort to unify those two platforms…..but I’m getting off topic now.

End of Part One

There are lots of problems with Xaml, but I chose to start this series with one of my particular pain points. Some developers neither care nor are affected (yet) by these sorts of version issues, but they have a big effect on the surrounding ecosystem and are going to be with us for the next decade. Over the next several blog posts, we’ll discuss many other problems, some technical, some not so much, but all have been singled out by multiple members of the community (read: not just me) as problems. It is my hope that Microsoft employees working on these technologies will read this and seriously consider what they can do to improve things going forward or at least not perpetuate the same mistakes again. I also hope that .NET developers will take a long, hard look at this part of the platform and make an honest valuation of its strengths and weaknesses.

Footnotes

1. Lakeshore is the name I’ve been hearing thrown around for the Xaml-runtime for XBox, which sources say is Silverlight-based, but drastically altered. I have no official word from Microsoft on this. It’s just what I heard through the grapevine, though I’m fairly confident in the accuracy of the information. Supposedly this is what is powering the “apps” in the new XBox dashboard which was released around last Thanksgiving. EDIT: Apparently the XBox version is called Lakeview not Lakeshore.

2. I don’t actually know when WinRT/Metro will be released. I imagine that 2012 is a reasonable guess.

Boo-yah!!! Caliburn.Micro v1.3 RTW is Here

Rob Eisenberg — Sat, 21 Jan 2012 01:32:00 GMT

I’m extremely pleased to announce the release of Caliburn.Micro v1.3. This is a great release with many bug fixes and several API improvements. We also support several new platforms. Here’s the highlights:

Support for WP7 Mango
Support for Silverlight 5
Basic MVVM Support for WinRT/Metro
Awesome improvements to ViewModelLocator/ViewLocator which allow easier customization of conventions.
Improved Design-Time Support for Conventions

Thanks to the great community who provided awesome feedback during this release cycle. Thanks also to those who spent time to provide fixes and pull requests for bugs as well as for API improvements. I’d like to add a special thanks to Chin Bae for excellent work on making our ViewLocator and ViewModelLocator both more extensible and more accessible for common customizations.

We’re still just getting started. Enjoy the new bits and see what you can build!

How I Lost, Regained and then Turned Down an MVP Award

Rob Eisenberg — Thu, 05 Jan 2012 01:46:00 GMT

What Happened To Me

I’d say that 2011 was a pretty good year for me as a .NET open source developer. After all, Caliburn.Micro had it’s first official release in April 2011 just in time for the Mix Open Source fest. At the festival, the framework had a great showing. I had tons of people literally coming up to me and dumping *all* their voting tokens into my bucket. In fact there were so many people constantly standing around my booth that my bucket didn’t even get collected for counting in the official vote. Thankfully someone standing around realized this and helped to remedy the situation. Needless to say, it was a successful event. Over the next several months I did two additional non-trivial releases and then began work on the v1.3 release. I also added support for Silverlight 5, WP7 Mango and preliminary support for WinRT/Metro. Furthermore, I began refactoring the entire framework so that it could be modularized into “feature” packages allowing a variety of different uses of the framework via Nuget. I even tested CM’s EventAggregator and IoC container to make sure they would run without issue on iOS and Android devices via Unity3d. In addition to the actual framework development, I wrote documentation, blogged, fixed dozens of bugs and added new features. I also participate daily in the Caliburn.Micro forums which currently have about 1k discussions. Caliburn.Micro is now used as the core enabling framework for thousands of applications across WPF, Silverlight and various versions of WP7. Depending on the day, Caliburn/Caliburn.Micro is the second or third most trafficked Xaml-related open source project in existence.

I’m not trying to toot my own horn here. I’m just trying to set up a context. Considering the enormous amount of work in both creating the project and supporting the community…you can imagine my surprise when I received the “form letter” stating that my MVP was not being renewed because I hadn’t accomplished enough in the last 12 months….and what I did do did not “stand out” in the community. Here’s the actual quote:

“The MVP Award is presented to individuals for their past year’s contributions to online and offline communities, which stand out from others in the communities that focus on Microsoft technologies. Your contributions were diligently evaluated over the past year against the contributions of others in the Silverlight community. As a result of this evaluation, you were not awarded as a MicrosoftMVP for the January 2012 award cycle.”

Now, I’m not really “attached” to being an MVP. I don’t attach a lot of self-worth or emotional satisfaction to it. It’s a nice thing to have though. So, I was really caught off guard by this and wondered how the MVP program could come to the conclusion that I hadn’t significantly contributed in the last year.

What I Did

Being surprised as I was, and not being too fond of “generic” letters , I made one simple tweet:

“Apparently Caliburn/Caliburn.Micro and my support of it is not a ‘good enough’ contribution for Microsoft. I lost my MVP this year.”

The Community Response

Immediately following this tweet, a storm of people responded with great affection for my work and general encouragement. I want to say thank you to everyone who responded so kindly. Paired with the encouragement was a general sense of befuddlement around how the MVP program could make such a conclusion. Apparently, I wasn’t the only surprised individual.

I thought to myself “mistakes happen.” But as I was surveying the twitter-verse, I also learned that Jeremy Miller (StructureMap, FubuMVC, Storyteller) and Daniel Cazzulino (Moq) also lost their MVPs; two other prominent open source developers. Now I had had some problem during the re-evaluation process indicating my new MVP Lead clearly didn’t understand the nature of open source. When I was up for renewal, he asked me to fill out a rather ridiculous spreadsheet. If you could see it, you would notice something missing? There’s no category for Open Source!!! There’s not even a way to report it. I had this problem in previous years when I was asked to update my online MVP profile (a hideously painful UX by the way). The program uses that to evaluate you as well. Guess what? There’s no way to report Open Source work!!! Do you see a trend here?

--Start Rant

The thing that really disturbed me was that my MVP Lead didn’t know who I was or understand the nature of my contributions. What is it that an MVP Lead does anyways? I can’t tell. I get a useless mass email every week or so telling me things about Microsoft I don’t care about. Half of the time it isn’t even readable due to bad formatting, etc. My Lead never contacted me personally during the year. When I came up for renewal, I had to *defend* why I should have my award renewed using a bad Excel spreadsheet and a really bad online form which don’t even allow me to capture my real contributions. Shouldn’t it be an MVP Lead’s job to know his MVPs and what it is they are doing? Seriously. I sat down and calculated how much time it would take me to fill out the Excel form and the online form, plus writing a custom report for everything that wasn’t able to be captured via those broken mechanisms. I took that number of hours and multiplied it by my hourly consulting rate and determined that the money I would make working exceeded the material value of the MVP award. Haven’t I given enough free work to Microsoft? This isn’t a personal attack on *my* MVP Lead. I don’t know the guy. But, I wonder whether the role of MVP Lead is improperly defined or under-defined, because I know that I’m not the only person who has had this exact problem repeatedly.

--End Rant

Microsoft Employees to the Rescue

Also following my tweet, a number of Microsoft employees stepped in to investigate. I have to thank them here personally. Much thanks to you (in no particular order) Tim Heuer, Pete Brown, Joe Healey, Glenn Block and Scott Hanselman. At one point I heard that this issue had even been escalated internally to Scott Guthrie. It’s truly an honor that so many well known and respected individuals *inside* Microsoft stepped up to personally investigate my situation. Thank you again. This is a tremendously good thing and points out something of great importance. Over the years I’ve very rarely had negative experiences with individual Microsoft employees. But, I’ve almost always had bad experiences interacting with groups, programs, etc. It seams that somehow the opinions of the individuals are lost in the system. That’s a real shame.

If the opinion of many trusted Microsoft employees and the opinion of so many community members is not reflected in the MVP Award, then there certainly is a problem with the program…or I don’t understand what the program is.

An MVP Again…for a few hours

Thanks to the work of the gentlemen listed above, I was informed last night that I was being re-awarded an MVP for the 2012 year. I understand this sort of thing never happens. But, I’d already had several days to reflect on the MVP program and had several conversations with various people leading to several realizations listed above and several more detailed below. I was very unsettled.

Why I Turned Down the MVP

This morning I responded to the award email with a respectful decline. Below are some of the reasons I chose to no longer be a part of the program and why I doubt I will participate again, unless serious reform happens.

Becoming an MVP

One of the problems with the MVP program is that the whole thing is basically a mystery. Here’s where I first knock heads with the program. I value transparency and openness, even if it’s difficult or sometimes painful. The MVP program does not value openness. That’s why it’s basically a mystery how you get nominated for an MVP or what you have to do to get one. Let me do a little exposé here. In my case, I’m fairly sure that my local Developer Evangelist saw the work I was doing in the local community and submitted me. That’s a good thing and it’s probably fairly common. But what happens from there? It’s my understanding that it’s completely out of DPE’s hands at that point. Who knows? From what I can tell, if the MVP program is interested in you, you then have to submit proof of your accomplishments to them. I remember doing this. It’s not like a normal award where the organization does the work to investigate your contributions and then decides whether or not to give you an award. No. If you are being considered for nomination, you literally have to *sell* yourself to the MVP program…and selling is exactly what you are doing. Want to know why? Have you noticed that the MVP disciplines are strictly organized around internal product groups, regardless of how hindering to the particular MVP discipline it appears to be? An example of this is that Client AppDev, Silverlight, WP7 and Blend are all separate MVP groups even though they should be unified. Because they are different products, they are different MVPs (actually, they should all be the same product, but that’s a subject for another blog post). Do you know why this is? I’ll tell you: because each product group literally gets an MVP “budget” which they use to “purchase” MVPs for the year. Personally, I’m offended by this notion. But it would take drastic re-organization of the MVP program to fix it.

General Life as an MVP

Now you can just imagine how this division along product lines and MVP purchasing might affect things. Because Microsoft’s product teams are notorious for not only being non-communicative with one another but are often pitted against one another by the upper level management…the various product teams can develop a vastly different set of values and beliefs with respect to interaction both internally and with the outside world. Depending on what MVP discipline you are a part of…and the nature of your contributions…you may have a great experience or you may be in store for hell. If the product group you are associated with is open, such as ASP.NET, you can expect lots of interaction, incorporation of your feedback into the product and probably a deep respect of open source work. If your product team is something like WP7, you can expect much less communication, very little change to the product based on your feedback and probably…they don’t even know what open source is.

My Life as an MVP

As for myself, it’s clear that my major contribution is through an open source framework. What a fool I was…there’s a certain insanity in building an open source framework on top of a proprietary UI stack. Back when I was awarded the MVP, I was given the Client AppDev designation, which basically means WPF (but for some reason, contrary to what I’ve said above, also included WinForms..interesting how they had WPF and WinForms in the same group but not WPF and Silverlight…but I digress…or do I?). Back then Xaml tech wasn’t so secretive. When Silverlight came along, they moved me into that group. That group was different. Silverlight was kept tightly sealed. When I was a Client AppDev, I actually felt like Rob Relyea and John Gossman were my kin. When I became a Silverlight MVP, I felt like I was an outsider being graced with a little tiny window to peer in on things. I say all that because when I started on Caliburn, while I was working on a proprietary platform, it felt more open. But when Silverlight came along, things changed. WP7 was even worse than Silverlight…and WinRT/Metro…well…they didn’t talk to anyone. Now that Xaml has moved out of the Developer Division and into the Windows division, it’s only going to get worse.

Secret Societies

I’ve already mentioned how the organization of the MVP groups along product lines can be a hindrance to everyone. WPF, Silverlight, WP7, Metro and Blend…which are all used by the same group of people, are actually different MVP groups. As a Silverlight MVP…I had no access to anything happening with WP7. I had no knowledge of WinRT/Metro. I had no knowledge of Blend or any mechanism to directly interact with that product team. Now, Caliburn.Micro spans all of these technologies, but I could really only talk to Silverlight product team members…and a few of my old WPF comrades. But would it surprise you if I told you the organizational absurdity went even farther. Did you know there are “insiders” groups. “Insiders” for a particular product group have more privileged knowledge than MVPs and more opportunities for direct interaction. Some MVPs are also insiders, but not all. Some insiders are not MVPs. But wait, there’s more. There’s also the TAP program….which seams to have more privileged connections and knowledge. To this day, I don’t know how one gets in a TAP program. I was in the WP7 Tap for about two days. Some guys already in the program were talking in the TAP forums about getting Caliburn.Micro working on WP7. They yelled loud enough and the powers that be invited me, since it seamed that significant apps were likely to be built with my framework. Unfortunately, things went public very shortly after that and the TAP was closed. LOL. But it doesn’t end there. It seams, based on observation, that there are even more secretive groups…who pretty much know everything the product team knows. These guys don’t have a name and I don’t know how you get into that. Though, I’m pretty sure it has to do with being “chummy” to the right people. Childishness. The bottom line is that there are too many levels of secrecy and too many and the wrong types of divisions to enable an effective feedback loop. I don’t know if this is true of all MVP groups, but it was with Silverlight and it has got worse with each successive Xaml platform. Now that Xaml is in Windows, I don’t expect anyone to be able to provide decent feedback.

Fruitlessness

Since things are so improperly organized, there are really only a few occasions where one can really provide good feedback on the product. Unfortunately, after three years as an MVP, I have to say that not a single bit of feedback I provided resulted in any sort of change to the product. With the Silverlight team..and almost always with the Blend team (when I could actually run one of them down), I would get some response like “yes, we’ll have to have a conversation about that.” And I’d be thinking…”isn’t that why I’m here at the MVP summit talking to you now?” But they never seamed to want to engage in a real discussion on *anything* that affected me, my project or my clients. I had this happen every year at the summit. I had even more outrageous things happen in email and at BUILD. On the insiders email list (when I finally got on it), I tried to start a conversation about Convention over Configuration and improvements to tooling that would help support those scenarios and generally make tool extensibility better. Somehow I managed to get into a private email thread of the Blend team where they could engage me on that. You know what they said when I tried to continue the conversation? They said “we don’t want to discuss that right now.” Ok…thanks. That made me really mad. Why am I an MVP again? But the real treat was at BUILD. I managed to track down two of the Blend PMs. I first talked to the PM in charge of the JavaScript Blend work. I told him about what I was building in JavaScript. He was really interested and wanted to follow up with me on what I was building and how it would work inside Blend. Then I took several steps to the right to talk to a Blend PM working on the Xaml side of things. I tried, once again, to discuss CoC. I know for a fact these guys either don’t understand it or don’t think it’s important in software at all. Well, they listened for a moment, then I asked about improving the tooling so I could have a plugin mechanism by which to improve that scenario for my customers. They were very not-helpful. I tried to bring up issues of developer productivity and better strategies for building applications. In a nutshell, the PM basically said to me “we don’t care about developers…they aren’t part of our use cases.” I was pretty enraged by that. See how the product team’s culture affects the effectiveness of the MVP program? My main point though is that nothing I ever said or did affected any product team’s work. Nothing. It was a waste of time and energy…and an emotional drain.

MVP Quality

Now I want to tread lightly here with how I say this….not all MVPs are created equal. I’m going to be vague here. I met an MVP once for Technology X. It turned out that she had never built anything with Technology X and wasn’t overly knowledgeable about it. She liked Technology X a lot though. Each day she would scan her RSS feeds and post about 8 - 10 links on Technology X. That’s why she had her MVP. It looks good on a review doesn’t it? I blogged 365 posts on Technology X this year!! Now, I’ve met some MVPs in various areas that were brilliant and obviously contributing a lot. But, I’ve met a fair share of MVPs who not only were not experts on the technology, but didn’t make half the contribution that other developers I knew did, who were never awarded MVPs. Not all MVPs are equal. If you are an employer, or looking for a speaker, expert, consultant…whatever; you cannot assume that just because that person has an MVP that they know what they are talking about. It’s sad, but this describes a noticeable number of MVPs.

One more word on MVP quality with respect to division along product team lines. You should never hire a highly product-specific MVP to help advise you on technology choices. I hope you realize the built-in problem with that. I know very few Technology X MVPs who would tell you not to use Technology X, even if there was a better, cheaper, faster way to build your solution. Be wary.

Open Source

I just want to say a little more about this. As I mentioned, there’s nothing about the MVP program that explicitly allows for recognition of open source work. It’s hard to get nominated for it and it’s even harder to renew with it. MVP leads who play a major roll in the renewal process may not be technical at all and even may not understand Open Source. Since I’ve mentioned how MVPs are linked to product groups, you might guess that the effectiveness of your MVP as an OSS developer is entirely dependent on that particular product group’s understanding of and interest in OSS. In a group related to ASP.NET or JavaScript, developers on the team are likely to have run open source projects themselves. In a group like Silverlight or WP7, they are likely to have never done such a thing…and not even have a clear idea of what is involved. I really came face to face with this when my non-renewed MVP…got renewed. Why? Well, it felt like a sort of “benefit of the doubt” renewal. Here’s the advice I was given from the renewal email, elided:

EDIT: I removed this quotation because a good friend of mine was honest enough to remind me that quoting a personal email is neither professional nor polite. I repent of that.

--Start Rant

What!? I released one of the most popular Xaml-related OSS project this year. I did multiple version releases, nuget packages, podcasts, documentation, forum support…the list goes on. What more do you want from me? And what should I do next year…because Caliburn.Micro is so popular, that in order for me to do something bigger for next year…I’d have to dump it entirely….completely abandoned it and build something totally different…something even more popular for Silverlight!? How could I do that to my community? That’s not even nice. No, in 2012, I’m going to continue to fix bugs, add features, add platform support and do awesome things with Caliburn.Micro. I love my own community and I’m going to continue to work hard and support them.

--End Rant

Now this kind of comment clearly expresses a deep lack of understanding for both the value of a project like Caliburn.Micro and the amount of time and resources it takes to maintain both the project and the community. If your OSS project is successful, it’s not just something you do one year and then move on to something else the next. In fact, building the first version of Caliburn.Micro was the easy part! It’s everything that’s happened afterwards and what is happening now that is hard work and will continue to be.

Unfortunately, Microsoft just doesn’t have a way of recognizing OSS developers who improve their platform. The MVP program doesn’t do this and the product teams may not either. In fact, Balmer has explicitly said he isn’t creating any policy around OSS…he’s totally dodging it entirely. This leaves the decision up to the individual teams…which sometimes goes well, but often times does not. That’s irresponsible leadership.

Career Affects

No one ever hired me as a consultant because I had an MVP. They hired me because of my open source work and my recognized expertise in UI architecture. The company I’m working for…I don’t even think they know what an MVP is. They hired me because they know *me* and know I can help them with their particular problem. I would say the personal career benefits of having an MVP are a wash except…

With Microsoft’s less than above the bar treatment and communication about Silverlight over the last year or so, you might imagine this could effect MVPs associated with the program. I’ve heard a lot of horrible stories in the last year. I didn’t have anything terribly bad happen to my business, but I was quite embarrassed recently. I was attending a .NET user group meeting, of which I am the president. Somehow I or someone else mentioned that I was a Silverlight MVP. I don’t remember the detail about how it came up, but I do remember what happened next. Someone laughed at me. Literally, I was made fun of because my MVP had the word Silverlight attached to it. Now, I’m just not willing to endure mockery for the sake of Silverlight, especially since I understood exactly why he was laughing at me. It has got to where being a “Silverlight” MVP is bad for my career.

My Happiness

Looking over the last three years, I’ve definitely been a less happy, more frustrated developer. I’m sure it’s linked to the sort of fake “value” being a Silverlight MVP gave me. Basically, they give you a couple of cheep gifts, then they pretend to listen to your feedback, while not actually doing anything. Year after year of that and you get really unhappy. It’s demoralizing. You start to realize that you really are a commodity. You are purchased by a product group and kept around as long as they perceive they need you…your feedback is allowed, but not effective. Again, it’s probably not the case for all MVPs, it depends on the groups. I just don’t need that in my life.

Conclusion

I’m saying goodbye to the MVP program even after I was re-offered the award for 2012. If you’ve read this far, you can probably see why I made that decision. I’m really positive about the future of Caliburn.Micro and hopeful regarding my JavaScript framework. I think 2012 is going to be a wonderful year. If someone seriously reforms the MVP program or if Microsoft decides to properly recognize and reward open source efforts, then, maybe I’ll let them give me an award. But for now, I don’t need to suffer any more. I’m free and I’m going to do great things.

Caliburn.Micro v1.2 RTW and Nuget Feature Packages!

Rob Eisenberg — Sat, 30 Jul 2011 17:40:00 GMT

Today, I’m pleased to announce the RTW of Caliburn.Micro v1.2. In this release we’ve had a number of bug fixes as well as a few incremental feature additions and refactorings. You can read the list of changes on the project site or get it as part of the download. Of course, v1.2 is now available through Nuget as well.

In addition to the standard release, I’m happy to announce something new we are doing with Caliburn.Micro: Feature Packages. Feature Packages allow developers a way pick and choose only the features they want from Caliburn.Micro and not have to take a dependency on other unused features of the framework. This allows for smaller Silverlight and WP7 applications as well as the ability to use some Caliburn.Micro features outside of the scope of a Xaml-application at all. Currently, we only have three feature packages available, but those will likely expand in the future.

Here’s a list of all the official Caliburn.Micro related packages on Nuget:

Caliburn.Micro – The full framework compiled into an assembly.

Caliburn.Micro.Container – The Caliburn.Micro inversion of control container (IoC), provided as a source code drop-in.

Caliburn.Micro.EventAggregator – The Caliburn.Micro event aggregator, provided as a source code drop-in.

Caliburn.Micro.INPC – The Caliburn.Micro INPC infrastructure: PropertyChangedBase, BindableCollection, Execute.OnUIThread and InDesignMode checking, provided as a source code drop-in.

Interestingly, by combing the container, event aggregator and INPC packages, you basically get something equivalent to MVVMLight Toolkit. So, if you are looking to get started with the absolute minimal needed to do MVVM, we have a solution for you. Naturally, it’s source-code-identical to Caliburn.Micro, which means you can upgrade from any combination of feature packages to the full framework without having to change a line of your code.

Happy app-building!

Caliburn.Micro Soup to Nuts Part 9–New WP7 Features

Rob Eisenberg — Thu, 09 Jun 2011 17:23:00 GMT

In version 1.0 we had pretty good support for building apps for WP7, but in v1.1 we’ve taken things up a notch. Let’s look at the same HelloWP7 sample that we did previously, but see how it’s been updated to take advantage of our improved tombstoning, launcher/chooser support and strongly typed navigation. You’ll also notice that the code is cleaner overall.

Bootstrapper

Here’s the cleaned up boostrapper in v1.1.

public class HelloWP7Bootstrapper : PhoneBootstrapper {
    PhoneContainer container;

    protected override void Configure() {
        container = new PhoneContainer(RootFrame);

        container.RegisterPhoneServices();
        container.PerRequest<MainPageViewModel>();
        container.PerRequest<PivotPageViewModel>();
        container.PerRequest<TabViewModel>();

        AddCustomConventions();
    }

    static void AddCustomConventions() {
        //ellided
    }

    protected override object GetInstance(Type service, string key) {
        return container.GetInstance(service, key);
    }

    protected override IEnumerable<object> GetAllInstances(Type service) {
        return container.GetAllInstances(service);
    }

    protected override void BuildUp(object instance) {
        container.BuildUp(instance);
    }
}

There are two things to notice here. First, we’ve removed all the manual Caliburn.Micro service configuration and pushed it into the SimpleContainer. That gives you one line of code to configure the framework if you are using the OOTB container. Speaking of which, we now provide the SimpleContainer officially in the Caliburn.Micro.Extensions assembly. That helps you get started faster. You can always plug your own in, of coarse. In addition to the simplified configuration, notice that the ViewModels for pages are no longer registered using a string key. For v1.1 our ViewModelLocator has been re-implemented to pull VMs from the container by Type rather than key. It now follows the exact same naming strategies as the ViewLocator (but in reverse) and even derives possible interface names so that it resolves VMs from the container correctly. This both improves the consistency of ViewModel location as well as makes the configuration simpler.

The boostrapper is added to your App.xaml as always:

<Application x:Class="Caliburn.Micro.HelloWP7.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:local="clr-namespace:Caliburn.Micro.HelloWP7">
    <Application.Resources>
        <local:HelloWP7Bootstrapper x:Key="bootstrapper" />
    </Application.Resources>
</Application>

Important Note About App.xaml.cs

If you create your WP7 application using a standard Visual Studio template, the generated App.xaml.cs file will have a lot of code in it. The purpose of this code is to set up the root frame for the application and make sure everything gets initialized properly. Of course, that's what the bootstrapper's job is too (and in fact it does a few things better than the out-of-the-box code in addition to configuring CM). So, you don't need both. When using CM's PhoneBootstrapper, be sure to clear out all the code from the App.xaml.cs file except for the call to InitializeComponent in the constructor.

INavigationService

Let’s review what CM’s INavigationService does for you. First, remember that WP7 enforces a View-First approach to UI at the platform level. Like it or not, the platform is going to create pages at will and the Frame control is going to conduct your application thusly. You don’t get to control that and there are no extensibility points, unlike the Silverlight version of the navigation framework. Rather than fight this, I’m going to recommend embracing the View-First approach for Pages in WP7, but maintaining a Model-First composition strategy for the sub-components of those pages and a Model-First approach to coding against the navigation system. In order to bridge this gap, I’ve enabled the INavigationService to hook into the native navigation frame’s functionality and augment it with the following behaviors:

When Navigating To a Page

Use the new ViewModelLocator to conventionally determine the Type of the VM that should be attached to the page being navigated to. Pull that VM by Type out of the container.
If a VM is found, use the ViewModelBinder to connect the Page to the located ViewModel.
Examine the Page’s QueryString. Look for properties on the VM that match the QueryString parameters and inject them, performing the necessary type coercion.
If the ViewModel implements the IActivate interface, call its Activate method.

When Navigating Away From a Page

Detect whether the associated ViewModel implements the IGuardClose interface.
If IGuardClose is implemented and the app is not being tombstoned or closed, invoke the CanClose method and use its result to optionally cancel page navigation.¹
If the ViewModel can close and implements the IDeactivate interface, call it’s Deactivate method. Always pass “false” to indicate that the VM should deactivate, but not necessarily close. This is because the phone may be deactivating, but not actually tombstoning or closing. There’s no way to know.

The behavior of the navigation service allows the correct VM to be hooked up to the page, allows that VM to be notified that it is being navigated to (IActivate), allows it to prevent navigation away from the current page (IGuardClose) and allows it to clean up after itself on navigation away, tombstoning or normal “closing” of the application (IDeactivate). All these interfaces (and a couple more) are implemented by the Screen class. If you prefer not to inherit from Screen, you can implement any of the interfaces individually of coarse. They provide a nice View-Model-Centric, testable and predictable way of responding to navigation without needing to wire up a ton of event handlers or write important application flow logic in the page’s code-behind.

These hooks into phone navigation enable a really smooth way of interacting with the phone’s navigation lifecycle. But now that we have an improved ViewModelLocator that matches exactly the ViewLocator and works on types, we can take things further. In v1.1 we’ve introduced support for strongly-typed navigation. Here’s what the new MainPageViewModel from the sample looks like using this new feature:

public class MainPageViewModel {
    readonly INavigationService navigationService;

    public MainPageViewModel(INavigationService navigationService) {
        this.navigationService = navigationService;
    }

    public void GotoPageTwo() {
        navigationService.UriFor<PivotPageViewModel>()
            .WithParam(x => x.NumberOfTabs, 5)
            .Navigate();
    }
}

This allows you to specify a ViewModel to navigate to along with the query string parameters. Since this all happens using generics and lambdas, you can never miss-type a page Uri or mess up your query strings….and refactoring will work beautifully.

For the sake of completeness, here’s the page that will be bound to MainPageViewModel:

<phone:PhoneApplicationPage x:Class="Caliburn.Micro.HelloWP7.MainPage"
                            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                            xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
                            xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
                            xmlns:cal="clr-namespace:Caliburn.Micro;assembly=Caliburn.Micro"
                            SupportedOrientations="Portrait"
                            Orientation="Portrait"
                            shell:SystemTray.IsVisible="True">
    <Grid Background="Transparent">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto" />
            <RowDefinition Height="*" />
        </Grid.RowDefinitions>
        <StackPanel Grid.Row="0"
                    Margin="24,24,0,12">
            <TextBlock Text="WP7 Caliburn.Micro"
                       Style='{StaticResource PhoneTextNormalStyle}' />
            <TextBlock Text='Main Page'
                       Margin='-3,-8,0,0'
                       Style='{StaticResource PhoneTextTitle1Style}' />
        </StackPanel>

        <Grid Grid.Row='1'>
            <Button x:Name='GotoPageTwo'
                    Content='Goto Page Two' />
        </Grid>
    </Grid>

    <phone:PhoneApplicationPage.ApplicationBar>
        <shell:ApplicationBar IsVisible='True'>
            <shell:ApplicationBar.Buttons>
                <cal:AppBarButton IconUri='ApplicationIcon.png'
                                  Text='Page Two'
                                  Message='GotoPageTwo' />
            </shell:ApplicationBar.Buttons>
        </shell:ApplicationBar>
    </phone:PhoneApplicationPage.ApplicationBar>
</phone:PhoneApplicationPage>

There’s really nothing new here in v1.1. But I just wanted to remind you that Caliburn.Micro supports Actions on the AppBar as long as you use CM’s AppBarButton and AppBarMenuItem :)

IPhoneService

The IPhoneService wraps the phone’s frame and provides access to important information and events. We had this service in v1.0 but we’ve expanded it in v1.1 to expose a better event model. Those familiar with WP7 know that the phone has a series of events that fire in different circumstances: Launching, Activated, Deactivated and Closing. Unfortunately, these events obscure whether the phone is actually resurrecting from a tombstoned state or simply continuing execution. The current SDK does not make it easy for the developer to actually determine this, so Caliburn.Micro does the heavy lifting for you and provides the following event model:

Launching - Occurs when a fresh instance of the application is launching.
Activated - Occurs when a previously paused/tombstoned app is resumed/resurrected.
Deactivated - Occurs when the application is being paused or tombstoned.
Closing - Occurs when the application is closing.
Continuing - Occurs when the app is continuing from a temporarily paused state.
Continued - Occurs after the app has continued from a temporarily paused state.
Resurrecting - Occurs when the app is "resurrecting" from a tombstoned state.
Resurrected - Occurs after the app has "resurrected" from a tombstoned state.

Using these new events, you can more intelligently make decisions about whether or not you need to restore data. In the forthcoming Mango release, the platform will provide us information on whether the app is continuing or resurrecting. However, developers working with Caliburn.Micro can have that information now and when Mango arrives, we’ll update our implementation to use the new bits. Your code won’t have to change.

Tombstoning

As you might imagine, our new tombstoning mechanism takes advantage of the new events so that it can more reliably and accurately save/restore important data. Let’s have a look at the PivotPageViewModel to see how it interacts with the tombstoning mechanism.

public class PivotPageViewModel : Conductor<IScreen>.Collection.OneActive {
    readonly Func<TabViewModel> createTab;

    public PivotPageViewModel(Func<TabViewModel> createTab) {
        this.createTab = createTab;
    }

    public int NumberOfTabs { get; set; }

    protected override void OnInitialize() {
        Enumerable.Range(1, NumberOfTabs).Apply(x => {
            var tab = createTab();
            tab.DisplayName = "Item " + x;
            Items.Add(tab);
        });

        ActivateItem(Items[0]);
    }
}

The PivotPageViewModel will receive the number of pivot items to create through it’s NumberOfTabs property, which is pushed in from the query string, as mentioned above. It will then add these items to the conductor and activate the first one. If you’re familiar with the Pivot and CM’s previous sample, you’ll notice that our PivotFix is gone. Pivot has a horrible bug that will crash your application if you try to set the SelectedItem or SelectedIndex to an item 3 or greater from either end of the pivot collection, while the Pivot itself is not visible. This makes it really hard to restore this control from a tombstoned state because you have to set the value at the exact right time. Previously we used a PivotFix hack to work around the control’s bug, but the new tombstoning mechanism is powerful and extensible enough to just make it work. You’ll notice that there are no attributes describing tombstoning behavior. They’ve been removed in favor of a poco model inspired by Fluent NHibhernate. If you would rather have the attributes, you can actually build them on top of the new system. The new system is also more reliable than previously and has a lot more options for storage. Let’s see the class that describes the tombstoning behavior for PivotPageViewModel:

public class PivotPageModelStorage : StorageHandler<PivotPageViewModel> {
    public override void Configure() {
        this.ActiveItemIndex()
            .InPhoneState()
            .RestoreAfterViewLoad();
    }
}

All you have to do to make a class participate in tombstoning is to inherit from StorageHandler<T>. The PhoneContainer will auto-register anything of this type in the assembly. Just override the Configure method and declare the tombstoning instructions. I’ve created some extension methods for common scenarios. Here’s what the above declaration states:

-Persist the Conductor’s ActiveItem’s index
-Store the index in PhoneState
-Restore the value after the associated view has been loaded.

Let’s look at the storage handler for the TabViewModel to see some more options:

public class TabViewModelStorage : StorageHandler<TabViewModel> {
    public override void Configure() {
        Id(x => x.DisplayName);

        Property(x => x.Text)
            .InPhoneState()
            .RestoreAfterActivation();
    }
}

Here we are specifying an Id because we actually need to persist multiple instances of the same VM. When we restore, we’ll need to know how to map the properties back. We’re also storing the data in PhoneState, but this time we’re not waiting for the view to load, but just waiting for the TabViewModel to be activated by its owning Conductor.

Out of the box, we also support storing data in AppSettings. For example, if you wanted to same tab to be selected *across application restarts* not just when tombstoned, you could define the PivotPageModelStorage like this:

public class PivotPageModelStorage : StorageHandler<PivotPageViewModel> {
    public override void Configure() {
        this.ActiveItemIndex()
            .InAppSettings()
            .RestoreAfterViewLoad();
    }
}

Pretty easy? All this works by collaborating with the IoC container and keying off of the new event model exposed by the IPhoneService. It’s pretty powerful and extensible. You can add your own storage mechanism or define your own restore timing. You can even implement IStorageHandler directly to write completely custom code on a class by class basis. You could easily add a version that inspected classes for custom attributes and built up the configuration, if you like the attribute model better. You can also store whole instances, not just their properties, and have them rehydrated properly and available for ctor injection.

Launchers and Choosers

Launchers and Choosers are painful to work with if you want to do MVVM. In v1.0 we provided a solution to this. I wasn’t happy with its implementation…it was unpredictable in certain scenarios. Once we established the new phone events, better IoC integration and new tombstoning mechanism, I realized I could build a better launcher/chooser system. Let’s take a look at the updated version of TabViewModel in order to see how it works:

public class TabViewModel : Screen, IHandle<TaskCompleted<PhoneNumberResult>> {
    string text;
    readonly IEventAggregator events;

    public TabViewModel(IEventAggregator events) {
        this.events = events;
    }

    public string Text {
        get { return text; }
        set {
            text = value;
            NotifyOfPropertyChange(() => Text);
        }
    }

    public void Choose() {
        events.RequestTask<PhoneNumberChooserTask>();
    }

    public void Handle(TaskCompleted<PhoneNumberResult> message) {
        MessageBox.Show("The result was " + message.Result.TaskResult, DisplayName, MessageBoxButton.OK);
    }

    protected override void OnActivate() {
        events.Subscribe(this);
        base.OnActivate();
    }

    protected override void OnDeactivate(bool close) {
        events.Unsubscribe(this);
        base.OnDeactivate(close);
    }
}

The most significant architectural change I made was to re-implement the launcher/chooser mechanism to work on top of the IEventAggregator. Take a look at the Choose method. The RequestTask method is just an extension method of the IEventAggregator that publishes a special event that the framework is subscribed to. The framework then starts the task. When it’s completed, the framework publishes an event TaskCompleted<T> where T is the result the the chooser returns. You can register for this in the same VM that published the chooser event or in an entirely different one if you like. In the case of our sample, we have 5 TabViewModels that can launch the same chooser. That’s probably not normal, but you can handle this situation in three ways. In our case, the VMs are in a Conductor, and only one of them can be active at a time, so we just Subscribe/Unsubscribe based on the Screen lifecycle so that only the active VM will receive the result. This is a version of the Latch pattern. The second way to handle this is through the event state. When you call the RequestTask method you can pass a state object which you can use for identification purposes later. Yes, this will be present even if the chooser causes a tombstone event. The final way is to have a single object that registers for the completed event, decoupling the launching from the completion. Thus multiple VM could launch the same chooser, but only one class would handle the result.

IWindowManager

The IWindowManager was actually in v1.0, as a last minute addition. It’s a really easy way to show native-looking, custom message boxes or modal dialogs. You can also use it to show popups. We’ll talk more about the window manager, on all platforms, in the next post.

Referenced Samples

Caliburn.Micro.HelloWP7

Footnotes

Even though the IGuardClose interface was designed to handle async scenarios, you must use it synchronously in WP7. This is due to a flaw in the design of Silverlight Navigation Framework which doesn’t account for async shutdown scenarios.

Caliburn.Micro v1.1 RTW

Rob Eisenberg — Wed, 01 Jun 2011 17:08:00 GMT

Today I’m happy to announce the release of Caliburn.Micro v1.1. You can get it on our project site or by using Nuget.

We’ve had a number of bug fixes, general improvements and a few new features added. Here’s the highlights:

For WP7

A new Tombstoning API based on ideas from Fluent NHibernate
A new Launcher/Chooser API
Strongly typed Navigation
SimpleContainer included
The full phone lifecycle is made easy to work with
- ie. we figure out whether your app is actually Resurrecting of just Continuing and tell you

For WPF

Support for the Client Profile
Better support for WinForms integration

All Platforms

A powerful new RegEx-based ViewLocator and ViewModelLocator
- Special thanks to cb55555
Polymorphic subscriptions and custom thread marshaling for the EventAggregator
Numerous bug fixes

You can get the complete list of changes in the release notes. Enjoy!

Caliburn.Micro Soup to Nuts Part 8–The EventAggregator

Rob Eisenberg — Mon, 30 May 2011 16:06:00 GMT

In Caliburn.Micro we have a series of supporting services for building presentation tiers. Among them is the EventAggregator, a service which supports in-process publish/subscribe. There are various implementations of this pattern available in other frameworks, but I think you’ll find that Caliburn.Micro’s implementation sports the cleanest API and the richest set of features. Let’s start by having a look at the IEventAggregator interface:

public interface IEventAggregator {
    void Subscribe(object instance);
    void Unsubscribe(object instance);
    void Publish(object message, Action<System.Action> marshal = null);
}

Below we’ll dig into how the default implementation of this interface (EventAggregator) works.

Subscribe

With the Caliburn.Micro EventAggregator we don’t actually leverage events under the covers. Events are prone to memory leaks and it’s extremely difficult to avoid them or to write a flawless weak event implementation. Instead, we allow you to subscribe an object instance. Under the covers we hold a weak reference. That makes things quite simple. But, how do we know what messages to subscribe to and what methods to use as callbacks? Well, we follow a declarative model by requiring subscribers to implement an interface which states which message they are interested in and provides the callback method. The interface looks like this:

public interface IHandle<TMessage> : IHandle {
    void Handle(TMessage message);
}

And it’s used like this:

public class MyViewModel : IHandle<SomeMessage>{
    public void Handle(SomeMessage message){
        //do something with the message
    }
}

Because we use an interface, you can implement IHandle<T> as many times as you want on a given class. This approach keeps things declarative, strongly-typed and free from memory leaks. You can even use explicit interface implementations to hide the handlers if you desire.

Unsubscribe

There’s not too much to say about this. When you call this method, we search our list of subscribers and remove the specified instance. You may be wondering why this is even necessary if subscribers are held with weak references to begin with. It turns out that there are a number of cases where you want to control the subscription’s activation. Imagine you have a Screen Collection and only the Active Screen is supposed to receive events. In this case, you’d want to subscribe when the screen was activated and unsubscribe when it was deactivated. See the v1.1 HelloWP7 sample for an example of how this works with the new Launcher/Choosers mechanism.

Publish

As you might expect, calling Publish actually sends a message to all it’s subscribers. Here’s how you might use it:

public class MyOtherViewModel{
    IEventAggregator events;

    public MyOtherViewModel(IEventAggregator events){
        this.events = events;
    }

    public void DoSomething(){
        events.Publish(new SomeMessage{
            SomeNumber = 5,
            SomeString = "Blah..."
        });
    }
}

Here, we get an instance of the IEventAggregator service via constructor injection. Then, when the DoSomething method is invoked, we publish the SomeMessage message along with its data. Assuming MyViewMododel above had subscribed itself to the aggregator, it would then have it's Handle method called with the SomeMessage instance. So how does this work? We do this by iterating our list of subscribers to see if any of them implement IHandle<T> where T is assignable from the message that is being published. All the matches that are found then have their handlers called on the UI thread.

Marker Interface

IHandle<T> inherits from a marker interface IHandle. This allows the use of casting to determine if an object instance subscribes to any events. This enables simple auto-subscribing if you integrate with an IoC container. Most IoC containers (including the SimpleContainer) provide a hook for being called when a new instance is created. Simply wire for your container’s callback, inspect the instance being created to see if it implement IHandle, and if it does, call Subscribe on the event aggregator. Just remember, you probably don’t want to use this technique if you need conditional subscription as I described above.

New in v1.1

Custom Publication Marshaling

Those familiar with v1.0 may notice a few interesting differences in the interface. Among them is the optional “marshal” parameter of the Publish method. By default messages will be automatically published synchronously on the UI thread. However, this is not always desirable. The optional parameter allows you to provide an action which marshals the publication to a custom thread. By using this extension point, a developer could easily write extension methods such as: PublishOnCurrentThread, PublishOnBackgroundThread or PublishOnUIThreadAsync.

Polymorphic Event Subscriptions

Above I stated that during publication we check for handlers “where T is assignable from the message being published.” We do this with reflection in v1.1 rather than casting (v1.0) in order to enable polymorphic event subscriptions. Let me explain what this means by providing an example:

public interface ICustomerMessage{
    //implementation here
}

public interface ICustomerCreated : ICustomerMessage{
    //implementation here
}

public interface ICustomerDeleted : ICustomerMessage{
    //implementation here
}

public class AnUnrelatedMessage{
    //implementation here
}

public class MyObserver :
    IHandle<object>, 
    IHandle<ICustomerMessage>, 
    IHandle<ICustomerDeleted> {
    
    public void Handle(object message){
        //will handle every message in the application
    }

    public void Handle(ICustomerMessage message){
        //handles ICustomerCreated and ICustomerDeleted
    }

    public void Handle(ICustomerDeleted message){
        //handles only ICustomerDeleted
    }
}

This turns out to be very powerful, especially when you need to evolve a system over time.

You can see the EventAggregator in action and step through some code by opening up the HelloEventAggregator sample under source. This sample creates a ShellViewModel with two child view models. Each child publishes a message that the other child is subscribed to. The ShellViewModel is subscribed to all messages via the polymorphic features of the aggregator. Here’s a screen shot after some messages have been published:

Caliburn.Micro RTW, NuGet Support, Mix Open Source Festival!

Rob Eisenberg — Mon, 11 Apr 2011 22:32:00 GMT

Today, I’m proud to announce the v1.0 RTW of Caliburn.Micro for WPF, Silverlight and Window Phone 7! The idea was born last year at Mix10 after my Build Your Own MVVM Framework talk received overwhelmingly positive feedback. I want to give a big thanks to the developers who put their time into this. Thanks Christopher, Marco and Ryan! Also, I want to say thanks to the community. It’s been exciting to see how fast a rich community of developers has grown up around this project and to see how many people are speaking about Caliburn.Micro at their local user groups, code camps and even major conferences such as Codestock and teched.

Along with his release comes a number of bug fixes and even a few new features, such as the new WindowManager for WP7 which provides View-Model-First modal dialogs with animations designed after the native MessageBox. Be sure to thank Marco for that. After you thank Marco, you need to give props to Ryan who spearheaded the NuGet package development. As of right now, Caliburn.Micro can be installed quite easily from Visual Studio. If you have NuGet 1.2 or later installed, from the Package Manager Console, just type:

Install-Package Caliburn.Micro

Then, follow the few steps in the web page that pops up so that you get your bootstrapper added to App.xaml correctly, run the app and enjoy sweet Caliburn.Micro bliss :)

The first release of Caliburn.Micro comes on the day of the first Mix Open Source Festival. I’ll be there tonight representing the project and would love to meet you if you are present. Please come by, say hello, tell me about the cool stuff you are building…and vote for the project of course! If you can’t make the festival, but will be at Mix, find me. I’m the short one.

The Future of Blue Spire

Rob Eisenberg — Thu, 07 Apr 2011 18:44:00 GMT

Recently my good friend and business partner, Christopher Bennage, made a decision to move his family to Redmond and take a job with Microsoft’s P&P team. A few people have been asking me what that means for Blue Spire. In short, I’m going to be focusing the company on what I know and do best: UI Architecture and Engineering. To that end there are three big areas I’m working on in the near future:

Caliburn.Micro

Caliburn.Micro is an opinionated framework designed to ease the authoring of maintainable presentation tiers on Xaml-based platforms. There are a lot of apps being built with it and a great support community too. You will see the RTW release along with NuGet support *very* soon. After that, it’s on to work on the next version. I’ve got quite a few improvements planned now, not to mention support for Silverlight 5. In the next few months I’ll be initiating a Caliburn.Micro sponsorship program and possibly some other goodies…

Master Classes

There’s a lot of talk in the .NET community about MVVM. There’s a lot of bad examples on the web of how to do it. Furthermore, the drone on the subject has unfortunately steered many developers away from an honest and deep exploration of UI engineering in general. This may come as a shock to many, but MVVM is not the only way and not always the right way to solve a problem. I’m working on putting together a 3 – 5 day master class that focuses strictly on UI engineering. At first, I’ll be traveling to various cities around the U.S. delivering this course. I have plans to visit Europe in the future as well. The goal is to take experienced Xaml-developers and infuse a very deep understanding of object-oriented programming as it applies to the presentation tier. Sure we’ll talk about MVVM, we’ll work with Caliburn.Micro, etc. but we’ll be talking and working through a lot more things you’ll need to have mastery of to work effectively in this space. In addition to the standard courses, I’ll also be putting together a package geared towards companies that wish to invest in this type of training for their developers internally.

Consulting

As always, I’m available as a consultant. I won’t lie. It’s not cheap to hire me to work on your presentation tier, but all my clients will tell you that they get tremendous value for their money. In addition to traditional consulting, I’m offering two other special services. The first is code reviews. I’ve found that having an expert spend a few hours reviewing your code can make a tremendous difference. It can be anything from “Our application works fine, but it’s been difficult adding new features, how can we improve our design?” to “We have a WPF application and were wondering if/how difficult it would be to port it to Silverlight?” to “We have a complex feature and we need some advice on how we should proceed.” Maybe you would say “We have a brownfield WPF application with no separated presentation. We’re looking at improving things by using Caliburn.Micro. Can you help us gracefully accomplish that transition?” Basically, we time box some hours, I dive into your code and I come back out with some answers to help you on your way. Finally, in addition to the Master Classes above, I’ll be delivering week-long development Bootcamps for companies that want an intense combination of training and focused development on one of their products. Basically, I’ll be on site, developing along with your team, helping in key architectural decisions, teaching UI engineering and helping you to leverage Caliburn.Micro along the way. It might be a brownfeld application that needs refactoring because of maintenance issues or it might be a completely new project that your team wants a really strong start with.

Durandal

I said three things didn’t I? Well, I can’t really help mentioning the Javascript RIA platform I’m working on. If you like the WPF/Silverlight development style and especially if you like Caliburn.Micro…this is going to blow your mind. I’m very excited about it. If you’re going to be at Mix this year, come find me and maybe I’ll give you a little sneak peak :) As you might imagine, when it arrives, I’m going to provide a version of my UI Engineering master class geared around it as well as the bootcamps and consulting services. It’s a bit down the road, but I’m really looking forward to being able to share more with you about it.

Two Caliburn Releases in One Day!

Rob Eisenberg — Mon, 21 Feb 2011 19:18:00 GMT

Today, I'm happy to make available the Release Candidates for both Caliburn 2.0 and Caliburn.Micro 1.0! The docs for both have been updated significantly, though they will continue to evolve over the coming months. Get em' while they're hot!

Caliburn.Micro Soup to Nuts Part 7 - All About Conventions

Rob Eisenberg — Thu, 16 Dec 2010 20:49:00 GMT

One of the main features of Caliburn.Micro is manifest in its ability to remove the need for boiler plate code by acting on a series of conventions. Some people love conventions and some hate them. That’s why CM’s conventions are fully customizable and can even be turned off completely if not desired. If you are going to use conventions, and since they are ON by default, it’s good to know what those conventions are and how they work. That’s the subject of this article.

View Resolution (ViewModel-First)

Basics

The first convention you are likely to encounter when using CM is related to view resolution. This convention affects any ViewModel-First areas of your application. In ViewModel-First, we have an existing ViewModel that we need to render to the screen. To do this, CM uses a simple naming pattern to find a UserControl¹ that it should bind to the ViewModel and display. So, what is that pattern? Let’s just take a look at ViewLocator.LocateForModelType to find out:

public static Func<Type, DependencyObject, object, UIElement> LocateForModelType = (modelType, displayLocation, context) =>{
    var viewTypeName = modelType.FullName.Replace("Model", string.Empty);
    if(context != null)
    {
        viewTypeName = viewTypeName.Remove(viewTypeName.Length - 4, 4);
        viewTypeName = viewTypeName + "." + context;
    }

    var viewType = (from assmebly in AssemblySource.Instance
                    from type in assmebly.GetExportedTypes()
                    where type.FullName == viewTypeName
                    select type).FirstOrDefault();

    return viewType == null
        ? new TextBlock { Text = string.Format("{0} not found.", viewTypeName) }
        : GetOrCreateViewType(viewType);
};

Let’s ignore the “context” variable at first. To derive the view, we make an assumption that you are using the text “ViewModel” in the naming of your VMs, so we just change that to “View” everywhere that we find it by removing the word “Model”. This has the effect of changing both type names and namespaces. So ViewModels.CustomerViewModel would become Views.CustomerView. Or if you are organizing your application by feature: CustomerManagement.CustomerViewModel becomes CustomerManagement.CustomerView. Hopefully, that’s pretty straight forward. Once we have the name, we then search for types with that name. We search any assembly you have exposed to CM as searchable via AssemblySource.Instance.² If we find the type, we create an instance (or get one from the IoC container if it’s registered) and return it to the caller. If we don’t find the type, we generate a view with an appropriate “not found” message.

Now, back to that “context” value. This is how CM supports multiple Views over the same ViewModel. If a context (typically a string or an enum) is provided, we do a further transformation of the name, based on that value. This transformation effectively assumes you have a folder (namespace) for the different views by removing the word “View” from the end and appending the context instead. So, given a context of “Master” our ViewModels.CustomerViewModel would become Views.Customer.Master.

Other Things To Know

Besides instantiation of your View, GetOrCreateViewType will call InitializeComponent on your View (if it exists). This means that for Views created by the ViewLocator, you don’t have to have code-behinds at all. You can delete them if that makes you happy :) You should also know that ViewLocator.LocateForModelType is never called directly. It is always called indirectly through ViewLocator.LocateForModel. LocateForModel takes an instance of your ViewModel and returns an instance of your View. One of the functions of LocateForModel is to inspect your ViewModel to see if it implements IViewAware. If so, it will call it’s GetView method to see if you have a cached view or if you are handling View creation explicitly. If not, then it passes your ViewModel’s type to LocateForModelType.

Customization

The out-of-the-box convention is pretty simple and based on a number of patterns we’ve used and seen others use in the real world. However, by no means are you limited to these simple patterns. You’ll notice that all the methods discussed above are implemented as Funcs rather than actual methods. This means that you can customize them by simply replacing them with your own implementations. If you just want to add to the existing behavior, simply store the existing Func in a variable, create a new Func that calls the old and and assign the new Func to ViewLocator.LocateForModelType.³

Framework Usage

There are three places that the framework uses the ViewLocator; three places where you can expect the view location conventions to be applied. The first place is in Bootstrapper<T>. Here, your root ViewModel is passed to the locator in order to determine how your application’s shell should be rendered. In Silverlight this results in the setting or your RootVisual. In WPF, this creates your MainWindow. In fact, in WPF the bootstrapper delegates this to the WindowManager, which brings me to… The second place the ViewLocator is used is the WindowManager, which calls it to determine how any dialog ViewModels should be rendered. The third and final place that leverages these conventions is the View.Model attached property. Whenever you do ViewModel-First composition rendering by using the View.Model attached property on a UIElement, the locator is invoked to see how that composed ViewModel should be rendered at that location in the UI. You can use the View.Model attached property explicitly in your UI (optionally combining it with the View.Context attached property for contextual rendering), or it can be added by convention, thus causing conventional composition of views to occur. See the section below on property binding conventions.

ViewModel Resolution (View-First)

Basics

Though Caliburn.Micro prefers ViewModel-First development, there are times when you may want to take a View-First approach, especially when working with WP7. In the case where you start with a view, you will likely then need to resolve a ViewModel. We use a similar naming convention for this scenario as we did with view location. Let’s take a look at ViewModelLocator.LocateForViewType:

public static Func<Type, object> LocateForViewType = viewType =>{
    var typeName = viewType.FullName;

    if(!typeName.EndsWith("View"))
        typeName += "View";

    var viewModelName = typeName.Replace("View", "ViewModel");
    var key = viewModelName.Substring(viewModelName.LastIndexOf(".") + 1);

    return IoC.GetInstance(null, key);
};

While with View location we change instances of “ViewModel” to “View”, with ViewModel location we change “View” to “ViewModel.” The other interesting difference is in how we get the instance of the ViewModel itself. Because your ViewModels may be registered by an interface or a concrete class, we don’t pull them from the container by type. Instead we pull them by key, using just the derived name, minus all the namespace stuff.

Other Things To Know

ViewModelLocator.LocateForViewType is actually never called directly by the framework. It’s called internally by ViewModelLocator.LocateForView. LocateForView first checks your View instance’s DataContext to see if you’ve previous cached or custom created your ViewModel. If the DataContext is null, only then will it call into LocateForViewType. A final thing to note is that automatic InitializeComponent calls are not supported by view first, by its nature.

Customization

You may not be happy with the way that LocateForViewType retrieves your ViewModel from the IoC container by key. No problem. Simply replace the Func with your own implementation. As you can see, it doesn’t really require that much code to map one thing to another.

Framework Usage

The ViewModelLocator is only used by the WP7 version of the framework. It’s used by the FrameAdapter which insures that every time you navigate to a page, it is supplied with the correct ViewModel. It could be easily adapted for use by the Silverlight Navigation Framework if desired.

ViewModelBinder

Basics

When we bind together your View and ViewModel, regardless of whether you use a ViewModel-First or a View-First approach, the ViewModelBinder.Bind method is called. This method sets the Action.Target of the View to the ViewModel and correspondingly sets the DataContext to the same value.⁴ It also checks to see if your ViewModel implements IViewAware, and if so, passes the View to your ViewModel. This allows for a more SupervisingController style design, if that fits your scenario better. The final important thing the ViewModelBinder does is determine if it needs to create any conventional property bindings or actions. To do this, it searches the UI for a list of element candidates for bindings/actions and compares that against the properties and methods of your ViewModel. When a match is found, it creates the binding or the action on your behalf.

Other Things To Know

On the WP7 platform, if the View you are binding is a PhoneApplicationPage, this service is responsible for wiring up actions to the ApplicationBar’s Buttons and Menus. See the WP7 specific docs for more information on that.

Customization

Should you decide that you don’t like the behavior of the ViewModelBinder (more details below), it follows the same patterns as the above framework services. It has several Funcs you can replace with your own implementations, such as Bind, BindActions and BindProperties. Probably the most important aspect of customization though, is the ability to turn off the binder’s convention features. To do this, set ViewModelBinder.ApplyConventionsByDefault to false. If you want to enable it on a view-by-view basis, you can set the View.ApplyConventions attached property to true on your View. This attached property works both ways. So, if you have conventions on by default, but need to turn them off on a view-by-view basis, you just set this property to false.

Framework Usage

The ViewModelBinder is used in three places inside of Caliburn.Micro. The first place is inside the implementation of the View.Model attached property. This property takes your ViewModel, locates a view using the ViewLocator and then passes both of them along to the ViewModelBinder. After binding is complete, the View is injected inside the element on which the property is defined. That’s the ViewModel-First usage pattern. The second place that uses the ViewModelBinder is inside the implementation of the Bind.Model attached property. This property takes a ViewModel and passes it along with the element on which the property is defined to the ViewModelBinder. In other words, this is View-First, since you have already instantiated the View inline in your Xaml and are then just invoking the binding against a ViewModel. The final place that the ViewModelBinder is used is in the WP7 version of the framework. Inside of the FrameAdapter, when a page is navigated to, the ViewModelLocator is first used to obtain the ViewModel for that page. Then, the ViewModelBinder is uses to connect the ViewModel to the page.

Element Location

Basics

Now that you understand the basic role of the ViewModelBinder and where it is used by the framework, I want to dig into the details of how it applies conventions. As mentioned above, the ViewModelBinder “searches the UI for a list of element candidates for bindings/actions and compares that against the properties and methods of your ViewModel.” The first step in understanding how this works is knowing how the framework determines which elements in your UI may be candidates for conventions. It does this by using a func on the static ExtensionMethods class called GetNamedElementsInScope.⁵ Basically this method does two things. First, it identifies a scope to search for elements in. This means it walks the tree until it finds a suitable root node, such as a Window, UserControl or element without a parent (indicating that we are inside a DataTemplate). Once it defines the “outer” borders of the scope, it begins it’s second task: locating all elements in that scope that have names. The search is careful to respect an “inner” scope boundary by not traversing inside of child user controls. The elements that are returned by this function are then used by the ViewModelBinder to apply conventions.

Other Things To Know

There are a few limitations to what the GetNamedElementsInScope method can accomplish out-of-the-box. It can only search the visual tree, ContentControl.Content and ItemsControl.Items. In WPF, it also searches HeaderContentControl.Header and HeaderedItemsControl.Header. What this means is that things like ContextMenus, Tooltips or anything else that isn’t in the visual tree or one of these special locations won’t get found when trying to apply conventions.

Customization

You may not encounter issues related to the above limitations of element location. But if you do, you can easily replace the default implementation with your own. Here’s an interesting technique you might choose to use: If the view is a UserControl or Window, instead of walking the tree for elements, use some reflection to discover all private fields that inherit from FrameworkElement. We know that when Xaml files are compiled, a private field is created for everything with an x:Name. Use this to your advantage. You will have to fall back to the existing implementation for DataTemplate UI though. I don’t provide this implementation out-of-the-box, because it is not guaranteed to succeed in Silverlight. The reason is due to the fact that Silverlight doesn’t allow you to get the value of a private field unless the calling code is the code that defines the field. However, if all of your views are defined in a single assembly, you can easily make the modification I just described by creating your new implementation in the same assembly as the views. Furthermore, if you have a multi-assembly project, you could write a little bit of plumbing code that would allow the GetNamedElementsInScope Func to find the assembly-specific implementation which could actually perform the reflection.⁶

Framework Usage

I’ve already mentioned that element location occurs when the ViewModelBinder attempts to bind properties or methods by convention. But, there is a second place that uses this functionality: the Parser. Whenever you use Message.Attach and your action contains parameters, the message parser has to find the elements that you are using as parameter inputs. It would seem that we could just do a simple FindName, but FindName is case-sensitive. As a result, we have to use our custom implementation which does a case-insensitive search. This ensures that the same semantics for binding are used in both places.

Action Matching

Basics

The next thing the ViewModelBinder does after locating the elements for convention bindings is inspect them for matches to methods on the ViewModel. It does this by using a bit of reflection to get the public methods of the ViewModel. It then loops over them looking for a case-insensitive name match with an element. If a match is found, and there aren’t any pre-existing Interaction.Triggers on the element, an action is attached. The check for pre-existing triggers is used to prevent the convention system from creating duplicate actions to what the developer may have explicitly declared in the markup. To be on the safe side, if you have declared any triggers on the matched element, it is skipped.

Other Things To Know

The conventional actions are created by setting the Message.Attach attached property on the element. Let’s look at how that is built up:

var message = method.Name;
var parameters = method.GetParameters();

if(parameters.Length > 0)
{
    message += "(";

    foreach(var parameter in parameters)
    {
        var paramName = parameter.Name;
        var specialValue = "$" + paramName.ToLower();

        if(MessageBinder.SpecialValues.Contains(specialValue))
            paramName = specialValue;

        message += paramName + ",";
    }

    message = message.Remove(message.Length - 1, 1);
    message += ")";
}

Log.Info("Added convention action for {0} as {1}.", method.Name, message);
Message.SetAttach(foundControl, message);

As you can see, we build a string representing the message. This string contains only the action part of the message; no event is declared. You can also see that it loops through the parameters of the method so that they are included in the action. If the parameter name is the same as a special parameter value, we make sure to append the “$” to it so that it will be recognized correctly by the Parser and later by the MessageBinder when the action is invoked.

When the Message.Attach property is set, the Parser immediately kicks in to convert the string message into some sort of TriggerBase with an associated ActionMessage. Because we don’t declare an event as part of the message, the Parser looks up the default Trigger for the type of element that the message is being attached to. For example, if the message was being attached to a Button, then we would get an EventTrigger with it’s Event set to Click. This information is configured through the ConventionManager with reasonable defaults out-of-the-box. See the sections on ConventionManager and ElementConventions below for more information on that. The ElementConvention is used to create the Trigger and then the parser converts the action information into an ActionMessage. The two are connected together and then added to the Interaction.Triggers collection of the element.

Customization

ViewModelBinder.BindActions is a Func and thus can be entirely replaced if desired. Adding to or changing the ElementConventions via the ConventionManager will also effect how actions are put together. More on that below.

Framework Usage

BindActions is used exclusively by the ViewModelBinder.

Property Matching

Basics

Once action binding is complete, we move on to property binding. It follows a similar process by looping through the named elements and looking for case-insensitive name matches on properties. Once a match is found, we then get the ElementConventions from the ConventionManager so we can determine just how databinding on that element should occur. The ElementConvention defines an ApplyBinding Func that takes the view model type, property path, property info, element instance, and the convention itself. This Func is responsible for creating the binding on the element using all the contextual information provided. The neat thing is that we can have custom binding behaviors for each element if we want. CM defines a basic implementation of ApplyBinding for most elements, which lives on the ConventionManager. It’s called SetBinding and looks like this:

public static Func<Type, string, PropertyInfo, FrameworkElement, ElementConvention, bool> SetBinding =
    (viewModelType, path, property, element, convention) => {
        var bindableProperty = convention.GetBindableProperty(element);
        if(HasBinding(element, bindableProperty))
            return false;

        var binding = new Binding(path);

        ApplyBindingMode(binding, property);
        ApplyValueConverter(binding, bindableProperty, property);
        ApplyStringFormat(binding, convention, property);
        ApplyValidation(binding, viewModelType, property);
        ApplyUpdateSourceTrigger(bindableProperty, element, binding);

        BindingOperations.SetBinding(element, bindableProperty, binding);

        return true;
    };

The first thing this method does is get the dependency property that should be bound by calling GetBindableProperty on the ElementConvention. Next we check to see if there is already a binding set for that property. If there is, we don’t want to overwrite it. The developer is probably doing something special here, so we return false indicating that a binding has not been added. Assuming no binding exists, this method then basically delegates to other methods on the ConventionManager for the details of binding application. Hopefully that part makes sense. Once the binding is fully constructed we add it to the element and return true indicating that the convention was applied.

There’s another important aspect to property matching that I haven’t yet mentioned. We can match on deep property paths by convention as well. So, let’s say that you have a Customer property on your ViewModel that has a FirstName property you want to bind a Textbox to. Simply give the TextBox an x:Name of “Customer_FirstName” The ViewModelBinder will do all the work to make sure that that is a valid property and will pass the correct view model type, property info and property path along to the ElementConvention’s ApplyBinding func.

Other Things To Know

I mentioned above that “CM defines a basic implementation of ApplyBinding for most elements.” It also defines several custom implementations of the ApplyBinding Func for elements that are typically associated with specific usage patterns or composition. For WPF and Silverlight, there are custom binding behaviors for ItemsControl and Selector. In addition to binding the ItemsSource on an ItemsControl, the ApplyBinding func also inspects the ItemTemplate, DisplayMemberPath and ItemTemplateSelector (WPF) properties. If none of these are set, then the framework knows that since you haven’t specified a renderer for the items, it should add one conventionally.⁷ So, we set the ItemTemplate to a default DataTemplate. Here’s what it looks like:

<DataTemplate xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
              xmlns:cal="clr-namespace:Caliburn.Micro;assembly=Caliburn.Micro">
    <ContentControl cal:View.Model="{Binding}" 
                    VerticalContentAlignment="Stretch"
                    HorizontalContentAlignment="Stretch" />
</DataTemplate>

Since this template creates a ContentControl with a View.Model attached property, we create the possibility of rich composition for ItemsControls. So, whatever the Item is, the View.Model attached property allows us to invoke the ViewModel-First workflow: locate the view for the item, pass the item and the view to the ViewModelBinder (which in turn sets it’s own conventions, possibly invoking more composition) and then take the view and inject it into the ContentControl. Selectors have the same behavior as ItemsControls, but with an additional convention around the SelectedItem property. Let’s say that your Selector is called Items. We follow the above conventions first by binding ItemsSource to Items and detecting whether or not we need to add a default DataTemplate. Then, we check to see if the SelectedItem property has been bound. If not, we look for three candidate properties on the ViewModel that could be bound to SelectedItem: ActiveItem, SelectedItem and CurrentItem. If we find one of these, we add the binding. So, the pattern here is that we first call ConventionManager.Singularize on the collection property’s name. In this case “Items” becomes “Item” Then we call ConventionManager.DerivePotentialSelectionNames which prepends “Active” “Selected” and “Current” to “Item” to make the three candidates above. Then, we create a binding if we find one of these on the ViewModel. For WPF, we have a special ApplyBinding behavior for the TabControl.⁸ It takes on all the conventions of Selector (setting it’s ContentTemplate instead of ItemTemplate to the DefaultDataTemplate), plus an additional convention for the tab header’s content. If the TabControl’s DisplayMemberPath is not set and the ViewModel implements IHaveDisplayName, then we set it’s ItemTemplate to the DefaultHeaderTemplate, which looks like this:

<DataTemplate xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
    <TextBlock Text="{Binding DisplayName, Mode=TwoWay}" />
</DataTemplate>

So, for a named WPF TabControl we can conventionally bind in the list of tabs (ItemsSource), the tab item’s name (ItemTemplate), the content for each tab (ContentTemplate) and keep the selected tab synchronized with the model (SelectedItem). That’s not bad for one line of Xaml like this:

<TabControl x:Name="Items" />

In addition to the special cases listed above, we have one more that is important: ContentControl. In this case, we don’t supply a custom ApplyBinding Func, but we do supply a custom GetBindableProperty Func. For ContentControl, when we go to determine which property to bind to, we inspect the ContentTemplate and ContentTemplateSelector (WPF). If they are both null, you haven’t specified a renderer for your model. Therefore, we assume that you want to use the ViewModel-First workflow. We implement this by having the GetBindableProperty Func return the View.Model attached property as the property to be bound. In all other cases ContentControl would be bound on the Content property. By selecting the View.Model property in the absence of a ContentTemplate, we enable rich composition.

I hope you will find that these special cases make sense when you think about them. As always, if you don’t like them, you can change them…

Customization

As you might imagine, the BindProperties functionality is completely customizable by replacing the Func on the ViewModelBinder. For example, if you like the idea of Action conventions but not Property conventions, you could just replace this Func with one that doesn’t do anything. However, it’s likely that you will want more fine grained control. Fortunately, nearly every aspect of the ConventionManager or of a particular ElementConvention is customizable. More details about the ConventionManager are below.

One of the common ways you will configure conventions is by adding new conventions to the system. Most commonly this will be in adding the Silverlight toolkit controls or the WP7 toolkit controls. Here’s an example of how you would set up an advanced convention for the WP7 Pivot control which would make it work like the WPF TabControl:

ConventionManager.AddElementConvention<Pivot>(Pivot.ItemsSourceProperty, "SelectedItem", "SelectionChanged").ApplyBinding =
    (viewModelType, path, property, element, convention) => {
        ConventionManager
            .GetElementConvention(typeof(ItemsControl))
            .ApplyBinding(viewModelType, path, property, element, convention);
        ConventionManager
            .ConfigureSelectedItem(element, Pivot.SelectedItemProperty, viewModelType, path);
        ConventionManager
            .ApplyHeaderTemplate(element, Pivot.HeaderTemplateProperty, viewModelType);
    };

Pretty cool?

Framework Usage

BindProperties is used exclusively by the ViewModelBinder.

ConventionManager

If you’ve read this far, you know that the ConventionManager is leveraged heavily by the Action and Property binding mechanisms. It is the gateway to fine-tuning the majority of the convention behavior in the framework. What follows is a list of the replaceable Funcs and Properties which you can use to customize the conventions of the framework:

Properties

BooleanToVisibilityConverter – The default IValueConverter used for converting Boolean to Visibility and back. Used by ApplyValueConverter.

IncludeStaticProperties - Indicates whether or not static properties should be included during convention name matching. False by default.

DefaultItemTemplate – Used when an ItemsControl or ContentControl needs a DataTemplate.

DefaultHeaderTemplate – Used by ApplyHeaderTemplate when the TabControl needs a header template.

Funcs

Singularize – Turns a word from its plural form to its singular form. The default implementation is really basic and just strips the trailing ‘s’.

DerivePotentialSelectionNames – Given a base collection name, returns a list of possible property names representing the selection. Uses Singularize.

SetBinding – The default implementation of ApplyBinding used by ElementConventions (more info below). Changing this will change how all conventional bindings are applied. Uses the following Funcs internally:

HasBinding - Determines whether a particular dependency property already has a binding on the provided element. If a binding already exists, SetBinding is aborted.
ApplyBindingMode - Applies the appropriate binding mode to the binding.
ApplyValidation - Determines whether or not and what type of validation to enable on the binding.
ApplyValueConverter - Determines whether a value converter is is needed and applies one to the binding. It only checks for BooleanToVisibility conversion by default.
ApplyStringFormat - Determines whether a custom string format is needed and applies it to the binding. By default, if binding to a DateTime, uses the format "{0:MM/dd/yyyy}".
ApplyUpdateSourceTrigger - Determines whether a custom update source trigger should be applied to the binding. For WPF, always sets to UpdateSourceTrigger=PropertyChanged. For Silverlight, calls ApplySilverlightTriggers.

Methods

AddElementConvention – Adds or replaces an ElementConvention.

GetElementConvention – Gets the convention for a particular element type. If not found, searches the type hierarchy for a match.

ConfigureSelectedItem – Configures the SelectedItem convention on an element.

ApplyHeaderTemplate – Applies the header template convention to an element.

ApplySilverlightTriggers – For TextBox and PasswordBox, wires the appropriate events to binding updates in order to simulate WPF’s UpdateSourceTrigger=PropertyChanged.

ElementConvention

ElementConventions can be added or replaced through ConventionManager.AddElementConvention. But, it’s important to know what these conventions are and how they are used throughout the framework. At the very bottom of this article is a code listing showing how all the elements are configured out-of-the-box. Here are the Properties and Funcs of the ElementConvention class with brief explanations:

Properties

ElementType – The type of element to which the convention applies.

ParameterProperty – When using Message.Attach to declare an action, if a parameter that refers to an element is specified, but the property of that element is not, the ElementConvention will be looked up and the ParameterProperty will be used. For example, if we have this markup:

<TextBox x:Name="something" />
<Button cal:Message.Attach="MyMethod(something)" />

When the Button’s ActionMessage is created, we look up “something”, which is a TextBox. We get the ElementConvention for TextBox which has its ParameterProperty set to “Text.” Therefore, we create the parameter for MyMethod from something.Text.

Funcs

GetBindableProperty – Gets the property for the element which should be used in convention binding.

CreateTrigger – When Message.Attach is used to declare an Action, and the specific event is not specified, the ElementConvention will be looked up and the CreateTrigger Func will be called to create the Interaction.Trigger. For example in the Xaml above, when the ActionMessage is created for the Button, the Button’s ElementConvention will be looked up and its CreateTrigger Func will be called. In this case, the ElementConvention returns an EventTrigger configured to use the Click event.

ApplyBinding – As described above, when conventional databinding occurs, the element we are binding has its ElementConvention looked up and it’s ApplyBinding func is called. By default this just passes through to ConventionManager.SetBinding. But certain elements (see above…or below) customize this in order to enable more powerful composition scenarios.

Footnotes

The WindowManager uses the ViewLocator under the covers. It inspects types to see if they are UserControl or Window/ChildWindow. If they are not, it automatically creates a parent Window/ChildWindow. So, you can choose to create your dialog views either as a UserControl or Window/ChildWindow in this particular scenario and the framework will take care of the rest. I typically make views UserControls when I can because that makes them a bit more reusable.
The bootstrapper is responsible for making sure that your application’s assembly is added to the AssemblySource, but you can add any additional assemblies by overriding the Bootstrapper’s SelectAssemblies method and returning the full list. You can also add additional assemblies to this collection at any time during application execution. So, if you are dynamically downloading modules that contain more views, you can handle that scenario pretty easily.
This pattern is borrowed from Javascript and I felt it generally made extensibility simpler for the most common use cases.
Recall that in Caliburn.Micro DataContext has the purpose of specifying to what instance databinding expressions are resolved and Action.Target specifies the instance that handles an Action. Thus, DataContext and Action.Target are allowed to vary independently of one another. By default, whenever the Action.Target is set, the DataContext is set to the same value though. To change this you can set DataContext explicitly to a different value or more commonly, you can use the Action.TargetWithoutContext attached property to set only the Action.Target without affecting the DataContext.
GetNamedElementsInScope used to be an extension method. However, it became apparent that developers wanted to customize the implementation. So, I made it into a Func. For lack of a better place to put it, it still lives on the ExtensionMethods class.
Well, I assume this would work. I haven’t actually tried it though.
If your item is a ValueType or a String we don’t generate a default DataTemplate. We assume that you want to use the default ToString rendering that the platform provides.
We don’t have this convention in Silverlight because A. TabControl is not part of the core framework and B. Silverlight’s TabControl is broken for databinding and has been for two versions of the framework without a fix. Please vote this issue up http://silverlight.codeplex.com/workitem/3604 It was reported about a year and a half ago and is not yet fixed.

Out-Of-The-Box Element Conventions

Following is the full code-listing showing how the built-in controls have their ElementConventions configured out-of-the-box:

#if SILVERLIGHT
AddElementConvention<HyperlinkButton>(HyperlinkButton.ContentProperty, "DataContext", "Click");
AddElementConvention<PasswordBox>(PasswordBox.PasswordProperty, "Password", "PasswordChanged");
#else
AddElementConvention<PasswordBox>(PasswordBox.DataContextProperty, "DataContext", "PasswordChanged");
AddElementConvention<Hyperlink>(Hyperlink.DataContextProperty, "DataContext", "Click");
AddElementConvention<RichTextBox>(RichTextBox.DataContextProperty, "DataContext", "TextChanged");
AddElementConvention<Menu>(Menu.ItemsSourceProperty,"DataContext", "Click");
AddElementConvention<MenuItem>(MenuItem.ItemsSourceProperty, "DataContext", "Click");
AddElementConvention<Label>(Label.ContentProperty, "Content", "DataContextChanged");
AddElementConvention<Slider>(Slider.ValueProperty, "Value", "ValueChanged");
AddElementConvention<Expander>(Expander.IsExpandedProperty, "IsExpanded", "Expanded");
AddElementConvention<StatusBar>(StatusBar.ItemsSourceProperty, "DataContext", "Loaded");
AddElementConvention<ToolBar>(ToolBar.ItemsSourceProperty, "DataContext", "Loaded");
AddElementConvention<ToolBarTray>(ToolBarTray.VisibilityProperty, "DataContext", "Loaded");
AddElementConvention<TreeView>(TreeView.ItemsSourceProperty, "SelectedItem", "SelectedItemChanged");
AddElementConvention<TabControl>(TabControl.ItemsSourceProperty, "ItemsSource", "SelectionChanged")
    .ApplyBinding = (viewModelType, path, property, element, convention) => {
        if(!SetBinding(viewModelType, path, property, element, convention))
            return;

        var tabControl = (TabControl)element;
        if(tabControl.ContentTemplate == null && tabControl.ContentTemplateSelector == null && property.PropertyType.IsGenericType) {
            var itemType = property.PropertyType.GetGenericArguments().First();
            if(!itemType.IsValueType && !typeof(string).IsAssignableFrom(itemType))
                tabControl.ContentTemplate = DefaultItemTemplate;
        }

        ConfigureSelectedItem(element, Selector.SelectedItemProperty, viewModelType, path);

        if(string.IsNullOrEmpty(tabControl.DisplayMemberPath))
            ApplyHeaderTemplate(tabControl, TabControl.ItemTemplateProperty, viewModelType);
    };
AddElementConvention<TabItem>(TabItem.ContentProperty, "DataContext", "DataContextChanged");
AddElementConvention<Window>(Window.DataContextProperty, "DataContext", "Loaded");
#endif
AddElementConvention<UserControl>(UserControl.VisibilityProperty, "DataContext", "Loaded");
AddElementConvention<Image>(Image.SourceProperty, "Source", "Loaded");
AddElementConvention<ToggleButton>(ToggleButton.IsCheckedProperty, "IsChecked", "Click");
AddElementConvention<ButtonBase>(ButtonBase.ContentProperty, "DataContext", "Click");
AddElementConvention<TextBox>(TextBox.TextProperty, "Text", "TextChanged");
AddElementConvention<TextBlock>(TextBlock.TextProperty, "Text", "DataContextChanged");
AddElementConvention<Selector>(Selector.ItemsSourceProperty, "SelectedItem", "SelectionChanged")
    .ApplyBinding = (viewModelType, path, property, element, convention) => {
        if (!SetBinding(viewModelType, path, property, element, convention))
            return;

        ConfigureSelectedItem(element, Selector.SelectedItemProperty,viewModelType, path);
        ConfigureItemsControl((ItemsControl)element, property);
    };
AddElementConvention<ItemsControl>(ItemsControl.ItemsSourceProperty, "DataContext", "Loaded")
    .ApplyBinding = (viewModelType, path, property, element, convention) => {
        if (!SetBinding(viewModelType, path, property, element, convention))
            return;

        ConfigureItemsControl((ItemsControl)element, property);
    };
AddElementConvention<ContentControl>(ContentControl.ContentProperty, "DataContext", "Loaded").GetBindableProperty =
    delegate(DependencyObject foundControl) {
        var element = (ContentControl)foundControl;
#if SILVERLIGHT
        return element.ContentTemplate == null && !(element.Content is DependencyObject)
            ? View.ModelProperty
            : ContentControl.ContentProperty;
#else
        return element.ContentTemplate == null && element.ContentTemplateSelector == null && !(element.Content is DependencyObject)
            ? View.ModelProperty
            : ContentControl.ContentProperty;
#endif
    };
AddElementConvention<Shape>(Shape.VisibilityProperty, "DataContext", "MouseLeftButtonUp");
AddElementConvention<FrameworkElement>(FrameworkElement.VisibilityProperty, "DataContext", "Loaded");