Wednesday, July 28, 2010

Building your Windows Phone 7 Series apps using Team Foundation Server 2010

UPDATE: There is a workaround to what I have said here. See this post - a really cool way to build WP7 targeting different WP7 builds: http://justinangel.net/WindowsPhone7EmulatorAutomation#BlogPost=TFS2010WP7ContinuousIntegration

So the ultimate question is, how do I build my Windows Phone 7 Series apps on TFS and perhaps run unit tests against a Windows phone 7 series emulator. The short answer is you can't, well that's not entirely true. You can build your Windows phone 7 series apps on TFS so long as you install the developer tools on your build server.

Bear in mind when you install the developer tools you will not only get all the required build targets and Silverlight framework for Windows phone 7 series but also a VS2010 IDE as well. This will either be VS2010 Express edition if you don't already have VS2010 RTM installed on your server, or the tools will integrate into VS2010 RTM (if installed). Either way, you are going to get an IDE on your build server.

This might sound rather ugly and I have asked Microsoft for separation of the tools/framework etc from the IDE so ISVs/consultancies can be more flexible how they build their apps. But this is really not high on Microsofts priority list right now. The reason is simple. These tools are targeted toward consumers, so the majority or at least what Microsoft would like is the majority of people building apps/games for Windows phone 7 series are individual programmers whether professional or ameteur and not big companies. Long term this will change.

Instead, the priority is to deliver a really quick and easy way to get up and running building Silverlight or XNA apps for Windows phone. And Microsoft has done this. Simply go to http://developer.windowsphone.com/ and you can download a single package, run it and this will set your machine up ready to build and ship apps on the Windows phone platform. No other downloads are required.

The cool thing about this is, unlike Windows Mobile development, the tools are free. A great step forward.

So to recap, in order for more professional programmers to build Windows phone apps using a sophisticated continuous integration yada yada solution, you need to install the tools on your build server, but you will get the IDE as well.

I also mentioned unit testing. Currently the latest beta tools do not support unit testing on the emulator. Of course you can still write unit tests that execute on the desktop against your Silverlight for Windows phone apps. I have a sample of this over at http://wp7.codeplex.com/

Happy coding!

Monday, July 26, 2010

Username and password format for TFS on codeplex

When you first setup a project on codeplex there is a popup that tells you what domain\username and password to use to connect to the TFS server.

But I found after setting up a project I couldn't remember what the format should be.

So this post is really for my benefit if nothing else, here it is:

Username: snd\<username>_cp
Password: <Codeplex password>

Sunday, July 25, 2010

I'm TestDriven.Net

Thanks to the chaps over at http://testdriven.net/ I got the opportunity to test their product.

So, one of the real problems with Visual Studio when it comes to unit testing your code is it is really slow and unproductive.

If I write a test method in C#, I often want to quickly run it and run it often as this is the whole point of TDD isn't it. If you use MSTest you'll probably find this is the slowest testing tool available but its great integration with TFS often makes it a desirable choice.

To quickly test our method we normally right click the method in code, and select "Run Tests". This will (if a MSTest) switch to the Test Results window and show you the result of the test, great. But...you'll find this quite slow. Then what if you want to debug a test. First you have to run the individual test as said above, then check the check box and hit Debug Test.


This is fine but all very time consuming, why can't I just say Debug this test without having to run it first, check the check box, then hit Debug test.

This is where TestDriven.Net comes into play. Now after installing the tool, I have a new menu item when right clicking my test "CanResolveTransientComponent":



So here I can hit "Run Test(s)" and it will execute the test in a fraction of the time that Visual Studio will do it. When doing this, TestDriven.Net will switch to the output window and show the test output:



So 0.36 seconds is pretty fast. When running via Visual Studio it is much longer, perhaps around 2 seconds for the same test.

The reason for this is when you execute via TestDriven.Net, it omits MSTest code coverage. This greatly speeds up the testing process. If and when you're interested in code coverage you can ask TestDriven.Net to give it to you.

There is a submenu when you right click your test method:



I like this submenu alot. It gives great flexibility in how you run your tests. If you want to simply debug your test without have to go through the lengthy steps mentioned earlier, simply select "Debugger". Sweet.

