With the Windows 8 preview release earlier this week, developers are now faced with a whole new and exciting Microsoft stack. The Windows 8 architecture has something of a split-personality, incorporating a completely new runtime, WinRT together with the older Win32 and .NET framework. However, these sit on different sides of a physical divide in both the architecture and the user interface. For more details of this, see my earlier article.

The new WinRT APIs support both C# and XAML, having an interface that is very similar to its .NET counterparts. However, there are a number of differences, most importantly much of the UI now resides in a new namespace. It is clear that transitioning from Silverlight, WP7 or WPF development to using WinRT will be quite easy.

I am sure there exists classes of application that sit best in the Win8 Metro UI, for which you will use WinRT for development. There will also be classes of application that sit best in the Win8 classic desktop, for which you will still be using WPF and Silverlight to develop.

However … there will certainly exist a class of application that sits well in both the Metro and Desktop environment. In the Win8 preview IE does just this.

This introduces a problem, how can we share code between our Silverlight Desktop and WinRT Metro applications?

I have previously presented talks and written articles on cross-platform application development. So I thought I would grab myself a copy of the Win8 preview release and see how easy it is to code-share between a Silverlight and WinRT Metro application.

This blog post describes a simple TwitterSearch application, the Silverlight version is shown below. Simply type in a search string to see the results retrieved from twitter:

A screenshot of the TwitterSearch application built for WinRT Metro is shown below:

When code-sharing between WPF, Silverlight and WP7 applications separation of concerns and solid design patterns are essential in order to navigate the framework differences. For that reason I use the Model-View-ViewModel pattern, this makes it easy to specialise the view for each platform, where they typically differ the most. I will use this same approach for WinRT.

The code is shared between the Silverlight and Win8 Metro application by having two separate solutions which both share files via the Visual Studio file linking feature.

The TwitterSearchViewModel which backs this application simply exposes a search string property and a list of tweets:

public partial class TwitterSearchViewModel : INotifyPropertyChanged
{
  private TweetViewModelCollection _tweets = new TweetViewModelCollection();
 
  private IMarshalInvoke _marshalInvoke;
 
  private string _searchText = "WinRT";
 
  public TwitterSearchViewModel(IMarshalInvoke marshalInvoke)
  {
    _marshalInvoke = marshalInvoke;
  }
 
  /// <summary>
  /// Gets / sets the search term
  /// </summary>
  public string SearchText
  {
    get {  return _searchText;  }
    set
    {
      _searchText = value;
      OnPropertyChanged("SearchText");
    }
  }
 
  /// <summary>
  /// Gets the search results
  /// </summary>
  public TweetViewModelCollection Tweets
  {
    get { return _tweets; }
    set { _tweets = value; }
  }
 
  /// <summary>
  /// Gets a command that executes the search
  /// </summary>
  public ICommand ExecuteSearchCommand
  {
    get
    {
      return new DelegateCommand(() => ExecuteSearch());
    }
  }
}

The IMarshalInvoke interface allows the view model to perform asynchronous calls via the Dispatcher, without being dependant on this UI class, more on this later.

It is here that I hit the first problem, WinRT has ICommand, but it lives in a different namespace! Time to add a WinRT compilation symbol to my WinRT project and throw in a pre-compiler directive:

#if WINRT
 
using Windows.UI.Xaml.Input;
 
#else
 
using System.Windows.Input;
 
#endif

Now my view model compiles just fine. However, when I hooked it up with the view, my bindings were only working in one direction. After appealing to Twitter, the MSDN forums and the WPF Disciples, Laurent Bugnion kindly informed me that WinRT has two different INotifyPropertyChanged interfaces. One within System.ComponentModel and the other in Windows.UI.Xaml.Data, if you use the one from System.ComponentModel it is ignored by the WinRT binding framework. Very confusing!

Fixing this is simply a matter of adding more platform specific namespaces:

#if WINRT
 
// used for ICommand
using Windows.UI.Xaml.Input;
 
// used for INotifyPropertyChanged
using Windows.UI.Xaml.Data;
 
#else
 
using System.ComponentModel;
using System.Windows.Input;
 
#endif

My original code used WebClient, which is not present in WinRT. Fortunately HttpWebRequest is present in both, so I changed my code to use that, hence the need for the IMarshalInvoke interface to marshal execution back onto the UI thread.

As a result, much of the core logic, which makes use of Linq-to-XML, in the view model is shared between both applications:

/// <summary>
/// Parses the response from our twitter request, creating a list of TweetViewModel instances
/// </summary>
private void ParseXMLResponse(string xml)
{
  var doc = XDocument.Parse(xml);
  var items = doc.Descendants(AtomConst.Entry)
                  .Select(entryElement => new TweetViewModel()
                  {
                    Title = entryElement.Descendants(AtomConst.Title).Single().Value,
                    Id = long.Parse(entryElement.Descendants(AtomConst.ID).Single().Value.Split(':')[2]),
                    ProfileImageUrl =  entryElement.Descendants(AtomConst.Link).Skip(1).First().Attribute("href").Value,
                    Timestamp = DateTime.Parse(entryElement.Descendants(AtomConst.Published).Single().Value),
                    Author = entryElement.Descendants(AtomConst.Name).Single().Value
                  });
 
  _tweets.Clear();
  foreach (var item in items)
  {
    _tweets.Add(item);
  }
}
 
/// <summary>
/// Searches for the given term
/// </summary>
private void ExecuteSearch()
{
  IsSearching = true;
 
  // perform the search
  string uri = _twitterUrl + SearchText;
  HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(new Uri(uri));
  request.BeginGetResponse(new AsyncCallback(ReadCallback), request);
}
 
