Windows Phone 7

A project I got to work on recently while working at Universal Music Australia was a Windows Phone 7 application allowing users to download digital music, purchase physical products including CD/Vinyl/DVD/Blu-Ray/Merch/T-Shirts, and get the latest aritst information. This was a great opportunity for us (UMA) as it would allow Getmusic (our D2C eCommerce platform for Australia) to reach even more users and would bring us even deeper into the mCommerce world. The big win for us was that our application would be the only application selling digital music on this device, in all of Australia.

Zune is Microsoft’s counterpart to iTunes and while it’s a great music purchasing service, which also has a much cleaner GUI than iTunes, this service unfortunately, and fortunately for us, is not available in Australia. So we own the digital music purchasing market and Microsoft gets to offer a service for their users to buy music. Win-Win

Getmusic/Zune Synchronization Process

Knowing that the WP7 is a new device with a new OS, we knew there was going to be limitations. A big one was we couldn’t sync the music downloaded from the Getmusic App to the Zune Media Hub library. This means that everytime the user buys music from the application, they have to download the files from the application to their desktop, then sync that with their Zune software so it can be copied into the media hub on their device. A painful process which is going to cause problems and complaints about the app. But there was also nothing we can do because this functionality is blocked by the OS and can’t be bypassed, so we pressed on.

During the 3 months of the development process, it was relatively straight forward. We didn’t hit too many hurdles, just a few speed bumps. I won’t get much into the specifics of the app, as this post is just to describe my experience with the WP7 development and certification process.

What I did like was there was multiple highlights to the application development. The first was how easy it was to setup the layout, styles, and transitions using Microsoft Expression Blend. After talking to the 3 different developers on the project, all of them identified that while you can edit all the needed layout settings from within Visual Studio, Blend did a really good job of giving a GUI editor experience to the application process.

Another positive during the process was how simple it seemed we could add additional features to the application. Now most of this is due to the codebase behind the app, which is mostly C#, but I also attribute this to the OS for the WP7 and it’s integration with the Microsoft desktop applications. During the development of the app, there were a number of scope creep items that we needed add and with the WP7 tools, it made it relatively easy for the guys to accomodate our requests.

But as with all projects, there are many successes, but there were also failures…

We were getting down to the final days of the development process and I was starting to test heavily. I was provided with a WP7 Samsung developer phone so I could see how apps worked within the device and to test our app. While I was using this phone for all my testing, 2 days before we were set to submit the app, the phone stopped letting me test. It was telling me the device wasn’t unlocked to use “Test Applications”. This meant I only had the Windows Phone Emulator to test the app and it didn’t work like the physical device did. Of course this worked to some degree, but it wasn’t ideal because it didn’t give the same memory/connection experience as a true 3G handheld. I emailed my contacts at Microsoft for help and hopefully a solution, but nothing could be done and we couldn’t get it fixed. So I spent several nights working very late because the WP Emulator only works on Windows 7…
my laptop is a Win XP.

Where is all this leading to… one BIG problem that wasn’t seen on the emulator. App Crashing and massive memory leaks!

The second developer on the project, Brendan Forster and I were surprised to see that the app was causing some big memory spikes. In order to help the app pass the certification process, Brendan had to do some serious investigations into the memory issues. After a late night working on his own time and collaborating with a friend Nick Randolph, they found some issues and possibly some work arounds.

After going back and forth with local Windows Phone guru Nick Randolph about the issue, and he blogged about the behaviour in more detail, we came to the conclusion that the garbage collection was not being triggered automatically. That’s not necessarily a bad thing (see the conditions for triggering a garbage collection here) but is a concern for large WP7 applications.

The workaround I devised for this is to trigger a GC.Collect() after a number of page navigations. I would only add this to an application when absolutely necessary. The implementation of this I’ll leave as an exercise to the reader.

They also posted some graphs of the app and its memory useage as we moved about the screens…

Memory Usage

Memory Pattern

I’m going to save all the technical jargon to the professionals who did quite a few tests, but head over to Brendan Forster and Nick Randolph websites for more info on the WP7 memory usage and how it was a problem for our app.

Ultimately, they had to increase the number of Garbage Collections to a more frequent rate than Microsoft suggests, but in the end, they were able to get the memory useage below the 90mb mark and app was certified.

Overall, the experience was good and not too stressful and I see this market growing rapidly and able to compete with the iOS and Andriod market.

Also look forward to a series on my experience with the WP7 Getmusic app development as well as an iPhone Getmusic app. I’ll post a comparitive review between the two and my thoughts on the future of app development vs mSites after finsihed with these 2 series.