Smarter ideas worth writing about.

Climbing the Windows 8 App Learning Curve

ASP.Net developers face a learning curve when writing Windows 8 apps. Based on my personal experience ASP.Net developers represent the majority of all .Net developers, so that's probably an important audience from Microsoft's perspective. Not surprisingly, Cardinal Solutions has many ASP.Net developers on staff and quite few of them have helped build Windows 8 applications, including at least a few applications already deployed to clients. All of those apps were built using C# and XAML.  Looking back, Cardinal developers identified a few areas in particular where they felt the steepest climb, starting with Windows 8 itself. 

Windows 8

You can only build Windows 8 apps while running within Windows 8 (even if you run Windows 8 within a VM), and running Windows 8 forces you to learn the new UI and many of its nuances.  However, using Windows 8 is one thing; it's an entirely different proposition to build an app that follows all of the new UI principles and behaves correctly within the new platform.

Chrome

One of the challenges teams encounter when building Windows 8 apps is the new Windows 8 UI guidelines, and in particular the whole topic of removing "chrome."  If you're not familiar with that topic, essentially this is a major departure from all prior versions of Windows. In Windows 7 and prior versions, applications had title bars, menus, toolbars, status bars, buttons for navigation, popup menus, etc.  Microsoft now calls all those things "chrome" and that's all considered bad now because chrome takes focus away from the application's data, its content.  Content good, chrome bad.

 

Figure 1: "Chrome" in Windows

For example, one application's UI design had a search box on the home page – it was a search-oriented app after all. The search box seemed well-behaved because it integrated with the search charm, such that when you typed in the search box it would immediately open the search charm and transfer the text and focus there. However that was too much chrome according to some Microsoft folks who reviewed the app, and the search box had to go. The same app also had a Save button on its settings page.  That didn't follow the guidelines either and had to go as well.

Charms

The prior section mentions the search charm and the settings charm, which brings up another area of Windows 8 that has caused developers a steeper-than-expected climb. Many apps use the settings, search, and share charms. While they are quite easy to integrate and get working, they have a tendency to take more time than expected to fine tune. For example, in one app it was easy to get the search charm to pop up when the user typed within the app, but it would also pop up when typing in the settings fly-out. It was a minor headache to prevent it from popping up in that case and took more time than expected. Also, getting the settings to save when the user clicked away from the settings fly-out–a "light dismiss"–took developers longer than expected. Finally, getting the share charm to format the shared data correctly can be mildly challenging, but is often the easiest of them all.

Live Tiles

One of the cool new things with Windows 8 is live tiles. They can actually be quite easy to get working, depending on the type of live tile and your data source. One team spent a lot of time getting live tiles to display images correctly. The design called for live tiles that worked just like the People app that comes with Windows 8, displaying a "Brady Bunch" grid of images from real application data. It turns out Windows 8 didn't like that the source for the images was HTTP URLs. There are examples on the internet that use image URLs and they claim to work just fine, but no such luck for our team. They ended up having to cache images in local app storage and then reference the local images, which worked just fine and was really a more efficient solution in the end.

 

Figure 2: The application's dynamic live tile

WinRT ≠ Win32

Another frequent challenge is the fact that Windows 8 apps run on the WinRT API, not Win32. You simply cannot reference Win32 components from WinRT apps. That means bazillions of Win32 apps and components are inaccessible, so for example one app couldn't easily integrate with Lync (an important requirement). Other teams were disappointed they couldn't use their favorite logging standby, Log4net. In the end the one team provided some basic Lync integration and the other team rolled their own basic logging utility–a nice component for your toolkit.

Deployment

Another frequently anticipated challenge with Windows 8 is deployment. The options here include deploying apps to the Windows Store, deploying them to a corporate store, or side loading them. All of the apps our developers created were deployed by side-loading the applications on desktops and tablet devices. The side-loading process requires changing a group policy, getting and installing a deployment license, and then running some PowerShell scripts. It turns out Microsoft has made this process very simple, because all developers had to do was build the deployment package, copy it to the machine/device, uninstall the app if it was previously installed, then run a single PowerShell script. The PowerShell script did everything, changing the group policy if needed, getting a license if needed, etc.  It was beautifully easy! Nice job Microsoft!

Deploying apps to the Windows Store is much more involved and requires following still another set of guidelines, which Microsoft enforces quite strictly. Also, there are humans involved in the submission approval process, which of course leaves room for errors and inconsistency. Best of luck to you!

XAML

As mentioned previously, one of the big challenges for ASP.Net developers is learning XAML. This can be quite a challenge. You can search online for learning sources but there really isn't much out there.  Most references focus more on the "what" than the "how" so for the most part you're on your own. However, a good source is http://msdn.microsoft.com/en-us/library/vstudio/ms752059.aspx.

Layout