As mentioned earlier regarding code coverage. When quickly executing a test the MSTest code coverage is omitted in order to speed up the test greatly. But if you want MSTest code coverage then you can select "Coverage" from this handy submenu. This will give you pretty much the same results as if you ran the test via Visual Studio itself.

As you can probably see, if you use another test tool other than MSTest, there is integration for NCover. In fact NCover works for MSTest too. Selecting NCover from the submenu fires up the NCover Explorer tool that gives you a code coverage for the test(s) you have selected to run:



This is a great feature, I do like this.

Another really cool feature that I'd like to mention is support for performance testing. Selecting "Performance" from the TestDriven.Net submenu gives you a nice breakdown of performance data for your test:



There are many more features to checkout with TestDriven.Net and I recommend you check them out.

Sunday, July 18, 2010

Windows Phone 7 Extension Tools

I started porting some code from the Compact Framework over to Silverlight for Windows Phone.

I have created a project on codeplex: http://wp7.codeplex.com/. The solution so far contains an IoC with support for implicit dependency injection - in fact this is a port from the Compact Container on the CF. It also contains a port of the Common Service Locator for the desktop by the p&p team at Microsoft.

The project is designed to be a work in progress and I'll add stuff to it if I think it might be useful to others.

I do plan over the next couple of days to add an event aggregator to the solution that will integrate with the container nicely to promote nice loosely coupled multicast event model in your Silverlight applications.

I am also working on an API that allows communication with the Microsoft Azure Service Bus - much like you get on the desktop. I will checkin as soon as it is available.

The current solution that is checked in is designed to be used with the latest release of Windows Phone developer tools beta.

Friday, July 16, 2010

Windows phone virtual live class - July 20th and July 22nd

Jump start your development of Windows Phone 7 applications by attending Windows Phone 7 JumpStart. This free virtual live class, comprised of four instructor-led 3 hour sessions, will guide you in developing applications for the Windows Phone 7 platform using Silverlight and XNA. Register today by visiting: https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032455932&EventCategory=2&culture=en-US&CountryCode=US.


Course sessions:

July 20 – 8am: Session One: Getting Started with Microsoft Windows Phone and Silverlight
July 20 – 1pm: Session Two: Programming Game Applications with XNA
July 22 – 8am: Session Three: Programming Applications with Silverlight
July 22 – 1pm: Session Four: Review and Wrap Up

Wednesday, July 14, 2010

Pivot and Panorama support in Windows phone 7 beta






The title of this blog post is a little confusing (it was meant to be!) in that there is no support for the Pivot and Panorama controls in the latest bits of Windows phone dev tools. The controls pictured above are courtesy of Stephane Crozatier.

Those controls are freely available on codeplex to download but were designed for the CTP bits of Windows phone. So as there were some breaking changes between the CTP and the recently released beta they won't work out of the box. But it very easy to fix.

Firstly you need to do delete the Microsoft.Phone.* references and add the Microsoft.Phone.dll to the project. All those additional dlls have been merged into Windows.Phone.dll.


Then you'll need to clean up the XAML namespaces. Luckily for me I have ReSharper 5.0 installed and all I have to do is press Alt+Enter and it fixes all my problems! nice



Now if you want the sample WeatherForecast app to run you need to do 1 last thing. That is the ApplicationBarIconButton class now has a mandatory Text property so you need to set this property for each of the buttons in the MainPage.xaml file.

Now once I clean up all that XAML, I rebuild and run and I get...



Sweeet....

Another nice cool thing with this emulator over the older Windows Mobile emulators is that you can do a ALT+Prnt Scrn to get a copy of the current focused window. You can't do this on Windows Mobile emulators.


Windows phone UK User group






I just learn't there has recently been a Windows phone 7 UK user group setup. The first meeting is 28th July at Conchangos offices in London. http://wpug.net/.

Microsofts Paul Foster and Rob Fonseca-Ensor will be speaking. There is now a wait list on the event but worth a try right!

Monday, July 12, 2010

First impressions Windows Phone Developer Tools beta