/// <summary>
/// A callback that receives the search results
/// </summary>
private void ReadCallback(IAsyncResult asynchronousResult)
{
  HttpWebRequest request = (HttpWebRequest)asynchronousResult.AsyncState;
  HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(asynchronousResult);
  using (StreamReader streamReader1 = new StreamReader(response.GetResponseStream()))
  {
    string resultString = streamReader1.ReadToEnd();
 
    // marshall onto the UI thread and parse
    _marshalInvoke.Invoke(() =>
      {
        Tweets.Clear();
        ParseXMLResponse(resultString);
        IsSearching = false;
      });
  }
}

This makes me happy

On a side note, whilst WinRT does not have WebClient, it actually has something much better via classes such as SyndicationFeed which make use of the new C# async and await pattern for dealing with asynchrony. Of course, using these new APIs reduces the amount of code you share with the Silverlight .NET code.

The DelegateCommand implementation again hits the same problem of the same interface being located in a different namespace, yet despite this, most of the code is shared:

#if WINRT
 
// used for ICommand
using Windows.UI.Xaml.Input;
 
#else
 
using System.Windows.Input;
 
#endif
 
namespace SLUGUK.ViewModel
{
  public class DelegateCommand : ICommand
  {
    private Action _action;
 
    public DelegateCommand(Action action)
    {
      _action = action;
    }
 
    public bool CanExecute(object parameter)
    {
      return true;
    }
 
#if WINRT
    public event Windows.UI.Xaml.EventHandler CanExecuteChanged;
#else
    public event EventHandler CanExecuteChanged;
#endif
 
    public void Execute(object parameter)
    {
      _action();
    }
  }
}

Despite the various XAML UI controls being in a different C# namespace, they use the same URIs for their XML namespace mappings. This makes it possible to share XAML as well as C# code between your applications.

However, in much the same way as it makes little sense to share XAML between WP7 and Silverlight due to differences in form-factor and user-experience, I don’t think it makes sense to share XAML between Silverlight and Metro WinRT. The primary focus of the Win8 Metro applications is the touch-first tablet form factor, hence you would expect it to be quite different from a desktop application.

The following is the XAML for my Metro UI application:

<UserControl x:Class="WinRTMetroTwitter.View.TwitterSearchView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:local="using:WinRTMetroTwitter.View"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
 
    <UserControl.Resources>
        <local:BoolToVisibilityConverter x:Key="BoolToVisibilityConverter"/>
        <local:ImageConverter x:Key="ImageConverter"/>        
    </UserControl.Resources>
 
    <Grid x:Name="LayoutRoot" Background="#FF0C0C0C">
        <Grid Margin="50"
              Width="400"
              HorizontalAlignment="Left">
            <Grid.RowDefinitions>
                <RowDefinition Height="Auto"/>
                <RowDefinition Height="*"/>
            </Grid.RowDefinitions>
            <StackPanel Orientation="Horizontal">
                <TextBox Text="{Binding Path=SearchText, Mode=TwoWay}"
                     Width="200"/>
                <Button Command="{Binding Path=ExecuteSearchCommand}"
                    Content="Go!"/>
                <TextBlock VerticalAlignment="Center"
                     Visibility="{Binding Path=IsSearching, Converter={StaticResource BoolToVisibilityConverter}}"
                     Text="Searching ..."
                     Margin="20,0,0,0"
                     FontSize="15"/>
            </StackPanel>
 
            <!-- renders the search results -->
            <ItemsControl x:Name="itemsControl"
                          Grid.Row="2">
                <ItemsControl.ItemsPanel>
                    <ItemsPanelTemplate>
                        <StackPanel Orientation="Vertical"/>
                    </ItemsPanelTemplate>
                </ItemsControl.ItemsPanel>
                <ItemsControl.ItemTemplate>
                    <DataTemplate>
                        <StackPanel Orientation="Horizontal"
                                    Margin="5">
                           <Image Source="{Binding ProfileImageUrl, Converter={StaticResource ImageConverter}}"
                                  Width="96" Height="96"
                                  Stretch="UniformToFill"
                                  Margin="2"
                                  VerticalAlignment="Top"/>
 
                            <StackPanel Orientation="Vertical">
                                <TextBlock Text="{Binding Title}"
                                           TextWrapping="Wrap"
                                           FontSize="15"
                                           Width="300"
                                           HorizontalAlignment="Left"/>
                                <StackPanel Orientation="Horizontal">
 
                                    <TextBlock FontWeight="Bold"
                                               Text="{Binding Path=Author}"
                                               FontSize="15"/>
 
                                    <TextBlock Margin="10,0,0,0"
                                              Text="{Binding Path=Timestamp}"
                                               FontSize="15"
                                              Foreground="#333"/>
                                </StackPanel>
                            </StackPanel>
                        </StackPanel>
                    </DataTemplate>
                </ItemsControl.ItemTemplate>
            </ItemsControl>
 
            <Rectangle Fill="#FF0C0C0C"
                   Opacity="0.5"
                   Grid.Row="1"
                   Visibility="{Binding Path=IsSearching, Converter={StaticResource BoolToVisibilityConverter}}"/>
        </Grid>
    </Grid>
</UserControl>

If you are a Silverlight developer you will notice that everything here is standard Silverlight, it is just wired-up to different classes via the XAML namespace mappings.

I did discover that the IValueConverter signature within WinRT is a bit different. Within this application, the value conversion logic is so simple it is hardly worth code-sharing, however, it would be a very simple exercise if you wished to do so.

