Over the weekend I was working to make WP7 more useful as it were, but all I have is scars to prove that I fought with the platform. Here’s a mini-selection:
All your IApplicationBars Belong to Us
What's the point of having an IApplicationBar interface, when one must use one and only implementation provided in the box. Yes, I'm aware it's rendered “natively” and not by Silverlight, so I'm not even asking for a bindable version.
Become Hostages to PhoneApplicationFrame and PhoneApplicationPage
These two classes encapsulate the only way to get phone hardware/application specific notifications for three things, namely:
1. Orientation Changes
2. Back-Key Press
3. Obscuration Changes
And what I can't understand is why not treat these hardware/application notifications like say the Accelerometer or GPS or Push Notifications. That way you won't be tied to any specific use-case, unless of course Microsoft's pre-envisioning department had pre-envisioned all use-cases. Similarly, the only other things an PhoneApplicationPage provides is getting/setting ApplicationBar, Support Orientations, and State, all of which could be / should have been done using attached properties - the right way to bring in case specific functionality.
I Navigate NOT
So, well, you give in and make use of PhoneApplicationFrame and PhoneApplicationPage, and then you just happen to notice that you can change it's navigation behaviour since it implements INavigate interface.
Oh not so fast, if you provide your own implementation it just takes away all phone specific functionality, so for example ApplicationBars are rendered useless even though you have the entire infrastructure as required in place. Again what's the point of abstracting INavigate when you mandate the use of one and only self-anointed implementation.
On a related note, I'm not going to rage on the stupidity of having to respond to a Navigation request with an inline response, given Silverlight by design only supports non-blocking calls - so for example if you wanted to properly save something back to the server before navigating away, good luck with holding the fort with Thread.Sleep(1000) loops.
What's that Gesture you are making?
I don't know, but given the primacy of touch input in modern phones, you'd think gestures would be as natural to WP7 phones as say butter is to bread. Well, or at least Microsoft would like you to think so, they've got an entire namespace dedicated to gestures. Except they had the good sense to internalize it completely, so it's good enough for use by their two premier gesture-driven controls but not for direct use by developers. Wonderful.
Default Task > Root Visual
One of worst paradigm I've seen in WP7 is the idea of having a default task – the idea being SL will execute a specific task when the application starts, and in all cases (i.e. no extensibility) it would try and navigate to "MainPage.xaml" and if that doesn't take effect within 10 seconds it will kill your application. The definition of this task is nicely tucked away in the manifest file, with a warning to boot:
I can see the broader need to ensure an application is responsive, but to me this technique is absurd as an app could easily come unstuck past the first navigation, which as I understand is also monitored for, so why double do it. Secondly, without locking one into a navigation-only approach, Silverlight's original set-once RootVisual model worked well - it at least gave you flexibility let alone the idea of extensibility.
Bigger Picture
To me some of these things show lack of critical thinking or worse a "I know best" mindset. Silverlight or broadly WP7's application model is as it is a highly constrained platform (just look at the "can I" questions on the WP7 forums), and chocking innovation/ideas other than the ones presented out of box is stupidity given the marketplace challenges WP7 faces. Obviously, I'm biased in my assessment, but for a comparison look at the approach MVC took in building their platform - almost everything is extensible or substitutable, and the reward, greater involvement and innovation through the community to the point where MVC 2 and the Razor View-Engine have been directly inspired by the work done by the community. Or then again we can just choose to live in the sandbox that Microsoft prepares.