This is a companion post for my talk at Wellington's SLAMD user group on 6 July 2011.

Recently I took part in Nigel Parker's "Release an App for Windows Phone 7 in 7 Days for a Chance to Win a New HTC 7 Trophy Phone" competition, with the intent of winning a Windows Phone 7 device. Although I didn't manage to win the device, I did get a free 1 year subscription to the App Hub, allowing me to develop and submit apps that I build, had fun doing it, and learned a few lessons along the way. This was my first exposure to the WP7 development ecosystem, as well as my first excursion onto a mobile platform in general.

So what follows is a few lessons that I would like to pass on about developing a windows phone application. First though, I will give a quick overview of what exactly I built. The brief was simple, build an application, and have it live on the marketplace by the 6th of June. Not that big of a task, really. The point of this exercise was to both boost awareness of the new development tools, and to increase the footprint of New Zealand-built apps on the marketplace.

'7 days' was a bit of a guideline really, as the competition ran from the 16th May, but this gave time after your 7 days to get it through the approval process, get your account validated and active, and still have time to fix anything that stopped it getting approved first time around. So I came up with a great idea, for a spacies-type game where the main character was a bottle of sauce, defending his kitchen against an invasion of bacon. Bacon Vaders was born. With an idea in hand, the very next thing to do, of course, was to grab all of the developer tools and sdk. This brings me to Lesson number 1.

1) Tools only work on Windows Vista and Windows 7

This was a bit of a problem for two reasons. The first is that my primary portable solution is my EeePC. It is perfectly practical for taking my development with me, and has been my PC of choice for presentations. The only catch is that it is running Windows XP. I am keen to find out if it can handle windows 7 and still be a functional dev machine, but the cost of upgrading when XP works perfectly fine has held me back. Lucky for me, my girlfriend also has a Netbook, a newer one, and it has Windows 7. Portability problem solved. Problem 2, this restriction means that it also doesn't work on Windows Server 2008 R2. If anyone was wondering, that is the OS running on my office machine.

Hmm, so can't do any dev at work either in my lunch break or before I head home. I'm sure I'm not the only developer who thinks that developing on a Server makes heaps of sense, but I guess they don't expect that developers of web applications, deskop applications and web services ( + any database solutions) will want to develop for the WP7. Well its lucky that my gaming machine is running Windows 7 then, so I can use that for the majority of my coding and testing.

So with the environment set up I was ready to start coding. With the help of my sister creating the graphical images and characters, I had a playable version of the game working by the end of 5 days made up of a weekend, and a couple of late nights after work. But as with anything new, there were a few bugs and oddities that had to be worked through to make it presentable for the marketplace.

2) Tombstoning

If you had been following any development blog or message boards around Windows Phone 7, you would have heard the term 'Tombstoning'. This is the way Window Phone 7 handles not having multitasking (at least for the first release, Mango improves upon this model). There are several scenarios where this occurs. The simplest way to demonstrate the tombstoning behavior is to press the windows key on the device while your application is running. This puts it into an out of processor state. If memory is needed, then your application will be closed completely. This is tombstoning. If you come back before this happens, everything is exactly were you left it. If you come back after tombstoning, you get to come back to the same page or screen, but you will have to do some work to continue where you left off.

Luckily, you can be notified when your application is tombstoned, and write code to save any important information, that you might need to use to bring it back up again. After much trial and error, I was able to get my game to behave how I wanted it to. rather than rely of specific Tombstoning information, I decided that if you were playing the game, and you left the in game screen in anyway, the current level state would be saved. Then, whenever you return to the page, either with resume from the menu, or using the back button, the level would resume itself. Even if tombstoning hadn't occurred, the same code can be used to refresh the page, and then resume the game.

After tombstoning, the rest of the application came together pretty easily, since it was simply Silverlight, and I have plenty of experience building silverlight apps. I wasn't using any networking, any complex configuration, saving or loading. I wasn't even doing anything overly complex with the game loop. The next lesson didn't crop up until closer to the end of the project.

3) Games vs Apps