namespace WinRTMetroTwitter.View
{
  public class BoolToVisibilityConverter : IValueConverter
  {
    public object Convert(object value, string typeName, object parameter, string language)
    {
      return (bool)value ? Visibility.Visible : Visibility.Collapsed;
    }
 
    public object ConvertBack(object value, string typeName, object parameter, string language)
    {
      throw new NotImplementedException();
    }
  }
}

Finally, I did hit against one further problem. With WinRT it seems that there is a currently a bug which prevents ItemsControl binding to collections via INotifyCollectionChanged from working. This has been raised in the MSDN forums and I am sure it will be fixed. As a simple workaround I added the following code-behind (gasp!):

public sealed partial class TwitterSearchView : UserControl
{
  private TwitterSearchViewModel feedViewModel;
 
  public TwitterSearchView()
  {
    InitializeComponent();
 
    this.Loaded += ResultsView_Loaded;
  }
 
  private void ResultsView_Loaded(object sender, RoutedEventArgs e)
  { 
    feedViewModel = this.DataContext as TwitterSearchViewModel;
 
    // detect collection changed
    feedViewModel.Tweets.CollectionChanged += FeedItems_CollectionChanged;
  }
 
 
  private void FeedItems_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
  {
    // manually 'refresh' the UI
    itemsControl.ItemsSource = null;
    itemsControl.ItemsSource = feedViewModel.Tweets;
  }
}

Conclusions

Creating a cross-platform WinRT / Silverlight application is entirely possible, using the same techniques that we currently employ for cross-platform Silverlight / WPF / WP7 applications. There are further complications relating to classes living in different namespaces and there will of course be other detail-level differences that this simple example does not touch upon. However, I think this presents a feasible and promising route for re-using existing Silverlight/ WPF code, and for developing applications that target the Win8 tablet, WP7 phone and Silverlight (or WPF) desktop with a single code-base.

You can download the full sourcecode: CrossPlatformTwitter.zip

Regards, Colin E.

In this blog post I take a look at Windows 8 on the outside, from a user perspective; and on the inside, from a developer perspective to see how it will change the way we develop with Windows on tablets, smartphones and the desktop when it is released next year.

In Anaheim, California, the Microsoft //build/ conference is drawing to a close. And as the attendees head for home, with their shiny new Samsung tablets under their arms, the news of Windows 8 and the impact it has on end-users and developers is starting to sink in around the globe.

There is no doubt that the impact of Windows 8 is going to be very large, it heralds the biggest change in the Windows architecture since 1993 and from an end-user perspective it is like no other version of Windows before it.

So why such a radical change to both the UI and the architecture? and why now? The answer to this question is quite simple … tablets. Previous versions of Windows have been targeted primarily at the desktop, laptop and netbook form-factors where the primary input devices are mouse and keyboard, and memory, disk-space, CPU performance is aplenty. Tablets have made the odd cameo appearance in the history of computing, but it is only recently with the launch of the iPad that they have suddenly become mainstream.

To take the Windows OS to a tablet it needs to be stripped-down, made faster and support multi-touch (or touch-first – a new Microsoft buzzword) and with Windows 8 Microsoft have done just that. With the requirements of a tablet interface being so different to a desktop, how have Microsoft reconciled these differences? The answer is a little surprising … they haven’t! They could have launched a dedicated Tablet Windows OS, just as they have done on the mobile with Windows Phone 7, but instead they have launched a single OS that works for both tablet and desktop. As a result it has something of a split personality. You can choose to run either the Metro or the ‘classic’ desktop UI on your tablet computer and you have exactly the same choice on your desktop.

An end-user perspective

The Windows 8 user interface uses the same Metro style that Microsoft introduced with Windows Phone 7, bright colours, clean edges, a lack of drop-shadows and other adornments. The style is heavily influenced by fonts and designs used for road and street-signs. The same concepts of clarity-at-a-distance translates very well to a small smartphone screen and should be equally at home on the tablet.

When applications are launched they run full-screen, with a similar multi-tasking model to Windows Phone 7 where hidden applications are suspended. These features, combined with the fast shutdown / restart times make sense for tablet users where limiting the work that the processor does will significantly enhance battery life.

You can run multiple applications side-by-side in a split-screen mode:

The current preview of Windows 8 has a few of the familiar applications available in the new Metro-desktop, these include IE which is now chromeless, i.e. it is permanently in full-screen mode. Gestures are used to reveal the open tabs or URL. Notably the Metro IE does not support any plugins, i.e. Flash, Silverlight – more on this later!

Metro applications for Windows 8 are distributed via the Windows Marketplace in much the same way as they are for Windows Phone (and iPad, Android etc…).

The Windows 8 UI clearly has tablets in mind and recent reviews by Engadget and Gizmodo seem to indicate that the experience is very good and agree that when released it could be a serious competitor to the iPad.

However, hidden behind the glossy Windows 8 UI sits the more traditional Windows 7 style desktop. Simply click (or touch) the desktop button and the old-familiar Windows desktop appears. It almost feels like the desktop is an app running within the new Metro UI – you can also run a split screen which combines the Metro and desktop UIs:

Interestingly if you want to run IE with plugins, there is a fully-featured version of IE present on the desktop. Try explaining these differences to your grandmother!

For a tablet, Windows 8 gives you the best of both worlds, an immersive and tactile Metro interface, plus the old-familiar Windows desktop.

On the desktop, Windows 8 does feel a bit strange. Metro applications are designed to work with the mouse and the keyboard, so it functions just fine, however, on a desktop monitor the Metro UI feels like a bit large and a touch gimmicky. The Metro concepts work well for small screens, but in my opinion are less effective on a large desktop monitor, especially in the absence of touch. I doubt it will make a big impact for desktop users, but at least they have the choice! When used on a PC with multiple monitors the new Metro UI is confined to a single screen, again further illustrating its tablet focus.

