WinRT app @ Labdays

Installed win8 on my work laptop not too long ago so I decided to create my first winrt app during lab days at work. Due to lack of imagination I created a simple dashboard app for our product SAFE (really ugly page on saabgroup btw).

Started of by looking at some sessions on channel9 and googled design patterns, frameworks and ended up with the following:

I ended up writing a custom navigation service that I bootstrapped on application startup to make the IOC container from MVVM Light play nicely together with the AlternativeFrame from WinRT Xaml Toolkit. If you pay attention to the navigation between pages you can notice the nice dissolve transition which is done in AppShell.xaml in only 4 lines of markup.
Once I got the basic architecture in place I noticed that the panorama control from windows phone was missing for winrt. One google search later I found a blog post that addressed this issue so I ended up copying some code since I didn’t want to install the entire nuget package win8nl. What it basically does is to add a panorama behvior to the FlipView control. The sad thing though is that you can’t flick the screen if you don’t have a touch screen, which is extremely frustrating!
As for what goes for component arts data viz library I really think it’s not worth to pay for (trial is free), in the short time I played around with it I stumbled upon several bugs. An ugly work around for the PieChart control can be seen in the code behind file MainPage.xaml.cs. When data binding to an observable collection the control goes bananas as items are added to the collection, I needed to reset the DataSource for each added item for it to work properly.
All and all I’m pretty satisfied with the choice to use MVVM Light together with WinRT Xaml toolkit and the custom navigation service, I will definitely reuse that part for other projects.
Anyways the result can be seen in the vid below, you can get the source code here, if you’re interested in how I hooked up the components and architecture. You will probably not be able to run the application since it requires our back-end and I didn’t spend too much time on exception handling.

 

Merry x-mas everybody and a happy new year, I’m off for two whole weeks!

 

What about WCF 4.5 and the async/await pattern?

From what I’ve heard it should be pretty smooth to produce asynchronous server/client code with .net 4.5, so let’s try it out! Defining async methods on the service contract is now a lot cleaner :

[ServiceContract]
public interface IPeopleService
{
	[OperationContract]
	Task<IList<Person>> GetPeople();
}

instead of the wcf 4.0 way which would look something like this :

[ServiceContract]
public interface IPeopleService
{
	[OperationContract(AsyncPattern=true)]
	IAsyncResult BeginGetPeople(AsyncCallback cb, object state);

	[OperationContract]
	IList<Person> GetPeople();

	[OperationContract]
	IList<Person> EndGetPeople(IAsyncResult ar);
}

the server side implementation of the operation when returning a task is straightforward :

public async Task<IList<Person>> GetPeople()
{
	Task t1 = Task.Delay(500);
	Task t2 = Task.Delay(500);
	await Task.WhenAll(t1, t2);

	return await Task.Factory.StartNew(() => people);
}

If you don’t want to await something in the method you can skip the async keyword and still return a Task as shown below, async on a method simply tells the compiler that “I’m going to await something in this method”.

public Task<IList<Person>> GetPeople()
{
	return Task.FromResult(people);
}

Anyways it’s really nice to skip the non-implemented begin/end methods on the server which was simply boiler plating in .net 4.0. For the sake of simplicity the service will be hosted in a console application and for consuming the service I’ve implemented a simple proxy that inherits ClientBase<TChannel> and implements the contract. See the code if this confuses you (which probably means that you’re a noob ;-)). The client code when working with tasks is clean and straightforward as well :

var serviceProxy = new PeopleServiceProxy("PeopleServiceEndpoint");

Task<IList<Person>> people = serviceProxy.GetPeople();
people.ContinueWith(
	x =>
		{
			foreach (Person person in x.Result)
			{
				Console.WriteLine(
					"{0} {1} born {2}",
					person.FirstName,
					person.LastName,
					person.BirthDate.ToShortDateString());
			}
		});

We can control on which thread we will continue by passing in a TaskScheduler. So far so good, so what about testing? I’m using Nunit which integrates really well with VS when using resharper. I want to write an integration test (not unit) to make sure everything works well including the WCF part since unit testing my simple service is too easy 😉 I’ll host the service in the Setup method and take it down in the teardown. A simple test then looks like :

[Test]
public void ShallBeAbleToGetDateTimeFromService()
{
	IPeopleService serviceProxy = new PeopleServiceProxy("PeopleServiceEndpoint");

	Task<IList<Person>> getPeopleTask = serviceProxy.GetPeople();
	getPeopleTask.Wait();

	IList<Person> result = getPeopleTask.Result;

	Assert.IsNotNull(result);
	Assert.AreEqual(2, result.Count);

	(serviceProxy as IDisposable).Dispose();
}

Obviously we’d use facades to call on services in a real application but the principle is the same. It doesn’t get much cleaner than this imo.

/A

Get the code here! (67KB)