Windows Phone 7 experiences
June 13th, 2011I took part in University of Helsinki’s Windows Phone 7 code camp. The aim was to develop applications quickly, in one week, and demonstrate them. And naturally learn something from C# and Windows Phone 7 platform. Yep, unluckily we didn’t have the newer Mango-release in use, so some of my comments might already be deprecated.
My uttermost experience is that the platform is still half way there. The API access is not so good that I wished it to be, and actually my initial application idea cannot be implemented in Windows Phone 7 as I don’t have access to data. Let’s just hope that there will be significant progress in this area. For this post, I share some of the core experiences.
Launchers and chooser kill innovations
Microsoft has decided accessing core mobile phone functionalities, such as sending a SMS or picking a contact, must be done via openers and choosers. The main argument for this design decision is security, this way 3rd party application developers can’t do anything nasty with users’ data or use costly features.

I accept the security comments, however the problem that this practice means I don’t control the interaction flow and in the end it means I cannot create a holistic experience. As an example, an application that would send an SMS automatically is impossible, you need to use a specific launcher and wait for user’s to press send button. However, for a taxi ordering application I would make the user flow so simple that user just needs to press one big button. You know – Friday evening and you’re hardly standing…
Second comment for this is, that the choosers and openers may be designed for a specific purpose only and not kept in mind we, the developers, might want to do hacks and things like that. Here a good example is contact chooser, or as they put it: EmailAddressChooserTask or PhoneNumberChooserTask. What if I would want to use the profile icon from contacts? Why isn’t there just a ContactChooserTask that would return me a contact object?
C# has inconsistencies
One thing I observed was language inconsistencies in C#. This sounds like a small thing and surely it is a minor detail. However, let me just pinpoint this, as I got some gray hairs from this:
Let’s assume you want to disable a button. It’s done by button.IsEnabled = false;
Now let’s also assume you want to make the button invisible. How would you do it? button.IsVisible = false; would be my first guess, but no. It is button.Visibility = false;
Gimme beautiful and powerful UI widgets!
However, syntax is always syntax. Let’s not worry about that. However, based on my experience, making a beautiful interface with fancy animations and nicely shaped elements requires “a few” additional steps. And, unluckily these additional steps meant for me that there were no fancy effects or dialog box or anything else cool. If you wish to get some deeper understanding, look at iOS guidelines.

Conclusions: Quick and Dirty
Based on this experience, the toolkit allows quick and dirty applications, but building “a proper” application might be more complicated. There’re cool ideas, such as the application being just XAML pages and that data can be binded to interface.
However, the overall experience is that things are dirty hacks that are kept together with glue. And, it’s not a good feeling for serious application developers.