A developer perspective

Windows 8 marks a radical change from the outside, but what about on the inside? What is the developer story?

One of the most important diagrams revealed in the keynote is the Windows 8 architecture diagram:

It is clear that the split personality of Windows 8 runs very deep. In this diagram you can see that Metro style apps and desktop apps share the kernel, but nothing else. This is a pretty significant change in Windows architecture; Metro apps are finally free of the Win32 APIs which .NET has been built upon.

The APIs for developing Metro apps reside within the WinRT. A few keys things to know about this new architecture are:

• WinRT applications are chromless, fullscreen, with no pop-up or modal dialogs
• WinRT is an Object Oriented replacement for Win32
• WinRT is very similar to .NET, however a number of APIs such as file I/O, security etc… are not present.
• You can develop with C++, or C# etc… in much the same way as .NET applications
• The UI defined using XAML, as per WPF and Silverlight
• You can potentially port Silverlight applications to WinRT by changing a few namespaces
• JavaScript is a first-class citizen of Windows 8, using a HTML UI

The above already tells us a lot about WinRT and Metro applications. My first thoughts are that they are much more similar to Windows Phone 7 applications than desktop WPF applications. They live within a sandbox which uses a restricted subset of APIs, you certainly cannot write a virus checked or hard disk partitioning tool with WinRT!

Furthermore, when developing Metro UI apps, Visual Studio ‘deploys’ your application too your Windows 8 Metro desktop in exactly the same way as it does with the WP7 phone.

So what about existing .NET applications? The important thing to know is that all the ‘old’ APIs are still there. Your WPF, Silverlight and WinForms applications are safe! There were also a few new WPF features announced at //build/ as part of .NET4.5, but they are not very interesting, it is clear that Microsoft has been putting its energy into other things.

The JavaScript / HTML5 story is a bit of an odd one. Clearly Microsoft has embraced these technologies, with JavaScript having full access to the WinRT. Furthermore, they have added APIs for creating Metro UIs with HTML. However, I am not sure why someone would want to use JavaScript to create Windows 8 Metro applications? The main strength of JavaScript and HTML5 is the portability due to its support on a wide range of browsers, tablets, phones, etc… The Windows 8 JavaScript Metro apps are ‘tied’ to WinRT so are in no way portable.

Questions …

Lots of questions … the rather complicated nature of Windows 8 has resulted in quite a lot of confusion.

Is Silverlight Dead? – this was probably the most oft asked question before //build/ and it is still being asked. The news that the Metro IE10 will not run Silverlight is certainly not good news for the technology, however, it does not mean it is dead – Silverlight is still present in the desktop IE10 browser (as is Flash). Recently Silverlight has been re-positioned as the technology of choice for more complex line-of-business applications, the types of application which sit better in the Windows 8 ‘classic’ desktop. Furthermore, whilst the Metro UI is leading the push into tablet computing, I doubt it will take off on the desktop. So, no, Silverlight is not dead, but it has unfortunately missed out on being part of the Metro UI for tablets.

There is a relatively simple migration path for Silverlight and Windows Phone 7 applications to the new Metro WinRT. This might work for full-screen Silverlight applications, but will not work for applications that mix HTML and Silverlight content within a browser.

Is WPF Dead? – Again, for much the same reasons as Silerlight the answer is “no”. WPF is a framework intended for line-of-business applications, and those belong on the Windows 8 desktop.

How does this impact Windows Phone 7? – it doesn’t. The next version of WP7 is going RTM shortly and there has been no change to these plans. In fact for WP7 developers Windows 8 is a great opportunity. The WinRT seems most closely related to Silverlight for WP7, so your skills and code are readily portable to the tablet.

Should I write my app as a desktop or Metro app? – this is probably the single hardest question that the Windows 8 preview has raised. As application developers we now have two very different ways which we can deliver applications to the desktop and tablet, either the new Metro UI, powered by the (deliberately) limited WinRT; or desktop applications using WPF or Silverlight. I think it will be very interesting to see how Microsoft tackles this problem with its own applications. So far the Windows 8 preview has Metro UI based Twitter, Weather and Social Networking applications and a desktop based Visual Studio. There is also IE which is available in both desktop and Metro, albeit with quite different functionality. Where will Outlook, Word, Excel sit in the new Windows 8?

I think there are rather a lot of applications that will want to make use of both Metro and desktop UIs. Take Outlook for example, you could imagine a simplified Metro interface sitting on one of your monitors, but a more feature rich desktop version available on the other.

One other point worth considering is ‘reach’. It will take a long time before everyone is running a Windows 8 PC, so if you choose to deliver your application as a Metro app, you are restricting yourself just to the Windows 8 user-base. However, if you are targeting the Windows tablet, you can of course guarantee that they will run Windows 8.

Conclusions

Windows 8 presents a significant change in the way we develop Windows applications. The split personality of the Windows 8 user interface and architecture is going to cause confusion on many levels.

The technical implications of WinRT and how it relates to .NET are slowly starting to become clear, thanks to great blog posts like “WinRT Demystified”.

Personally what I think will take a little bit longer to understand is how we design applications for Windows 8, as we start to discover what works well in Metro, what should remain on the desktop and what we deliver to both.

Regards, Colin E.