I just installed the beta bits released this evening and as per the CTP the install experience is brilliant. Except with the beta the greatest thing is support for Visual Studio RTM. So unlike the CTP, even if you had VS RTM installed, then you installed the WP7 dev tools, the installer would install the CTP of VS express and not integrate with VS RTM. Actually I found a whole bunch of errors when attempting this with the CTP.
New project in VS 2010 RTM (no support for VB.NET though):


However this build is good. I'm running VS 2010 Ultimate and VS 2008 Team Suite and this build integrated with VS 2010 RTM nicely.

It is also worth noting in this release of WP7 dev tools, you get Expression Blend 4 for Windows Phone beta. In the CTP you had to download this separately.
So experience so far is great, well done Windows Phone 7 team.

Emulator running bing:



I'll post my experiences of actually writing WP7 code using these bits in later posts. In the mean time you can download and try for yourself.

Windows Phone Developer Tools Beta is here

Announced today at WPC. Get it from: http://www.microsoft.com/downloads/details.aspx?FamilyID=c8496c2a-54d9-4b11-9491-a1bfaf32f2e3&displaylang=en

Check out this post on breaking changes from CTP to Beta: http://blogs.msdn.com/b/jaimer/archive/2010/06/28/migrating-apps-from-windows-phone-ctps-to-the-beta-build.aspx?wa=wsignin1.0

I'll post my feedback once I've installed it and tried it out.

Notice this under "System Requirements:"

This Beta of the Windows Phone Developer Tools is compatible with the final version of Visual Studio 2010


This has made my day :)

Friday, July 02, 2010

Testing Motorola EMDK WLAN implementation on the desktop

I've been writing about testing recently and whether or not to use device test projects or desktop test projects. You can read my view on this in a previous blog post.

No doubt if you have written code for any of the Motorola rugged devices (or other rugged OEM devices) you might have encountered the EMDK WLAN class (or similar if not coding against the EMDK) - which wraps the low-level mobile specific Motorola Fusion API. This is a prime example of why you should use a desktop test project rather than device project. Hang on, you just said the Fusion API can only execute on the device, so don't we need a device test project? No. The reason is simple, again if you have a continuous integration, automated build process setup, your tests will be executing on the build server so you won't be able to execute those tests against a real Motorola device. If you have a device test project, the best you can do is execute those tests on the Windows Mobile emulator - but what will this prove? In this case this is really no different in terms of a test problem than executing them on the desktop.

So this is a reason to write your WLAN tests within a desktop test project. Let me demonstrate...

The WLAN class that comes with the EMDK (Symbol.Fusion.WLAN.WLAN) is a prime example, to make things worst, it doesn't implement an interface, take a look:



So this makes it almost impossible to test. Instead how I have overcome this problem is to write an adapter that wraps the WLAN class, then mock out the adapter using Rhino Mocks. Observe the following WLAN implementation, the interface isn't important:
public class MotorolaMC75WLAN : IWLANService
{
private readonly IMotorolaWLANAdapter _adapter;
private bool _disposed;

public MotorolaMC75WLAN(IMotorolaWLANAdapter adapter)
{
_adapter = adapter;
}


public void Enable()
{
if (!_adapter.IsEnabled)
{
_adapter.Enable();
_adapter.PowerStatusChanged += OnPowerStatusChanged;
}
}

private void OnPowerStatusChanged(object sender, PowerStatusChangedEventArgs e)
{
//raise events to interested parties....perhaps using some sort of event aggregator
}

public void Disable()
{
if (_adapter.IsEnabled)
{
_adapter.Disable();
_adapter.PowerStatusChanged -= OnPowerStatusChanged;
}
}

public bool IsEnabled
{
get { return _adapter.IsEnabled; }
}

public void RenewDHCP()
{
_adapter.RenewDHCP();
}

public void Connect()
{
_adapter.Connect();
}


#region IDisposable Members

public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}

#endregion

private void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
Disable();
_adapter.Dispose();
}
_disposed = true;
}
}
}
So that is our high level implementation that can be easily extended and contains no low-level mobile code. The adapter in this case is injected and can be anything we want it to be which allows us to test this class easily on the desktop.

