Well, my pseudo-dummy Windows Phone app is almost done. As a proof of concept, it falls quite short since sockets aren't supported in WP7. However, I thought I'd blog again to review the good, the bad and the ugly.
First, the good. Many things do work. Since WP7 and Silverlight 4 are build on XAML, databinding does work, so all of reflection, etc., also must work. Most of the other usual supects work, such as Regular Expressions. I found (again) that the new XDocument classes are a treat to code for and serialization works very weil. My whole app's state and all current data are just swooshed out to Isolated Storage and back in again via serialization. I think it's almost a necessity to have Expressions 4 along with Visual Studio, and bopping back and forth between them is old hat for me by now. C# is still the best language (for its class) out there, and Linq is supported, which surprised me.
Now the bad. Again (from previous posts), no DataTriggers, no sockets. Also, the Emulator doesn't persist app storage across executions, making complex data management almost impossible (who wants to use the cloud just to test?). XAML is still, IMHO, a very near disaster. It's completely un-type-safe, which in 2010 is almost a joke. In addition, the whole process of creating well-behaved property notifications is completely tedious. Since I don't have DataTriggers, I had to work around such common issues as selecting a graphic for an item in a listbox based on conditions. To do this without triggers, I created a pseudo-property called StateImage that my XAML can bind to. This means two things. First, I have to create a bunch of these non-property properties to help the UI work like it should. Second, I have to manually propagate notificiations to cause XAML to rebind. It's about time that XAML and C# supported declarative bindable properties so that OnPropertyChanged, etc., would happen without tedious coding. Maybe I'm missing something. In the same vein, XAML really needs to support more than just public properties. Why can't I pass parameters if they're statically defined, such as integers? Have you actually looked at the stack trace in a data binding call? It's horrendous! If the system were truly type-safe, these calls could avoid the gnarly depths of recursive reflection. Then we'd have the same situation we have in C# 4.0: If you know about the class at compile time, it's type-safe and renders compile-time errors; if you don't it's dynamic and renders run-time errors. XAML these days is entirely dynamic.
Finally, the ugly. There's no popup window! This is nothing short of amazing, but luckily I found a great blog post by Shawn Wildermuth that showed me how to drag in code from Silverlight 3.0, sprinkle some of his sugar on it and produce a nice-looking (and zooming) popup window. I guess the Metro gurus really don't like informative UIs, or they believe we've entered a golden era of failure-free networking.
More ugly: there's no ComboBox! Another delightful broomstick up the **** from the Metro guys. Again, I found a blog post by Alex Yakhnin linking to a download of his PickerBox. While it's still a little error-prone, it generally does exactly what it should. I really have to wonder when WP design people decide that a UI element that is absolutely ubiquitous must simply be eliminated. This is no way to win hearts and minds.
Still more ugly: the ApplicationBar, which is inserted into every WP page's XAML automatically, is really not ready for prime time. First (of course) the UI gods have decreed that there shall be no more than four buttons. OK, I guess that's their job. However, the buttons and menu items aren't Framework Elements, and that means that you can't easily work with them. The namespaces appear to be a little hokey, so you have to qualify things too often. A word to the wise: you'd bettter use the blessed Microsoft ApplicationBar icons or strange things can happen. It's also funny that buttons can appear correctly in Expressions but come up as big X's in the Emulator.
And more. Page navigation is based on a web mode, where pages are represented by URIs. That's OK, but when I want to pass parameters I have to resort to global variables (I just say no) or pass query terms. There's no query term parser, so I have to code all that dreck by hand (thanks to regular expressions). If they really insist on a URI model, why can't there be a type-safe HTTP POST capability that allows one page to parameterize another in a flexible way using serialization?
All in all, there's still the aroma of a rush to market by a team of people too convinced of their own wisdom. I'm not going to sign up as a developer or get a phone until sockets work. I hope.
Subscribe