Morse Coder Part 1 : Universal Apps with MVVM Light

This is the first in a series of blog posts detailing the process of creating a new Universal App targeting Windows 8.1 and Windows Phone 8.1, from creation of the solution to publication to the store. The goal of the application is to translate between Morse Code and the standard Alphabet and vice-versa.

Background

MVVM Light is an excellent MVVM toolkit by Laurent Bugnion that I’ve used on a number of apps currently published on the Windows Phone Marketplace.
Universal Apps (can, and do by default) use a shared code project in order to share code between platform specific Projects at compile time.

Outcome

By the end of this post we should have a compiling Universal App Solution, with projects targeting Windows 8 and Windows 8.1 with MVVM Light Libraries installed along with some basic ‘plumbing’ in place to provide the foundation for the rest of the series to build upon. We should have a MainViewModel created, wired up to a view, along with some design time differentiation of what to display in Expression Blend and the Visual Studio Designer as opposed to what is presented to the View at Runtime.

Prerequisites

Implementation

First we need to create a Universal App Project, this example uses the Blank App Template as below.

Project Creation in Visual Studio

This will give us 3 fairly self-explanatory Projects in Our Solution:

MorseCoder.Windows;

MorseCoder.WindowsPhone;

MorseCoder.Shared.

Now we add the MVVM Light Libraries Only package from NuGet, either via the Package Manager Console using…

Install-Package MvvmLightLibs

…or through right clicking your project and selecting ‘Manage NuGet Packages’ and searching as follows…

NuGet Package Manager

This needs to be done for both the Windows and WIndows Phone Projects.

We now need to create a basic View Model for the MainPage in order to provide a container for our views to Bind against, and a ViewModelLocator to provide instances of our newly created ViewModel. Both of these are to be shared between Windows and Windows Phone, so we will create them in the Shared Project .

Create a folder named ViewModel in the Shared Project, and create a MainViewModel.cs class. Your MainViewModel class needs to inherit from the MVVMLight ViewModelBase. For now, we need to consider :

a public string property, ‘Translation’, which (surprisingly), will house the translation of the user’s input;

a private field, ‘_translation’, providing the storage for the public properties accessors;

the public property’s setter will need to raise a Property Changed event;

the constructor of the MainViewModel class needs to populate Translation with something (doesn’t really matter what at this stage).

with the above in mind, we end up with a MainViewModel looking like this:

Note the IsInDesignMode property on the ViewModelBase class, in this instance we use this to differentiate between what we want to display for a given property at design time and run time. More importantly we can use it with Dependency Injection to provider services to our constructor; for example if our Transation property would ordinarily be provided by a Database, we can ‘stub’ this service with a Deisgn Time equivalent for use with the IDE, this will be covered in a future post.

Create a class named ViewModelLocator in the ViewModel folder in the Shared project. This provides instance of our ViewModels to the views at run time, (along with providing a place to configure dependency injection, again, this will be looked at in a future post). We need to consider:

a public property for our Main View Model, configured to return an instance of it through the ServiceLocator;

With the above considerations in mind, this should be fairly self explanatory, we’re mapping up the MainViewModel instance to the Main Property on the locator class. The configuration of the Service Locator Provider happens within a static constructor of the ViewModelLocator.

Now that we have our ViewModelLocator in place, we need to make it available to our application(s) through xaml. Note that the App.xaml is by default in the Shared Project. We need to add the following static resource to our App.xaml file in order for views to be able to reference our ViewModelLocator :

[xml]

[/xml]

Note the inclusion of the namespaces, vm and d, bringing in our references to our ViewModel namespace and some design time blend functionality. The ViewModelLocator key is set to “Locator”, this is the reference our Views use in order to retrieve the ViewModelLocator instance.

At this stage, we have most of the plumbing in place, our ViewModel has a string property to bind and our ViewModel is available via the ViewModelLocator, we are now ready to do add the DataBinding to our View.

We now need to add our DataContext to our MainPage View XAML file. Add the following to the Page Element :

DataContext="{Binding Main, Source={StaticResource Locator}}"

As above, our ViewModelLocator key was set to “Locator” in our Application Resources, our MainViewModel property on the ViewModelLocator class is named Main, we now have an instance of our MainViewModel set as the DataContext on the MainPage View. We’re now ready to do some binding.

Add a TextBlock to your page and set the Text property to bind against our Translation property on our ViewModel, again, at this stage we aren’t concerned with how it looks. Our view’s XAML now looks something like this :

[xml]

[/xml]

Note the ‘Text={Binding Translation}’ attribute configuring the DataBinding against the Translation property.

Do this for both the Windows and Windows Phone Projects.

Your views at design time should now look like this…

Windows Data ContextWindows Phone Data Context

Summary

Where are we?

We’ve created a set of Universal App Projects targeting Windows 8.1 and Windows Phone 8.1, leveraging a Shared Code Project;

Added our MVVM Light Dependencies;

Created a View Model;

Added a ViewModelLocator to provide View Models to Views, and made it available through an Application Resource;

Added a TextBlock to our views and bound it to a Property on our View, specifically being set for Design Time.

Where are we heading?

The next post will cover Portable Class Libraries (PCLs) and how we can make use of them alongside our Shared Code Projects.