Microsoft’s recent change in stance over Silverlight, promoting HTML5 as “the only true cross-platform solution for everything”, seems to have sidelined Silverlight as a niche framework. This has understandably caused a great deal of upset and confusion in the .NET development community. Despite this, Microsoft are remaining steadfast and tight-lipped about their vision for tighter integration of HTML5 into Windows 8 (and as a result just how side-lined Silverlight will be), until the BUILD conference next month. Recently I have read numerous blog posts about the difference between HTML5 and Silverlight, and how to select the right technology for your development, however almost all of them seem to ignore the great-big thorn in HTML5s side … JavaScript. In this blog post I will explain why JavaScript is such a big issue for Microsoft and what it could do to solve this.

That HTML5 will be a huge success is a given. The specification is not finished yet; the parts that are finished are not fully-rolled out, however it is making technology headlines on a daily basis. The HTML5 buzz has also been felt by both technical and non-technical managers, who you will often find asking, “why aren’t we creating HTML5 applications?”. Pointing at the unfinished specification is a little unfair on HTML5, you can reliably use a number of the APIs right now, and they will certainly provide a ‘boost’ to your current web-offerings.

HTML5 is a real mixed-bag of features, from the complex, such as canvas and video, to simple semantic markup improvements and a powerful set of CSS features. Because HTML5 provides a spectrum of features from the simple to the complex, I don’t doubt that every new site will be using HTML5 in a few years time, you simply have to add rounded borders or a <header> tag to earn yourself the coveted HTML5 badge!

One concept that underpins the HTML5 specification(s) is that of client-side web-applications. The server-side web-application, where business logic and presentation logic reside on the server, spitting out markup (sprinkled with a bit of JavaScript) are becoming an architecture of the past. The model where the server exposes business logic as a service makes it much easier to provide a front-end on a range of devices (mobile, tablet, desktop), a range of operating systems (Windows, iOS, Android), allows the effective use of client CPU, and provides a more accessible service that customers can integrate into their own application. From my perspective the most significant undertone of the HTML5 specification is that it supports this model.

The problem is that the name ‘HTML5’ can be a little misleading. Whilst the specification has much to do with HTML, it has much more to do with JavaScript. In fact, many of the HTML5 APIs have nothing to do with presentation or layout. Any article which compares HTML5 and Silverlight, without focussing on JavaScript is really missing the point.

So, what is my big issue with JavaScript?

Image used under Creative Commons Licence from Flickr

JavaScript was hastily developed as a language for scripting the web. Unfortunately it has not evolved much since its inception. Certainly the APIs that surround it have evolved, including the DOM APIs, HTML5 and popular libraries such as jQuery, however the language itself remains largely unchanged.

The big issue with JavaScript is that it is not well suited for the development of large applications, and if we shift to a model where the server provides a service which is consumed by the client web-application, this necessitates a lot of JavaScript code. I don’t want to go into all the gory details of the problems with JavaScript, but here are a few:

• Many language quirks and gotchas (see this article on codeproject)
• A lack of ‘familiar’ object-oriented concepts (I am not going to make the mistake of saying it is not an OO language!)
• A lack of dependency management
• A lack of organisational structure (namespaces)
• A very small ‘base’ library (for example no event support, string formatting, etc…)
• It is not strongly-typed
• A confusing array of patterns for solving some of the above!

This list is certainly not exhaustive; rather it is just a brief illustration of some of the obstacles that JavaScript presents to the developer of complex applications. Many of the items listed above are features of the language that are advantageous in a simple, scripting context, but when used to develop complex applications they are quite troublesome.

Another issue with JavaScript is not so much the language itself, more the attitude of developers towards the language. Because of its quirks and its predominant usage as a language for scripting web-pages (with the usual “google → cut → paste” approach) many developers simply don’t bother learning how it works. I have interviewed many job candidates who list ‘JavaScript’ as one of their skills, yet they cannot describe the difference between the binding of the ‘this’ variable between JavaScript and C#/Java.

There are numerous JavaScript frameworks that go some way towards solving the above issues … filling in the gaps. This is an area that Microsoft has dabbled in before, with the Microsoft Ajax Library adding inheritance patterns and .NET style libraries (albeit with a very clumsy, verbose and convention-heavy syntax!).

Whilst the list of issues above presents a challenge to the JavaScript developer, they provide just as great a challenge to the tool providers. Many features of existing IDEs, Intellisense (auto-completion) and structured views of the code rely on language features that are absent from JavaScript. Again, Microsoft has provided some innovations in this area, with pseudo-execution of JavaScript code providing some Intellisense support. Unfortunately this neat feature, which works well if you have all your code in a single JavaScript file, is less easy to manage on a large, more complex application. From personal experience I find Visual Studio adds little value to my JavaScript development experience, I am equally happy with Notepad++ and JSLint!

So when Microsoft announces their tighter integration of HTML5 / JavaScript into Windows 8, what innovations are they going to announce?

Personally, I think if Microsoft is serious about HTML5 and its potential for client-side application development they need to do much more than just add CSS3, canvas and video support to ASP.NET. They need to support the client-side application model, where ASP.NET no longer has a stake. To fully support this they need to ‘fix’ the problems with JavaScript.