As you might know, the phone allows for two categorisations of Applications, apps, and games. Both can be pinned to the tiles screen, but the first appears in the applications list (to the right of the tiles screen) and the latter is on the Games Hub. So how do we get it there? Here comes a three part lesson learned.

Part 1, how to set where your application ends up? In the solution, when you create a new Silverlight project, the file WMAppManifest.xml is created in the Properties folder with the setting Genre="apps.Normal". If you set this to apps.games, your application will be place inside the games hub. Alternatively, when you create a WP7 XNA application, you will have apps.games, and by changing to apps.normal, you will no longer be placing you xna application in the games hub. One thing to note here, is that this does not affect the categorisation of you application, this is done during the submission process.

This brings me to part 2 of the apps verses game lesson: icons. When you create a silverlight wp7 application, you get an image in the project called ApplicationIcon.png, with a resolution of 62x62. This is the size of the icon in the applications list. However, when you create an xna application, you get a GameThumbnail.png, which is 173x173. There is a really good reason for this: in the Game Hub, games get bigger icons. This means that if you start with a silverlight application, and change its genre to apps.games, you get a distorted icon, as the phone tries to stretch the 62x62 icon to the 173x173 size. So you need to make sure that you make the image for the icon a 173x173 image, if its a game.

A side note here is that a separate image is used for the tile background, but this too is 173x173. What makes this a bit of a problem is part 3 of the lesson. In the emulator, you only get a subset of the phones functionality. The emulator doesn't include the Games Hub for instance. This means that once you set the application to become a game, you can no longer launch it from the phone, without starting it through Visual Studio. This relates to the last bit, because without looking on an actual device, you might not notice you need to change the icon size. This is what happened to me before I tested it on an actual device. The next lesson is also as a result of finally testing on an actual device.

4) Performance

There are a few things to know about the emulator. 1, it performs better on the cpu then the actual device will. 2) sometime graphics processing will be better on the device then on the emulator. This all comes down to a very simple lesson, always test on a real device. I noticed that my application was not running smoothly on a real device, and made a few enhancement to improve this.

I was ready to submit. I filled out all the details, had a activated account, sent through all my verification details, and submitted my first draft of Bacon Vaders. After a few days I had my response and my next lesson. I failed validation.

5) Contrast

If you have played with the phone, or the emulator, you would see that there are two basic themes to the device, light and dark. From silverlight, this theme is used for the font color, and backgrounds. many theme resources are available to use when you need to set the colour of something, including the accent colour. Unfortunately, I didn't use these. I failed the validation because when you put the phone in light mode, you couldn't read some of the text, since I had made a few rectangles with either black or white translucent colours, instead of using the provided theme resources. So I quickly fixed this up, and got my application resubmitted. This time it passed, and now my app is available on the marketplace. For more information about the specifications that are tested against, check here.

6) Silverlight for Games

There are a few issues with the current version of my game. I have some performance issues with my game loop. This brings me to my second to last lesson, building games in silverlight. If you are building a simple game, without any real-time processing, or a nominal gameloop, you can build games in silverlight, especially if you want to rely on the animations, UI dynamic layouts and simple 2D graphics that it provides in a nice API . If you need a gameloop, however, XNA can do all the heavy lifting for you. And if you want to do 3D on the phone, you will certainly want to use XNA. Of course, now you can get the best of both world with using XNA and silverlight together on WP7 Mango. If I built this again, I would most likely use XNA to do it, but for this short build-time project, I had to go with what I knew.

7) Tasks on the emulator

Some things I have come across since finishing, while trying to add a few tasks to my application, such as rating, links to my website, and integrated sending feedback/bug reports, have been interesting discoveries. This relates to the Tasks in the API, and to the hubs and built in applications. I wont go into too much detail, but you can basically use the tasks as a backdoor to access the hidden hubs. From there, you can set up an email account or two, as well as a few other settings, and then get a lot more functionality out of the tasks. More about this can be seen on this blog post.

So there you have it. 7 lessons from 7 days developing an application for Windows Phone 7.