The next thing is our actual adapter. The interface for the adapter looks like this
public interface IMotorolaWLANAdapter : IDisposable
{
void Enable();

void Disable();

bool IsEnabled { get; }

void RenewDHCP();

event EventHandler PowerStatusChanged;

void Connect();
}
The implementation is low-level that talks directly to the WLAN class (Fusion API). I'm not going to include a typical implementation for this but an example Enable() method might look like the following:
public void Enable()
{
if (IsEnabled)
return;

Symbol.Fusion.WLAN.WLAN command = null;
try
{
command = new Symbol.Fusion.WLAN.WLAN(FusionAccessType.COMMAND_MODE);
command.Adapters[0].PowerState = Adapter.PowerStates.ON;
}
catch (OperationFailureException ex)
{
//do something...
}
finally
{
if (command != null)
command.Dispose();
}
}
It simply enables the first adapter it can find. Non-of the real adapter is testable.

So if this were a device test project, we'd have to mock out the adapter by hand, then pass it in to the constructor to the MotorolaMC75WLAN class. But as we have decided to use a desktop test project we can use any mocking framework that we choose which enables us free of having to do the laborious hand mocking work.

You can download Rhino Mocks from here if you don't already have it: http://www.ayende.com/projects/rhino-mocks/downloads.aspx. Download the zip and extract it somewhere on your hard disk, then add a reference the Rhino Mocks assembly in your test project - there is only one dll you need to reference.



Add a
using Rhino.Mocks;
to your test class. Now if you wanted to mock out the adapter Enable method, in Rhino Mocks world it could look like the following using the newer triple A syntax:
[TestMethod]
public void ShouldEnableWLAN()
{
IMotorolaWLANAdapter _mockWLANAdapter = MockRepository.GenerateMock<IMotorolaWLANAdapter>();
IWLANService _wlan = new MotorolaMC75WLAN(_mockWLANAdapter);

_mockWLANAdapter
.Expect(x => x.Enable())
.Repeat.Once();

_wlan.Enable();

_mockWLANAdapter.VerifyAllExpectations();
}
So the only actual thing we are testing here is the real MC75 WLAN class and not the adapter. The code is fairly easy to read. We are simply telling Rhino Mocks to expect exactly 1 call to Enable() when _wlan.Enable() is called. The thing to bear in mind here is to ensure your actual adapter doesn't contain bugs as we can't automate those tests on the build server.

There you have it, a true mocking framework put at use in the mobile space.

If you want to learn more about mocking frameworks, use Google, there are millions of articles out there on the subject.

Thursday, July 01, 2010

Automated testing considerations for enterprise Windows Mobile projects - avoid a world of pain

I know in the past I have written blog posts on how to create unit tests that are actually executed on the Windows Mobile emulator which is great if you have mobile specific tests. But to be honest, when you are building large scale enterprise mobile solutions targeting a range of different devices i.e. Motorola, Casio, Intermec etc. Writing device specific platform tests for all these devices becomes quite hard to automate when using an application lifecyle management solution such as Visual Studio and TFS with its continuous integration and automated test execution support.

Even if you only support one type of device, when you do enterprise mobile development, using the tools mentioned above, you're not going to be able to automate those tests as part of a nightly build or even a CI build. As you will no doubt be using the vanilla Windows Mobile Emulators that know nothing about such specifics that you might be testing such as barcode reader, credit card reader, bluetooth stack etc. Instead you would normally write adapters or mock out implementation code when testing your barcode implementation. You'll generally never write an actual test that calls the true native code on that platform, why would you anyway unless it's part of an integration test. Ensuring you do this allows you to write unit tests, integration tests that do run as part of your nightly and CI builds that do improve code quality.

So what type of tests should you write for most of your code base, device or desktop? My advice is desktop even if you think your device project is small, there will come a time when your project becomes large and more complex. The benefit to targeting the desktop is the ability to use mocking frameworks. We tend to use Rhino Mocks and today there are 0 mocking frameworks available on the CF. If you start to go down to road of writing your own mocks, then you're entering a world of pain. When you think of it, most code can be tested on the desktop anyway. For things like data access, if you use SQL CE 3.5, then this can run on the desktop. For the features that require explicit device testing, then create a single device test project for this purpose and exclude it from the build definition.