Despite my misgivings, I decided to give Windows Phone 7 development a try. The experience was bad in ways that I did not expect, and good in some areas that I had been concerned about.

The good

The transition to Silverlight

First and foremost, I was wrong about something that I had been very outspoken about: For the most part, Silverlight is not the weak point in the development chain; the Silverlight experience was actually tolerable. Is it perfect? No. Am I now a Silverlight expert? Not by any means. But I have learned in the last several weeks that the amount of Silverlight needed to hash together typical business applications is minimal.

Coming from a WinForms background (with only one minor WPF app under my belt), the transition to Silverlight isn’t bad — you can even still follow the WinForms paradigm if you choose. In a nutshell, the Silverlight ecosystem is filled with folks who really like to talk patterns and practices, and from reading their stuff, it sounds like using Silverlight without following stuff like MVVM will kill you. The reality is, it won’t.

Silverlight’s supporting technologies
Working with Silverlight’s supporting technologies, such as RIA Services and WCF, isn’t as bad as I thought it would be based on the live demos I’d seen about the technologies. Thanks go to TechRepublic reader Terje Bergesen, who set me straight with his top flight tutorial on using data services from Silverlight.
Silverlight tools in Visual Studio 2010

The Silverlight tools in Visual Studio 2010, combined with the Windows Phone 7 development tools, were smooth and functioned just fine. Before I installed the Windows Phone 7 tools, I was concerned that it would install Express versions of Blend and Visual Studio even though I had full versions of both products. Happily, it detected my existing installations and did not install the Express versions side-by-side. This needs to be clarified on the development tools website.

Unfortunately, that is where the good news ends.

The bad

The APIs

The first problem I encountered was that the APIs lack the ability to do many useful things. To be frank, the APIs stink. I was really excited about my original application idea because it addressed my need for an autoresponder for text messages that would also disable the phone’s volume while it was on. It drives me nuts when people send me text messages while I’m driving, because I’m tempted to read and answer the messages, but I know that is really dangerous. I was sure that this could be done because I had been to Windows Mobile 6.5 presentations that showed how to send and read text messages, work with the phone’s settings, and so on. While Windows Phone 7 is a new platform, I couldn’t imagine that it would be less capable than Windows Mobile 6.5.

It’s not a phone platform

It turns out that I was wrong. From the developer’s standpoint, Windows Phone 7 is not a phone platform. It is a Silverlight client (missing a lot of Silverlight’s current functionality) with access to the phone’s sensors (compass, microphone, accelerometer, GPS). Any of the things that one associates with a cell phone (other than the vibration device) are inaccessible to your application. Instead of having an API for actually working with text messages, the contacts list, the camera, phone calls, and so on, you have the ability to start those applications and sometimes get results back from them after the user takes some action.

For example, your application cannot send a text message, but it can start the text messaging application and pre-populate the “To” and “Body” of the message (as far as I can tell, there is no way to send pictures or movies — even those are supported by the phone). Or to work with the camera, you can start the camera application, and if the user takes a picture, your application is given the picture information afterwards. This limitation rules out entire categories of applications — the kinds of applications that leverage the innate properties of a phone.

It’s really ironic that Microsoft is pushing the Reactive system for Windows Phone 7, using it as the preferred way of working with the sensors. It would be an ideal way to work with phone calls, text messages, and other system events to put together some outstanding applications… if only the phone allowed you to do so, and if it was multithreaded so you could have applications running in the background.

If you plan to build a Windows Phone 7 app that depends on phone functionality, I suggest that you really study the API documentation before you commit to the project. Chances are, you won’t be able to write the app you want.

Developing my Windows Phone 7 app

I was in a hurry to at least write something but I knew that I had to scale back my plans dramatically, so I headed to to see if I could find any data services that I could build an application on. I did not have the time or resources (namely, the server resources) to put together a Web service that did anything useful on the server side. I found a Web service for getting the status of U.S. airports, and it looked easy enough to work with until I hit yet another snag: Silverlight works really great with SOAP Web services, but not so great with REST.

When I did some research on using REST in Silverlight, everything I found said that I needed to get a connection to the service and manually parse the XML and look for what I needed. To add insult to injury, Windows Phone 7 does not support the WCF Data Services stuff out of the box! There is a decent OData-capable library on CodePlex; unfortunately, it has a major shortcoming: It does not support authentication. Since there are not many Web services that are exposed to the Internet that do not require authentication, that renders it useless in far too many circumstances, and you are in the cold.

For my application, I decided to play it quick and dirty and use WebClient to download the data, pop it into an XDocument object (it would never be too large, 2 KB max), and use LINQ to get what I needed from it. And I hit yet another snag. It turns out that someone at Microsoft decided “thou shalt call thy network services asynchronously.” I get it — they don’t want someone jamming the phone up for 30 seconds waiting for a server to time out, or a few minutes downloading a big file — but I believe that decision should be up to the application developer not the operating system. Instead of using a simple call to WebClient.DownloadString(), I was forced to use the less direct asynchronous model, which really makes the code ugly and more difficult to debug and maintain. To make matters worse, the Reactive stuff would have been great here, but it only works with some of the sensors at the moment, so it was out of the picture.

Another cautionary note: The Windows Phone 7 development templates are extremely conservative in the default references in a project in comparison to WPF or WinForms applications to save resources. It is sometimes unclear whether you cannot work with an expected piece of functionality because of a missing reference, or because Windows Phone 7 just does not support that functionality. The documentation is your friend here.

Once I overcame these minor hurdles, my Airport Status Checker application was easy to pull together. I posted the Airport Status Checker application under the MIT License, so you can take a look at the code.

In the second installment of this two-part series, I’ll discuss what it is like to work within the Windows Phone 7 ecosystem in terms of getting support and having your application published.

More about Windows Phone 7 development on TechRepublic


Disclosure of Justin’s industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.