The release of Windows 8 brought with it a new software framework: Windows Runtime (WinRT). Although the approach used for WinRT application development mimics how development in .NET Framework works from a code standpoint, there are crucial differences between app development in WinRT and in .NET.
Related: Developing Windows 8 Applications
To build applications optimally under WinRT, developers need to understand the differences between WinRT app development and traditional .NET development on the desktop. Here I will outline six essential areas of difference that .NET developers should understand in order to transition successfully into building apps in WinRT.
User Experience and User Interface
One of the first differences developers will notice is that the user experience (UX) and user interface (UI) are completely different in WinRT apps as compared with UX and UI in traditional .NET applications. In traditional .NET desktop apps, it is assumed that users will interact with such applications using a mouse and keyboard. Overcrowded menus are acceptable because users can rely on the mouse to pinpoint and select menu items. Users can navigate visually complex applications, although sometimes ease of use is an issue. Because no standard exists for defining where settings belong in each application, each application has a unique look and can present a steep learning curve for end users.
WinRT does a great job of setting end-user expectations by imposing unified design requirements for every app. Touch rather than use of a mouse is assumed to be the primary interaction method. This means that buttons and selectable items must have larger hit targets and scrolling should not require use of a scrollbar. These constraints result in an app design that "breathes" more and doesn't feel cluttered or complicated. Even so, WinRT applications should always support mouse interaction in addition to touch, as shown in the app in Figure 1, as many users are upgrading to systems without touch support.
Every app in the Windows Store is required to use specific APIs and features provided by Windows 8 when certain tasks are being performed. Some relevant examples of such features include the Settings charm, which should be used for all app settings; the app bar, which is a unified way to access certain types of commands in each app; and the back button (left arrow) in the top left corner of pages that have been navigated to. These and other key unifications make WinRT apps easy to learn and understand.
Application Lifecycle
Next to UX and UI, the biggest difference between WinRT development and traditional .NET development is in the area of application lifecycle (i.e., state management). In traditional .NET apps, there are only two states an application can be in: running or closed. In some cases, an application's state may be saved to disk for recovery on the next run of the application; there is no concept of pausing application execution temporarily, then resuming the application later. The only way traditional applications come close to this pause-and-resume behavior is when Windows hibernates or sleeps. However, the difference is that Windows handles the state globally, and each running application exists as part of that state.
A WinRT app transitions between different states: closed, running, suspending, suspended, terminated, resuming, and restoring. The closed and running states are very similar to those states in traditional .NET applications. The new states, along with the closed and running states, ensure that all available system resources go to the app that is currently running—unlike in traditional .NET applications, where all running applications have to share the available resources. Microsoft has provided developers with an excellent article that explains each state in great detail—see "Application lifecycle (Windows Store apps)" for more information.
You can think of these new application states as a way to mimic multitasking. Although only one app at a time is actually running, the user can seamlessly switch between apps in any state. From the user's point of view, an app will appear to have been running the entire time—with two exceptions. If an app is in the closed state, then the app must be loaded into memory. The user will experience the app-loading screen until the application is fully loaded and enters the running state. If an app is in the terminated state, the app must also be reloaded into memory and also needs to restore any state that was saved when the app entered the suspended state.
An easy mistake for a developer to make is to treat an app coming from the suspended state the same as an app coming from the terminated state. It's important to treat each state correctly; doing so has a direct effect on UX. When an app is coming from the suspended state, the app is being resumed; in this case, the only necessary steps are to refresh stale data such as data coming from a device or web service. When an app is coming from the terminated state, the app is being restored and needs to have the entire UI reconstructed (because it is no longer in memory) and to have stale data refreshed. Restoring an app is a time-consuming process. Resuming an app is quick and has a relatively low impact on the data the user sees. When a developer treats resuming as restoring, the resulting performance slowdown is likely to cause end-user dissatisfaction, possibly even inducing users to stop using the app in favor of another app that's more responsive. In short, when developing a WinRT app, you'll need to properly handle state transitions in order to make the app as responsive as possible.
Mobility and Connectivity
Microsoft designed the WinRT framework with mobility and high connectivity in mind. Each API is designed to use device resources efficiently so as to conserve the mobile device user's battery as much as possible. For a traditional .NET developer, battery conservation is a new concern—one that doesn't apply when developing for traditional desktop applications. But for WinRT apps, from both a business and usability standpoint, apps built to minimize battery-intensive processing (such as processing of web services or other local data) will win out over battery-draining apps. A battery-hogging app could lead to diminished ad revenue and end-user frustration, and eventually be replaced by a battery-conserving app. In your WinRT apps, therefore, you should limit processing of web services and local data as much as possible. Additionally, consider moving processor-intensive operations, which consume a lot of power, to a web service used by the app.
WinRT apps are also assumed to be highly connected and should be designed with this specific purpose in mind. A "highly connected" app is one that uses web services to provide app data and has social aspects. Near Field Communication (NFC) APIs exist to help users connect while they're in the same vicinity or on the same Wi-Fi network. Apps are encouraged to consume web services and do so in unique, creative, and innovative ways.
It's important to balance high-connectivity needs with mobility concerns. For many WinRT apps, being able to use the app offline is an important feature. To help support offline usage in an app, Windows 8 provides a great feature called Connected Standby, a power state that allows the PC to enter a special kind of sleep mode. While a device is in Connected Standby mode, WinRT apps may queue up requests for small amounts of data, such as updating a live tile. This feature is not available to traditional desktop applications.
Performance and Memory Management
Performance optimization is tough in WinRT app development because of a lack of tooling—unlike in the desktop world, where developers can choose among a plethora of performance management tools. As of this writing, many companies have released brand-new products that perform performance profiling of WinRT apps. Keep in mind that these products are first-generation tools, so they may have limited capabilities compared to their desktop counterparts. Visual Studio has some built-in tools available to help developers analyze the performance of their Windows Store apps. See "How to profile a XAML Windows Store App" for detailed information about those tools and how to use them. Some third-party performance-profiling tools are available as well—for example, from Red Gate Software and JetBrains.
Similarly, memory management for WinRT apps is challenging, in part because few memory-profiling tools are available. Currently there are at least two tools available: Visual Studio's built-in memory profiler and the open source CLR Profiler.
Memory is a big deal for WinRT apps. One of the main reasons a WinRT app would be terminated (i.e., moved from the suspended state to the terminated state) is because of a lack of system memory. Suspended apps still take up memory, whereas terminated apps do not. WinRT apps that can manage a lower memory footprint may be less likely to be terminated than those with a higher memory footprint. Suspended apps load significantly faster than terminated apps; thus, users can re-enter a suspended app faster and more easily than a terminated one. Also, if an app was terminated because it had a large amount of memory in use, the app will need to reload all that data into memory when the app is activated again. The more memory in use, the slower the app will be to load. (For tips on managing memory, see "Managing Memory in Windows Store Apps, Part 2.")
Features Unique to WinRT
Some WinRT features are not available in traditional desktop applications. Many of these features have to do with app interoperability. Desktop applications have a tremendously difficult time connecting and communicating with each other, even when they are built by the same developer. However, WinRT apps don't suffer from this problem. The Charms bar located on the right side of the Windows 8 screen, as shown in Figure 2, provides search, sharing, and settings features that facilitate interaction between apps.
In Windows 8 the Search charm allows users to search installed apps, files, folders, pictures, and other media, as well as search within an app. This search capability contrasts with the search function in Windows 8's File Explorer (formerly Windows Explorer), which searches only the files of the selected folder, or search in a desktop application, where only data available to the application is searched. Note especially the Search charm's intra-application search capability. WinRT apps can opt into search and thus can provide Windows with search results from the app. The unique benefit here is that the user can switch the search from one app to another using the same criteria until the desired contents are located.
Sharing is one of the handiest features provided by the Charms bar's Share charm and one of the most innovative features of Windows 8 for WinRT apps. From a developer's point of view, enabling two traditional desktop applications to share data back and forth can be a nightmare. However, in Windows 8 doing so is as easy as specifying in the app's manifest what kind of data the app shares out and what kind of data the app allows to be shared to it. Windows 8 then handles the communication between each app. This makes for a great experience for a user who wants to share data between applications, such as sharing pictures on social media or sending documents via email or another app. This sharing capability is also great for note taking, as shown in Figure 3, since any app that shares data can provide content for notes.
Another useful feature is the Settings charm, which makes it easy for users to find and change an application's settings. To ensure that an app conforms to Windows 8/WinRT requirements for settings, developers must use a consistent, unified approach to laying out an application's settings and menu options. Figure 4 shows an example of settings in the built-in WinRT weather application.
Live Tiles is another unique WinRT feature—and possibly the best feature of any single WinRT app. Live Tiles truly bring an app to life, especially when it isn't running, by informing users of what data is waiting for them in the app. Live Tiles also allow users to deep-link into specific parts of the app, which is especially useful for applications in which users are accessing data, such as weather apps that provide data for multiple locations, flight-tracking apps, social apps, and even business apps. Users are more apt to place apps with beautiful and engaging Live Tiles in an easy-to-view part of their Start screen, as shown in Figure 5; thus such apps will likely be accessed more often than apps with less-engaging Live Tiles. Don't underestimate the power of Live Tiles in your application!
Deployment and Quality Control
A crucial factor in whether an app fulfills its intended purpose is how easy it is for a user to obtain and install the app. The Windows Store facilitates this process, by providing a central location for all users to search for and install WinRT apps. With the Windows Store, downloading and installing an app is a much simpler and more consistent process than users were accustomed to for traditional desktop applications, where installations were often as unique as the applications themselves. Each time a new version of an app is pushed to the Windows Store, users are notified that an update is available. Users can obtain and install the update as soon as possible.
Another great feature of the Windows Store is the approval process that all apps must go through. The approval process ensures that each WinRT app is of the highest standard and meets certain criteria in regard to its functionality and design. The approval process provides you with free extra testing of your app before its release. The Windows Store approval process also means that other apps on the platform are of the highest standards as well, which helps users accept the platform. And of course, users' acceptance of a platform means job security for that platform's application developers!
Vive la Différence!
As you've seen, the WinRT framework ushers in some important changes for those familiar with traditional .NET desktop application development. Understanding the differences between WinRT and traditional .NET development can help developers successfully transition to the new world of WinRT and Windows Store apps.
