Mike Taulty's Blog
Bits and Bytes from Microsoft UK
Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?

Blogs

Mike Taulty's Blog

Elsewhere

Archives

In talking to developers around Windows/Phone applications I often find that there’s something of a “tax” in being able to get to the position of discussing a simple example that uses views, models, viewmodels, services and I kind of wish that the Visual Studio templates and XAML frameworks provided more in this area in order to avoid developers having to decide;

  1. Do I need this MVVM thing?
  2. How far do I go with it?
  3. Is it something that Microsoft “wants” me to do or am I going against the flow?
  4. Should I invent something to fill the gaps that I seem to encounter?
  5. Which of the existing MVVM libraries/frameworks should I use if I don’t invent?

I was thinking about this in writing my previous blog post and thought I’d jot down some quick examples of where it feels like I’m paying that “tax” in building up examples;

1. Where’s My Implementation of INotifyPropertyChanged?

I’m a bit stunned that the .NET framework provides INotifyPropertyChanged but no base class to implement it for a developer. Given that data-binding is so powerful and common in XAML-based applications and that data-binding really relies on on “INPC” ( hey, it’s even so common that we’ve abbreviated it over the years to “INPC” ) I’m surprised that the framework doesn’t ship with some implementation.

2. Where’s My Implementation of ICommand?

Pretty much the same thing. Given that most folks agree that you want to separate out your View from its ViewModel and given that binding is a great way of doing it and given that ICommand is provided in the framework and is pretty much the means via which we can bind a View to executable behaviour, why not give the developer an implementation of it in the platform then we all can use the same one and agree on what it does?

3. Can Navigation be Separated from the Frame?

I’d really like to see the idea of navigating around the app to be separated from having access to a Frame object. I might want to write some piece of code somewhere deep in a library that causes navigation to (e.g.) a “details page”. I’d like that code to be able to make a call like NavigationService.Navigate(“details page”). I don’t really want that piece of code to have to know about the UI in the sense of having access to a Frame object. I’d prefer to see some abstracted NavigationService that a Frame can hook into rather than tying the two things together.

4. Can Navigation be Separated from the Type of the View?

While thinking about navigation, I’d really like a navigation service to deal with some simple token like “details page” rather than some concrete type. Maybe some convention can be applied such that “DetailsPage” would be default resolve to some type called DetailsPageView or similar so long as that convention can be overridden.

5. Can a Service be Provided to Wire up the View to its ViewModel?

Where a view (whether a UserControl or a Page or whatever) today has a DataContext I’d like it to have some kind of “DataToken” or “ViewModelName/Token” property. That token could be something as simple as a string that, again, convention can be applied to in order to resolve a view model to go with a view. That is, a page could specify Page.ViewModelName=”Foo” and the XAML framework could apply an overridable convention for how the string “Foo” gets resolved into an instance of a view model.

6. Can ViewModels Understand Navigation?

If we want to cleanly separate a View from its ViewModel then it’d be great for the ViewModel to have an “awareness” of when things are happening in the app. For instance, a ViewModel might want to “know” when it is being created for the first time and it might want to “know” when it is being discarded and/or re-used.

The challenge with the bits as they ship with Visual Studio is that it is the ViewModel that has the data but the View (i.e. Page) that the awareness of whether it is being navigated from/to and whether that navigation involves being created for the first time or is a re-use from cache and so on. The developer’s then left to try and figure out how to get that information from the View to the ViewModel.

7. Can There be a Slot for an IoC Container?

This is somewhat a corollary of items 4 and item 5 above. Typically, I have a View which has some ViewModel behind it which has some dependency on some Services living below it. I’d like the framework to allow for resolving these types via an IoC container (of any type). Now, if I have item 4 and item 5 above then I can probably build that myself but I’d like to see the framework make it much easier for developers to just assume IoC rather than treat it as some oddity.

8. Can ViewModels Understand Suspend/Terminate?

Similar to point 6 above – in the XAML frameworks for Windows/Phone 8.1 apps today there’s little automatic support for saving/restoring state when an application needs to suspend/terminate and then re-run and get the user back to where they were when the app was terminated by the OS. There’s a class in the app templates called SuspensionManager which links up with some other classes (Frame, Page, NavigationHelper) to ensure that your Page navigation history (+ parameters) can be saved but this largely operates at the Page (View) level rather than offering support to the developer who needs that at the ViewModel level.

Those are the first 8 that I thought of. I’m sure there are more.

