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.

Well, I've spend quite a few hours with the Windows Phone SDK, Expressions Ultimate and Visual Studio 2010 over the last week.  The bottom line is that in spite of some very nice elements, the available assemblies (libraries) for Windows Phone display a distinct rush to market.

My princpal complaint are the egregious limitations on XAML in the WP7 SDK.  I wrote a fairly interesting media player application in WPF and came to respect and appreciate the data-centric WPF model.  After a few false starts I had an app that responded automatically to changes in the core datasets of the program.  The key to this was data triggering of XAML styles.  But guess what-- DataTriggers are not available on WP7!  Microsoft continues to ballyhoo "model-view-controller" (MVC) methodology and praise data models, but without DataTriggers you cannot write a truely MVC application for WP7. 

For example, to load a ListBox in "real" WPF you can specify the styles of the items, their containerization and visibility entirely from the data, using Binding to apply the content and DataTriggers to control both styling and structure through templates.  This is exactly what is needed in many cases.  In fact, it was exactly what I wanted for the WP7 app I want to write.  Instead, I'm left with the need to write oodles of plain old C# code to create listbox items, nest them and add them to the appropriate list.  This is very 1990's-style graphics development.

I have other beefs.  Why, pray tell, can you not persist IsolatedStorage elements across debugging sessions?  In my app I want the user to configure a list of sites.  I'll have to do that manually every time I restart the emulator!  This is very serious and seriously stupid.

As mentioned in a previous blog, the WP7 SDK is crippled with regard to sockets.  I had to write a proxy web site to perform standard operations (like ICMP ping) that the WP7 cannot do.  As I wrote before, I'm very suspicious the motivations for this.

Given the crippled nature of this release, I'm seriously debating waiting until a future release to get into WP7 development.  Microsoft has had years (and years) to get this right.  It's looking as though it's heading the right direction, but it hasn't reached critical mass yet.  IMHO.

I just installed the Windows 7 Phone SDK and all is component parts, which was a long but easy chore.  Well, the first time it hung forever and I had to remove a bunch of components before it would install correctly.

The process of getting a simple phone app built and running on the emulator was about like I expected.  I already learned basic XAML programming, and I found nothing extraordinary about the Phone classes (so far).

However-- (big pause) The level of support for real network programming on the WP7 is abysmal.   First, you can only use the WCF "service" model, which currently only runs over HTTP.  In other words, you must have a server hosting a WCF service or no go.  The claim (see this forum among many others) is that resource-poor Microsoft didn't have time to test sockets correctly before releasing this still-wet-behind-the-ears new product.  Maybe so.

On the other hand, maybe their urgent desire to establish Azure as the cloud platform of choice had something to do with this.  If you can't do your own networking you're forced to rely on hosted faciliies, either web servers or cloud communications.  Either way, Microsoft gets more money from you.  

Since HTTP runs over TCP and HTTP is supported in its web browser, I sense something altogether fishy in Microsoft's limitations for this first version of the WP7. Why couldn't they simply allow synchronous (blocking) communications over single TCP sockets, which is probably what the built-in web browser is doing?  Reason-- because they want to kill peer-to-peer.

What really (really) concerns me as a civil libertarian is that this coincides with ongoing, onerous attacks against peer-to-peer operations from both government and big business.  I sense that there are deep, powerful forces at work that want to work with ISPs to "white-list" the internet and kill peer-to-peer operations.  The crippled version of the WPF7 may just another example of a product brought to market too soon.  Or it could be part of a larger, decentralized effort to kill arbitrary point-to-point internet connections.  Government wants to monitor everything, and PTP is messy to monitor.  Businesses assume everyone doing PTP is an IP pirate and want to block it all.   Now, arguably the biggest product launch of the year for a smartphone fails to include the most basic communications capability for the internet.  Accident?  Hmmmm.

Suffice it to say that without sockets or multitasking, this product is more a toy than a platform.  On the iPhone, most people run their applications an average of twice.  Microsoft seems to be depending on games and social networking sites to drive WPF7 sales.  They will probably fail.

After my last post, I continued to fiddle with my TVersity configuration.  What I found was that the Shark007 codec packs really do the job. 

Follow their instructions carefully.  You'll need to remove all other codec packs (they recommend even uninstalling TVersity's built-in codec pack).  Then install the 32-bit version, then the 64-bit version.  After I did that, I could play anything (even MKV videos) through TVersity using the DirecTV MediaShare or with Windows Media Player.   Since I haven't had good luck with Windows Media Center, I haven't gotten around to testing that again.

Another useful tool is the Win 7 Direct Show Filter Tweaker.  It allows you to control which codecs are invoked by DirectShow clients, both 32-bit and 64-bit.  It also allows control over the new Windows 7 "override" codecs (those used to create icons and play media through WMP and WMC).  I used this to force my DVIX and XVID to play through ffdshow.  Since Shark007 is really a repackaged version of ffdshow, you'll see that name among the alternative codecs for most of the popular video formats.

I haven't tried streaming Dolby or DTS since DirecTV MediaShare doesn't support anything but stereo (AFIK), so I can't vouch for that capability.

I did see TVersity die once, but I have a simple batch script that checks to see if it's running and restarts it if it's not.  Time will tell how often this is necessary.