One of Microsoft’s most prized assets is Visual Studio, their investment in tool-support allows you to use the same quality tooling for developing in a wide range of languages (C#, VB.NET, C++, F#, …) and frameworks (WinForms, MFC, WPF, Silverlight, ASP.NET, …). To fully embrace HTML5 / JavaScript it has to be fully embraced by Visual Studio. But therein lies the problem, the lack of namespacing, familiar object oriented concepts, strong-typing and base ‘class’ framework makes this a challenge.
I think the worst thing Microsoft could do is add their own JavaScript framework to the mix, further fragmenting the JavaScript development experience. Thankfully they recently adopted jQuery within their ASP.NET framework, showing signs that they are willing to work with existing open-source frameworks. So if they do not announce a new JavaScript framework, what could they provide instead?

Image used under Creative Commons Licence from Flickr

Microsoft’s Scott Henselmann has published a couple of interesting blog posts about the concept of JavaScript being the assembly language of the web (or the JVM of the web depending on your perspective). His second blog post included comments from a number of JavaScript thought leaders including its creator Brendan Eich who said “Believe it or not, classical OOP languages — especially ones with not-very-expressive static type systems — are not the only way to build large apps. It can be done in JS, but it’s harder than it ought to be”.

Google have already made some innovations in this area, the first is Google Web Toolkit (GWT), which allows developers to write Java code (using the powerful Eclipse IDE), which is compiled into JavaScript. The second is Google Closure Compiler, a JavaScript to JavaScript compiler / optimiser that provides type checking via annotated comments. It is this area that I think Microsoft should be investing in.

Microsoft could create a C# (or VB.NET etc…) to JavaScript compiler with an accompanying set of .NET base-class libraries. This would significantly boost Microsoft’s JavaScript offering in that it would be fully supported by Visual Studio, providing the developer with the quality tooling that they are used to when developing using other .NET frameworks. Furthermore, the C# to JavaScript compiler could be used to compile the existing .NET base-class library giving developers a large suite of familiar libraries for use within their code. You could event support C# to jQuery using a fluent Linq-style API!

So how would this work a runtime? When used on the internet to write applications for the browser or mobile browser, a set of C# DOM APIs could be created that compile to the ‘native’ JavaScript equivalent. HTML and CSS3 could of course be included directly within the project as resources.

On the desktop there are a few options, HTML could certainly be used as the presentation technology, but there is of course another option … XAML. Microsoft has clearly indicated that XAML will be part of Windows 8, considering that Silverlight 1.0 was XAML + JavaScript, it is clearly possible to have a XAML UI backed by JavaScript code. Although, it would seem a bit convoluted to compile C# to JavaScript to interact with the UI generated from XAML when C# APIs exist already!

In summary, I feel the current focus on HTML5 whilst ignoring the very real JavaScript issue is going to cause adopters of this technology a lot of pain. Whilst this technology set gives a fantastic boost to interactive websites, using JavaScript for the development of large client-side applications is an expensive option. My hope is that if Microsoft really embrace HTML5 they look beyond simply adding tag support and tooltips and address the real problem … JavaScript.

Regards, Colin E.

Earlier this week I presented a talk to the Silverlight UK User Group on cross-platform application development with WPF, Silverlight and Windows Phone 7.

Thanks to Gergley Orosz for these pictures

Thanks to all who attended my talk. Here is a copy of the presentation I gave:

You can see the Windows Phone 7 XAML Finance application which I demonstrated in the following video:

The Silverlight version is also available online.

Finally, the sourcecode for the simple cross-platform Twitter application I demonstrated is available to download: CrossPlatformDemo.zip

Regards, Colin E.

When meeting current and prospective clients the subject of web technology choice often arises. There has been a great deal of confusion and uncertainty out there, even before Microsoft’s perceived change of stance with respect to Silverlight emerged.

This white paper is intended to help technology decision makers come to an informed choice when faced with this difficult decision. You can view the paper below, or download it in PDF format: Flex-Silverlight-HTML5.pdf (1.3 MBytes)

Thoughts? comments? leave them below …

Regards, Colin E.

Both WPF and Silverlight have a property TextTrimming=”WordEllipsis”, which trims the text that a TextBlock displays based on the available width. This blog post describes a simple method for automatically showing the full text as a tooltip whenever the text is trimmed. This is presented as an attached behaviour and works in both WPF and Silverlight

A few weeks ago I blogged about a Silverlight solution for automatically adding tooltips when a TextBlock Text is trimmed and renders an ellipsis. I found a decent looking WPF solutions on the web and linked it in my article, however, based on the comments to my previous blog post, it looks like the WPF solution didn’t work too well, failing to respect font size etc… In this blog post I have updated my solution to be cross-platform, working on WPF and Silverlight.

To briefly recap, my solution for automatically adding tooltips to trimmed text relies on the slightly odd behaviour of the TextBlock where its ActualWidth is reported as the width of the text without trimming:

In order to determine whether to show a tooltip, all you have to do is compare the ActualWidth of the TextBlock to the ActualWidth of its parent.

However, the WPF TextBlock does not have this same quirky behaviour, so a completely different approach is required. The other solutions I have seen involve using the low-level WPF drawing APIs to compute the size of the rendered text, however, there is a simpler solution to this problem …

UPDATE: I originally wrote about a method of finding the overall text width from various internal fields within the TextBlock via reflection, as shown below. However, a kind reader of my blog, Daniel Fihnn, pointed out that there is a simpler solution that does not require any reflection.

Daniel pointed out that the width of the TextBlock without the trimming can be obtained using the Measure method. This method is typically used by panels during layout, the Measure method is invoked with the size made available to the element, calling this method causes the element to update its DesiredSize property. Therefore, if you invoke Measure on a TextBlock which has trimming enabled, giving it an infinite available space, its DesiredSize property will report the width that the text would occupy without trimming.

The ComputeAutoTooltip method of the attached behaviour I described in my previous post is updated to have a completely different WPF implementation:

public class TextBlockUtils
{
  /// <summary>
  /// Gets the value of the AutoTooltipProperty dependency property
  /// </summary>
  public static bool GetAutoTooltip(DependencyObject obj)
  {
    return (bool)obj.GetValue(AutoTooltipProperty);
  }
 
  /// <summary>
  /// Sets the value of the AutoTooltipProperty dependency property
  /// </summary>
  public static void SetAutoTooltip(DependencyObject obj, bool value)
  {
    obj.SetValue(AutoTooltipProperty, value);
  }
 
  /// <summary>
  /// Identified the attached AutoTooltip property. When true, this will set the TextBlock TextTrimming
  /// property to WordEllipsis, and display a tooltip with the full text whenever the text is trimmed.
  /// </summary>
  public static readonly DependencyProperty AutoTooltipProperty = DependencyProperty.RegisterAttached("AutoTooltip",
          typeof(bool), typeof(TextBlockUtils), new PropertyMetadata(false, OnAutoTooltipPropertyChanged));
 
  private static void OnAutoTooltipPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
  {
    TextBlock textBlock = d as TextBlock;
    if (textBlock == null)
      return;
 
    if (e.NewValue.Equals(true))
    {
      textBlock.TextTrimming = TextTrimming.WordEllipsis;
      ComputeAutoTooltip(textBlock);
      textBlock.SizeChanged += TextBlock_SizeChanged;
    }
    else
    {
      textBlock.SizeChanged -= TextBlock_SizeChanged;
    }
  }
 
  private static void TextBlock_SizeChanged(object sender, SizeChangedEventArgs e)
  {
    TextBlock textBlock = sender as TextBlock;
    ComputeAutoTooltip(textBlock);
  }
 
  /// <summary>
  /// Assigns the ToolTip for the given TextBlock based on whether the text is trimmed
  /// </summary>
  private static void ComputeAutoTooltip(TextBlock textBlock)
  {
#if WPF
    textBlock.Measure(new Size(Double.PositiveInfinity, Double.PositiveInfinity));
    var width = textBlock.DesiredSize.Width;
 
    if (textBlock.ActualWidth < width)
    {
      ToolTipService.SetToolTip(textBlock, textBlock.Text);
    }
    else
    {
      ToolTipService.SetToolTip(textBlock, null);
    }
 
#else
    FrameworkElement parentElement = VisualTreeHelper.GetParent(textBlock) as FrameworkElement;
    if (parentElement != null)
    {
      if (textBlock.ActualWidth > parentElement.ActualWidth)
      {
        ToolTipService.SetToolTip(textBlock, textBlock.Text);
      }
      else
      {
        ToolTipService.SetToolTip(textBlock, null);
      }
    }
#endif 
  }
}

This code now works in both a WPF and a Silverlight context. Here’s a screenshot of it working in WPF:

You can download the full sourcecode, including the WPF and Silverlight demo: AutoTooltipTextBlock.zip

Thanks to Daniel Fihnn for a much improved WPF version of this code!

Regards, Colin E.

This blog post looks at the fallout after last week’s PDC conference where Microsoft were quoted as saying “our strategy on Silverlight has shifted”, and the resulting fallout in the developer community. In this post I will describe why I think Silverlight has a future ahead of it and exactly where that future lies.

Bob Puts His Foot In It!

Last week’s Microsoft Professional Developer Conference (PDC) has caused quite a stir. It was clear from Steve Ballmer’s keynote speech that HTML5 was taking centre stage, with Silverlight not getting a single mention in his opening speech.

The image below shows a word cloud showing the most frequent words in Steve Ballmer’s PDC keynote speech, rendered using Wordle

This is in contrast to previous events such as MIX9 where (just over a year ago) Silverlight 3 took centre stage. This focus on HTML5, which many see as a competing technology to Silverlight was enough to get the community a little worried, however, it was the interview that Bob Muglia gave to ZDNet that really caused a storm.

The key quotes are given below:

“[...] when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, our strategy has shifted.”

“But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform”

The above statements caused quite a stir, with calls for Bob to clarify his statements which seemed to contradict the recent “Future of Silverlight” blog post which contrasted the difference between standardisation (HTML5) and innovation (Silverlight) to show a very positive future for the technology. I think this is the first time I had seen such a direct comparison of HTML5 vs. Silverlight from Microsoft’s Silverlight team, and the arguments they made were quite compelling.

Bob Pulls His Foot Out Again

As a result of Bob’s interview, which was commented upon by virtually everyone in the Silverlight community (Jeremy Likeness, Mike Taulty, and many many more), Bob quickly followed up with a blog post where he stated the following:

“I said, ‘Our Silverlight strategy and focus going forward has shifted.’ This isn’t a negative statement, but rather, it’s a comment on how the industry has changed and how we’re adapting our Silverlight strategy to take advantage of that”

However, I think that the most important point he made came at the very end of his post:

“The purpose of Silverlight has never been to replace HTML, but rather to do the things that HTML (and other technologies) can’t, and to do so in a way that’s easy for developers to use.”

I think it is people’s misunderstanding of the differences between Silverlight and HTML that caused most of this uproar in the first place. It is this point which I would like to concentrate on, and hopefully provide a bit more clarity.

PDC is an Event

Before I focus on the differences between HTML and Silverlight I think it is worth noting that PDC is an event, and just like any other event it needs to be marketed in order to fuel people’s interest and get them through the door. Microsoft embraces a very wide range of technologies, and if the PDC tried to be a true reflection of this diversity it would be very fragmented and hard to market. It is much better that the event focuses on something new and interesting to provide an underlying theme. This year that theme was HTML5.

Interestingly after MIX9 where Silverlight was the main focus and out-of-browser support was announced, there was noticeable unrest amongst the WPF community, they felt short-changed (4 MIX sessions on WPF to Silverlight’s 31) and there was speculation that Silverlight would replace WPF entirely. However, when the knee-jerk reactions were forgotten about and a more sensible analysis of the difference between the two was considered (see Pete Brown’s Future of Client App Development blog post for example), it was clear that WPF does have a future.

The Web Landscape

Back to HTML and Silverlight, if we look at the current landscape of the internet we can crudely characterise web sites and web based applications based on the degree of interactivity that provide:

In the above diagram we see a sliding scale of interactivity and complexity with a few well known sites positioned along this scale (don’t ask me about what units I am using to measure each site!).

With the above sliding scale we can position the popular internet technologies based on their relative strengths and the types of site they are most suited to:

I have not tried to pin each technology to a specific location on the scale because in my opinion the boundaries between each are blurred … a lot. It is possible to use any of the above technologies to create a web site / web application at either end of the spectrum, however, the further away you move from the ‘comfort zone’ of each technology, the harder the job becomes.

We’ll start at the Flash / Silverlight end of the spectrum. Why not capitalise on the fact that these plugin technologies provide a controlled environment for your code to run in, providing great performance and virtually zero browser compatibility issues?

Whilst this point may not have been addressed in great detail for Silverlight, there are certainly numerous strong arguments presented on the internet which describe quite clearly why full-page Flash sites will never fully replace HTML (For a thorough analysis take a look at Emil Stenström’s blog post on Flash vs. Ajax sites). The main reasons cited are:

• Splash screens – Flash / Silverlight sites need to load the entire ‘executable’ before they can render. Contrast this with how quickly the pages from Wikipedia appear.
• Maintenance – Quick fixes are often required for websites, with HTML / JavaScript this can often be left to the support team. For Silverlight / Flash this requires a full rebuild of the application.

(There are a number of other points, including search engine indexing, etc …)

There is not a strong case for replacing simpler web sites with Silverlight. I think my fellow WPF Disciple Justin Angel’s blog, which is powered entirely with Silverlight is unfortunately a good illustration of why Silverlight should not be used to replace HTML for the presentation of largely static content. Sitting here on a train using the pitiful WiFi connection I can see Justin’s stylish loading ‘splash screen’, however, after I minute of waiting I grow tired of staring at his beard and sunglasses and little else!

On the flip-side, when HTML and JavaScript technologies are used to create complex applications, development becomes costly and complex. Cross-browser problems, lack of support for business concepts such as controls and validation, performance issues all start to have a significant impact on the development. To combat this more and more sophisticated solutions are being applied, from the numerous libraries that abstract the differences in browser DOM APIs (jQuery etc…) to Google Web Toolkit, which generates JavaScript code from Java (which provides strong typing and better structuring).

Interestingly in the book Google Closure the Definitive Guide, the preface describes how Google Closure (a JavaScript compiler and mechanism for checking types) was developed to combat the problems the Google Mail development team were experiencing in developing a complex JavaScript application composed of tens of thousands of lines of JavaScript. The take-home message of this is that for complex applications you need more than the JavaScript language alone provides.

Bob’s Comments in Perspective

In the previous section I described how the web landscape can be illustrated as a sliding scale of complexity, with HTML and Silverlight at opposite ends of the spectrum and HTML5 sitting somewhere in-between. With this in mind, Silverlight developers should not fear that HTML5 will replace Silverlight. Whilst it is true that there is some common ground between the two, i.e. a certain interactivity / web-site complexity where the two technologies are equally suited, Silverlight users should feel comfortable that for the more complex problems, Silverlight has a clear advantage.

To repeat Bob’s closing statement of his follow-up blog post:

“The purpose of Silverlight has never been to replace HTML, but rather to do the things that HTML (and other technologies) can’t, and to do so in a way that’s easy for developers to use.”

I think it is the failure of the developer community to realise that there is little direct competition between HTML5 and Silverlight and failure of Microsoft’s marketing to highlight this.

The Web Increases its Reach.

However, there are some important points to note in Bob’s comments and his reference to iOS (i.e. iPhone, iPad etc…). Whilst I do not think HTML5 is a significant threat to Silverlight for web based application development, the introduction of a more diverse range of mobile devices potentially increase the market for HTML.

Most people who use an Android phone or an iPad do not use them as a replacement for their laptop or desktop PC. They use them on the train, in the coffee shop and at home on the sofa as a way to stay online and connected for more of their waking hours. HTML5 is a suitable technology for delivering a interactivity to a diverse range of devices and it looks like the overall market size is increasing.

However, if Microsoft can produce Silverlight plugins for these devices, on the Android phone for example, there is no reason why Silverlight cannot be part of this growing market, delivering more than just interactivity to the mobile platform.

Unfortunately, more recent news, like today’s announcement by the Bing Maps team that seems to indicates they will be dropping their Silverlight based 3D libraries in favour of HTML5 is going to fuel the fire which Bob and Steve Ballmer are currently trying to dowse.

Regards, Colin E.

Last week I gave a presentation at a joint Scott Logic / Microsoft event about how WPF and Silverlight are unifying the development platform for desktop, web and mobile. To accompany the talk I wrote a white paper which delves into this subject in a little more detail.

You can download the whitepaper here: WPF and Silverlight Cross Platform Development White Paper (PDF, 1.8 MBytes)

Or view it online in the PDF viewer below:

I also created a cross platform application that has a 75% shared codebase between the WPF (desktop), Silverlight (web) and Windows Phone 7 (mobile) versions. I plan to share more of this at a later date.

Any thoughts, ideas or comments, please share them below.

Regards,
Colin E.