Windows Phone MVC?

So to get started, let me explain what it is.
It is a MVC + MVVM Hybrid framework, I think MVVM falls down in a few area’s, and by teaming up with the MVC pattern we can achieve great testability, performance, navigation, lifecycle etc..

The aim of Windows Phone MVC is to make windows phone development quicker, easier, more enjoyable and most of all help you build a nice performant app which gives an awesome user experience.

This is going to be quite a long post going through many features of Windows Phone MVC, I hope it gets across what I am trying to do with the framework, and how it can help you out!
I am still a little way from v1, so there will be API changes, but I am more than happy to field some questions about how to use it.

Many of the improvements on this release are due to http://transhub.wordpress.com/ using Windows Phone MVC and I have been working close with the transub team to make sure the framework helped them deliver a killer app!

Last week I put together a project template for a windows phone 7 test project. At the moment there isn’t a really good story for unit testing on the phone. If you have the mango tools you have to grab the Mango Silverlight Unit Test assemblies from Jeff Wincox’s blog.

The Project Template available at http://visualstudiogallery.msdn.microsoft.com/6819514d-4bd6-4f31-a231-48c6530ed03b is really basic, and you then have to add a reference via NuGet of either the Silverlight Unit Testing Framework (doesn’t work with Mango), or WindowsPhoneEssentials.Testing.

The advantage of the WindowsPhoneEssentials.Testing project is it contains the Mango compatible versions, sets everything up and has a collection of really useful testing related helpers/abstractions for WP7. Check out http://windowsphonefoundations.net/windowsphoneessentials or the source at http://wp7essentials.codeplex.com/ for more information.

But what you get after you install it is:

Then you add the NuGet reference to WindowsPhoneEssentials.Testing

Enjoy!

I blogged a few weeks ago about the Windows Phone Essentials project, since then, I have started up the http://windowsphonefoundations.net/ website which is home to Windows Phone Essentials, Windows Phone MVC and Windows Phone MVP (and more projects in the future).

Features

This will change over time, so check out the change log.

• Strongly Typed Navigation
• Custom Shell, Navigator and Journal to give better control over navigation of WP7
• TransitionFrame comes out of the box, for nice navigation animations
• Ability to pass arguments in navigation, rather than uri query strings
• Modal Dialog support
• Easy access to Obscured and Activated events on your view model
• Full Testable! All major WP7 classes (WindowsPhoneFrame, WindowsPhoneApplication etc) all have Interfaces and are wrapped to allow you to test
• Some helpers around Async. Execute.AsyncPattern or Execute.AsyncPatternWithResult synchronise async calls
• Task/Chooser support, in a testable way
• Convention based Controller and View discovery
• Autofac Support Via an Extension
• Easy access to page or application transient storage
• Simple tombstoning support

The problems

Lets start with the problems we want to solve with our solution

• Blend Design time support
• Resharper binding validation support
• No using ServiceLocator, DI only
• ViewModels should be testable

Frameworks like Magellan solve these sort of issues in other ways, but if you don’t want to take on a framework then maybe an approach like this may help you get started.

I dislike having R# warnings in code bases I work on, and try to leave every class I work on having a green status.

Here is a scenario

var entryAlias = default(Entry);
var entries = session.QueryOver<Entry>(()=>entryAlias);

In the above scenario R# will warn that entryAlias is always null, which is is, but I don’t care, nHibernate is simply getting the type from the expression.

I have hit this before, but it was VSTO related and posted about it http://jake.ginnivan.net/clickonce-deployment-in-teamcity

When trying to publish my clickonce installer I am getting the error:

[14:55:16]: [_DeploymentGenerateBootstrapper] GenerateBootstrapper
[14:55:16]: [GenerateBootstrapper] c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3939, 9): warning MSB3155: Item 'Microsoft.Windows.Installer.3.1' could not be located in 'C:\TeamCity\buildAgent\work\63190f273e745a25\TrainersAdmin'.
[14:55:16]: [GenerateBootstrapper] c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3939, 9): warning MSB3155: Item '.NETFramework,Version=v4.0' could not be located in 'C:\TeamCity\buildAgent\work\63190f273e745a25\TrainersAdmin'.
[14:55:16]: [GenerateBootstrapper] c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(3939, 9): error MSB3147: Could not find required file 'setup.bin' in 'C:\TeamCity\buildAgent\work\63190f273e745a25\ProjectName\Engine'.

If your build server is a x64 operating system copy 'C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\' to the same directory on the build server, then copy the blow code into a file called FixBootstrapper.reg, then run it.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\4.0]
"Path"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bootstrapper\\"

If you have a x86 build server, upgrade. Otherwise copy ‘C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\’ to the same directory, then copy the blow into a registry file

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\4.0]
"Path"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.0A\\Bootstrapper\\"

Yesterday the project I have been working on for close to a year now went live! We have had very minimal issues and apart from working with an Amazing team of Readify people we have made use of an extensive suite of UI Automation and Integration tests.

Our UI Automation suite was originally supposed to simply be ‘Smoke Tests’ which run through all UI processes in our application and makes sure it works end to end, not really asserting much, just that the process worked and the expected result was there at the end.

This grew… we now verify all application logs, have helpers which wait for our message processors to send and receive all messages, then assert everything from audit messages, to financial movements to report data. It has given us amazing confidence in our product and allowed us to go live with maybe a dozen medium priority bugs which has taken us ½ a day to get on top of.

I have started breaking out the framework we built into a CodedUI contrib project which lives in the MSTestContrib project on codeplex (http://mstestcontrib.codeplex.com)

I will be creating a WPF Todo application using the framework, writing my UI Automation tests first, refactoring, making mistakes, improving the code etc. It will be the first time I have used EF, so this whole thing will be a learning experience.

Rich Client UI Automation, without shooting yourself in the foot

When you talk to most people that have tried Coded UI Tests or other UI Automation they tell you it was great, then it caused them way too much pain to be worth it. This phenomenon is also known as the Sine of Death by UI Test Automation. In this session Jake will show you how to avoid the Sine of Death and make UI Automation an invaluable part of your testing with a great ROI which reducing risk in the project.

After watching this session you will talk away knowing how UI Automation works, what each of the Frameworks (White, Coded UI) give you, and the techniques you can apply to succeed with UI Automation. These techniques are used in production right now and you will see a demo of that applications test suite.

Resources

I will post resources on Rich Client Automation after my talk, or early next week.

Update Compatibility table at http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Common_Framework_and_Profile_Targeting_Examples

I released windows phone essentials last week, and I have the mango tools installed, so all seemed fine. Then when a friend of mine tried to install the package they got the following error:

Unable to find assembly references that are compatible with the target framework 'Silverlight,Version=v4.0,Profile=WindowsPhone'

Hrrm that blows. As you may be aware, Windows Phone 7 runs a version of silverlight known as Silverlight 3.7. NuGet recommends that you use the lib\SL3-WP for windows phone projects, but if you install the mango tools, this will change to SL4-WP. On top of that if you create a project targeting mango specifically you need to put your library into SL4-WindowsPhone71. It seems that NuGet 1.4 will replace WP with WindowsPhone, but I am not sure about previous versions.

My workaround at the moment is to just specify all of them until there is some official documentation:

lib\SL3-WP\WindowsPhoneEssentials.dll
lib\SL4-WindowsPhone71\WindowsPhoneEssentials.dll
lib\SL4-WindowsPhone\WindowsPhoneEssentials.dll

Windows Phone Essentials tries to fill a gap that many of the other WP7 frameworks don’t fill. Most of the libraries out there are Controls and UI related libraries, wp7essentials tries to fill that gap.