Now, of course, I can build these myself. More likely, I can go and use someone else’s implementation – e.g. a framework like MvvmLight or Prism or MvvmCross or one of those would probably cover all of these and much more (e.g. loosely coupled events might be another thing that I’d want).

The “problem” is that if those frameworks don’t ship plugged in as a default for Visual Studio then at least three things happen;

  1. A developer is faced with those immediate choices of “which of these is the right one to go with if I need any of them?”
  2. A conversation always has to be brokered around “do you use X, Y or Z?” with a fallback conversation if a developer doesn’t.
  3. The tooling can’t make an assumption that a developer will be working with framework X in a particular pattern and then start to help that developer by building higher levels of abstractions on top of that assumption.

I thought I’d jot these down. It’s not an attempt to complain or to rant but a suggestion as to something that I think could improve developing these kinds of apps and, as always, I’m keeping my eye out for anything that comes along and adds in these areas. Feel free to discuss in comments below and especially if you think it’s something that you wouldn’t want to see change – always looking for contrary viewpoints!


Posted Fri, May 9 2014 8:57 AM by mtaulty

Comments

Nick wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Fri, May 9 2014 9:16 AM

So which one of these frameworks you would use? =D

I am using Prism right now for a desktop WPF product, but I think it's a framework too big for Windows Phone app.

Austin Dimmer wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Fri, May 9 2014 9:31 AM

Great points Mike. I support a lot of what you say and faced these problems in the past in the end I opted to use the excellent Fody for automatic implementation of INPC. I combine this with the equally excellent ReactiveUI MVVM framework. They work very well together.

Rehan Saeed wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Fri, May 9 2014 10:48 AM

I'll add a few more to that list coming from a WPF and WinRT perspective.

Validation is an often overlooked missing chunk of functionality. INotifyDataErrorInfo provides a nice way to do this but again there is not base class. Worse, still, most WPF frameworks (Not sure about WinRT) do not provide proper styles for controls when they are in an invalid state.

ObservableCollection does not have AddRange, so you always need a helper method.

What if you want to know if some property on an object in your collection has changed, so you can for example raise a 'Can Execute Changed' on your ICommand. I think this is a fairly common thing to do. ObservableCollection is no help here.

Showing or hiding Windows or popups (WinRT now has Multi-Window support) has always been difficult in MVVM.

Finally, How about the MessageDialog/MessageBox? In MVVM you have to write a wrapper for that too.

Russell Archer wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Fri, May 9 2014 12:32 PM

Absolutely spot-on with your observations!

It is strange that, given that MVVM is pretty well established as the *right* way to approach a non-trivial app, Microsoft doesn't supply some officially support/sanctioned MVVM templates.

I wrote my own very simple MVVM framework, mostly so I could learn about what's involved. I encountered pretty much all the items you raised.

In particular, given how tedious and error-prone the whole save/restore business can be when you've got lots on objects, I implemented an auto-save/restore mechanism. Now, all I need to do is decorate ViewModel properties with a [AutoSave] attribute and my ViewModel base class does the save/restore work.

Anyway, great post!

Russell

Brian wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Mon, May 12 2014 7:37 PM

I would mirror Rehan in regards to the MessageBox.  In fact I just did a post about wrapping SaveFileDialog, OpenFileDialog so you can call them from your view models.  But is this something I should have to wrap?  It feels like there are a few interfaces that don't really fit into one of the MVVM frameworks and should be more a part of the core just to more cleanly separate the view and view model.

Brian

Will Rogers wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Thu, May 15 2014 1:46 PM

Some of my coworkers and I commented on this lack of guidance and basic MVVM implementations in the recent WPF survey sent out by Tim Heuer.

Will Rogers wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Thu, May 15 2014 1:49 PM

Also:

9: How does 1 ViewModel talk to another ViewModel? An Event Aggregator should be available in the framework without having to include the entire Prism framework.

David Cuccia wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Thu, May 22 2014 5:52 AM

Hear hear!

mtaulty wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Wed, May 28 2014 7:26 AM

Hi Will,

If I remember correctly, Prism packages its loosely coupled events support in its own library?

Thanks,

Mike.

Carlos Farinha wrote re: Windows/Phone 8.1 and XAML Apps–Making It Easier for MVVM Developers?
on Thu, May 29 2014 12:42 AM

Hi Mike,

This post shows how much you are involved with professional applications. We need to use all of these every day.

I believe that the "which" is not pacific, because there are aspects in all that technologies that some like and others don't. Examples View-Models been singletons, IoC with injection in the constructors, etc.

If they would like to create a group to work and test the implementation of an alpha version, can count with my help :)