XAML as a mystical experience, Pain Level transcendent

As I’ve blundered through learning XAML in Silverlight 3, 4, 5, WPF, WP7, and now WP8 and Win8, it has always been a painful experience.  I recall the very first time I saw XAML and thought “Oh, no – I’m going to be staring at the ugliness of XML angle brackets for the rest of my life”.  But the promise of portable UI components and a nice designer in Blend made me persevere.  Until now.

Sure, one can eventually achieve guru status and understand all the various binding quirks of XAML and be wonderfully productive.  But for average programmers like me, the pain has always been excessive.  Keeping track of which XAML features are available on each platform is a headache.  Writing pages of XAML to do something simple like changing the background color of a control is a test of one’s faith.  From:  http://www.zagstudio.com/blog/1314#

If we attempt to use the styles and templates from our earlier WPF example, we quickly discover that WPF XAML is incompatible with Win8 XAML in a few places (mostly the same places as Silverlight):
• DataTemplate doesn’t have a DataType property. Instead, we have to refer to DataTemplates explicitly by x:Key.
• ControlTemplate doesn’t have a Triggers collection. Instead, we have to use VisualStateManager to control the appearance of selected and unselected items through visual states.
• Canvas doesn’t support the Canvas.Bottom or Canvas.Right attached properties. Instead, we must use Canvas.Left and Canvas.Top to position child elements.
• Various other properties have been moved, simplified, or eliminated.

So, my new resolve is to do as much as possible in code.  Fill up my code behind files.  Write more foreach loops.  At least I can see what’s going on instead of relying on XAML magic to do the right thing.  Hopefully multiple platform support will actually be simpler.

Surface and GPS, Pain level 5

Incredibly, neither the Surface Pro nor Surface RT include a GPS.   Somehow almost every $300 7” and 10” Android tablets can include this feature, but it wasn’t deemed critical to include in a Surface.  DOH!

Monthly Developer Registration, Pain level 7

I recently took the Victoria Clipper from Seattle to Victoria, planning to use my laptop en-route to do some work during the 3 hour crossing.  A few minutes into the trip, I’m confronted with the monthly dialog to “renew” my development license.

This monthly annoyance suddenly became a major pain since I can’t do any more development until I get an internet connection.   Why exactly?  At the very least, why not a few days grace period.  Good job annoying your developers!

Windows 8 Sample Code, Pain level 6

The Windows 8 sample code is designed in a modular fashion which makes it easy for Microsoft to add new pages or “Scenarios” to demonstrate various features of the new Win8 APIs.  While there is a bunch of nice demonstration code, it’s really not written in a fashion which encourages easy borrowing.   The user interface of the “scenario” is all jumbled up with the APIs being demonstrated, so now each developer gets to go through the pain of rewriting the code into a useful format.

Instead of a nice “SampleBackgroundDownloader.cs” class that has 95% of the features each developer would need which is called from the UI code, everybody gets to tear apart “Scenario1.cs” toss out the UI and logging code and rewrite it mostly from scratch.  More pain!

No ZipArchive in WP8, Pain level 4

Every 6 hours or so there’s a wonderful new compatibility puzzle to solve.  Win8 has ZipArchive.  WP8 has none! 

What should I choose as a substitute? ZipCompress (solo developer, recent updates, but not spending much time on the project), DotNetZip (no updates for over a year), SharpZipLib-WP7 (no updates for 2 years), or something completely different?

The GetResourceStream() method shown here doesn’t seem to work for large .zip files, presumably because it’s using a MemoryStream internally leading to OutOfMemoryExceptions.

GeoPosition and GeoLocator, Pain level 5

Of course you needed to rework the WP7 GeoPosition and GeoCoordinate structures for Win8 and WP8, breaking all of our existing code!  

Fortunately Adam Denning wrote a nice blog post explaining the differences but why-oh-why did you need to make all the replacement classes sealed with no setters?  Now it’s impossible to serialize and deserialize these objects, forcing everyone to invent a duplicate replacement class for persisting routes and courses.

DOH!

Portable Class Libraries, Pain level 5

While Portable Class Libraries are great in theory for sharing code across Win8 and WP8, in practice they’re severely limited by the classes which can be referenced.   The BCL should be segmented at a lower level to make simple non UI classes like Point and Rect available.

IValueConverter incompatible, Pain level 3

Win8 seems to randomly break IValueConverter by making the last parameter a string instead of CultureInfo!  I haven’t found the correct way to fix this, but at least this compiles Win8 and WP8:

public class BooleanConverter<T> : IValueConverter

{

    public BooleanConverter(T trueValue, T falseValue)

    {

        True = trueValue;

        False = falseValue;

    }

    public T True { get; set; }

    public T False { get; set; }

    public virtual object Convert(object value, Type targetType, object parameter, string language)

    {

        return value is bool && ((bool)value) ? True : False;

    }

    public virtual object ConvertBack(object value, Type targetType, object parameter, string language)

    {

        return value is T && EqualityComparer<T>.Default.Equals((T)value, True);

    }

#if !WINFX_CORE

    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)

    {

        return Convert(value, targetType, parameter, "");

    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)

    {

        return ConvertBack(value, targetType, parameter, "");

    }

#endif

}

Platform fragmentation, Pain level 7

Sure, any platform over time will begin to fragment, but Microsoft seems hell bent on ensuring minimal portability of source code across their recent platforms. Whereas 1992 source code written for Win32 can be recompiled and run without modification throughout the intervening years, the same cannot be said of code written for Silverlight, WPF, WP7 and now Win8 and WP8.  

The half life of supported development platforms has fallen precipitously.  Silverlight, dead.  WPF ailing, WP7 obsolete, and the newcomers Win8 and WP8 proclaiming themselves the new shining path going forward. 

But developers are now gunshy and looking elsewhere, having learned through painful experience that Microsoft seems unable to commit to a coherent, long term development strategy.  Presumably this is an outcome of the org chart from the last decade:

One would have hoped that C# and the painfully verbose XAML would form the foundation of the future, but then COM and  C++ were confusingly resurrected, and we’re all invited to enjoy sprinkle our code with pointy hats:

 task<IVectorView<StorageFile^>^>(picker->PickMultipleFilesAsync())
      .then([this, uri]  (IVectorView<StorageFile^>^ files)  

Or we can learn the joys of non-typesafe code by switching to javascript and CSS for coding our Win8 UI (but not WP8!).

Since C#, javascript, and C++ and associated controls and libraries aren’t compatible for developing applications across Win8 and WP8, the future for Windows developers will be one of continued pain. 

…none of the crazy you get from too much choice.

Windows 8 and Windows Phone 8 Pain Log

I’ve been a Windows developer for just about forever, and since my pain threshold has just been exceeded attempting to port existing code to these new platforms, I’ve decided to share my agonies as a form of therapy.

Each item will have an associated numeric Pain value of  1 to 10, with 10 being extreme, out of one’s mind pain.

This should be fun!