One common initial challenge with XAML is layout, which for web developers can feel like classic HTML layout with tables. But instead of HTML tables, in XAML you mostly use grids and also some stack panels. Then there are the Windows 8 XAML controls: TextBlock, TextBox, ScrollViewer, GridView, ListView, Image, etc. Really nothing shocking from the perspective of an ASP.Net developer.

Styles

Some of my personal favorite things about XAML are its styles, its extensions, and the VisualStateManager, which altogether provide a lot of power. My favorite thing with XAML styles is inheritance. I've asked for many years why didn't they do normal inheritance in CSS. It's wonderful how it works in XAML! In fact, XAML styles and built-in templating are so powerful that they're used to define the structure of all the XAML controls. You can even override those default control templates in XAML to customize your app's look and feel.  

 

Figure 3: A portion of the style definition for the Button class

 

Markup Extensions / Data Binding

XAML's markup extensions bring still more power to the game. Extensions are frequently used to specify values for attributes by using curly braces. For example, you add a style to a control using the following extension syntax: 'Style="{StaticResource PageHeaderStyle}".' The most common use of markup extensions, however, is for data binding. You can bind the text of a TextBox to a data source using the following syntax: 'Text="{Binding Title}".' You can even use the extension syntax to dynamically bind a property on one control to another control’s property. For example, 'IsEnabled="{Binding IsOn, ElementName=SettingsToggle}". As if that's not great enough, you can also bind sample data to your UI at design time so you can see how your app will display "live" as you design it.  Binding sample data is a must-have for a productive UI design experience.

 

Figure 4: Binding to a sample data class

Views and Resolutions

Finally, one of the challenges of Windows 8 apps is dealing with the various views and resolutions supported by Windows 8. You have to handle landscape and portrait views, snapped view (where your app occupies a 320 pixel wide slice on the right/left side of the screen), and fill view (where your app occupies the remainder of the screen when another app is snapped). And then there are screen resolutions ranging from 1024x768 to 2560x1440 and beyond. It's insane! However, the XAML VisualStateManager comes to the rescue, allowing you to declaratively specify how to modify your UI to render appropriately in each orientation. Trust me, this is way better than CSS media queries. And to facilitate the design process Visual Studio's XAML designer allows you to select which view to preview (landscape, portrait, snapped, filled) at design time, as well as pick from various screen resolutions and sizes (from 10.6" to 27").

 

Figure 5: Switching views and resolutions within the XAML designer

 

Figure 6: Some sample VisualStateManager transformations

ASP.Net developers can easily be overwhelmed by all that XAML offers, but it's clear XAML is very powerful, and yet I've just scratched the surface here.

async / await

The last and most fascinating topic (at least for this techno-geek) is the new async & await pattern.  This is deceptively simple at first – simply add the new keywords and you're writing asynchronous code.  Awesome! But it doesn't take long to figure out that it's not nearly that simple. Microsoft's developers hid some fairly complicated code behind the new keywords, and there are ramifications with their implementation that are revealed as you try to await asynchronous methods in various scenarios. It's truly a beautiful thing to behold once it's all working nicely, but it's also like peeling an onion–as you get deeper there always seems to be more to learn.

Some suggestions to help you climb faster:

  • Follow Microsoft's naming convention and always name your async methods SomethingAsync.
  • You can't simply declare a void method as async and expect to await it; you have to change void to Task, even though you still don’t have to return anything.  The compiler will complain if you try to await a void method.

 

  • Events get special async handling.  That is, you can change events to be async as needed even though they're void, and the compiler won't complain.
  • There's often a ripple effect to making a method async.  That is, when you change a method ABC to async then you end up changing methods that call ABC to async as well, and on and on.
  • You cannot have async properties, which can lead to some challenging scenarios.
  • There are some limitations to awaiting async methods:
    1. You cannot await an async method within a thread lock block.  This most of the time results in thread deadlocks and so Microsoft prohibited it.
    2. You can't await async methods in catch & finally blocks because it doesn't agree with the semantics of the CLR's exception handling.

  • You will likely stumble into some multithreaded programming concerns, even though async/await don't necessarily start new threads.  Regardless, familiarize yourself with multithreaded topics such as the Task class, threadsafe collections, PLINQ, etc.

 

Regardless of these and other complications, it's a beautiful thing to see how responsive apps become once they have a correct asynchronous implementation.

In Summary…

Based on experience of Cardinal's developers, building one or two small Windows 8 apps should put you well on your way up the Windows 8 app learning curve.  That's not bad at all and bodes well for Microsoft developers – ASP.Net developers in particular.  This is a very cool and fun new technology to learn, so get to it!  

 

Share:

About The Author

Practice Manager, Enterprise Microsoft Solutions
Vince is the Practice Manager of the Enterprise Microsoft Solutions practice at Cardinal Solution’s Columbus, Ohio, branch. Vince loves building things and fixing things, and working with teams to achieve success. He’s been applying those passions to the IT industry for well over 20 years now – the past 20 as a consultant wearing many hats (developer, trainer, architect, mentor, manager).