Visual Studio 2012 enables developers to create the new Windows apps that target Windows 8. If you worked with either WPF applications or Silverlight, you can reuse your XAML knowledge and it doesn't take too much time to start working with .NET Profiles for Windows 8 apps, known more formally as ".NET for Windows Store" apps.
However, it is indeed necessary to change the way you design the user experience, especially if you have previous experience with apps. You have to master the new way Microsoft thinks about Windows 8 apps, the UI elements, the controls, and the layouts. In this first article in a series (that will run in three consecutive weekly installments), I provide a brief overview about the different Windows 8 apps types, the new .NET Profile, and the first steps to build a Windows 8 app and customize its appearance with Visual Studio 2012.
Windows 8 Apps Require a Paradigm Shift
Forget about colorful icons, stop thinking about gradients, and don't even try to add mirror effects. Think a bit monochrome and keep things as simple and fluid as possible. These are good precepts to follow when initially designing the UI for a Windows 8 app with XAML, the new .NET Profiles, and especially the new Window 8 tiles.
The first time I installed the final version of Windows 8, some aspects of the UI made me think my system didn't have the appropriate GPU drivers. However, after making sure the right drivers were installed and my GPU was working OK, I figured out what Microsoft was talking about when it warns app developers about keeping things simple. Just look at the new Start screen to understand how simple I mean (see Figure 1).
Figure 1: The icons displayed within single color tiles in the Windows 8 Start screen are very simple. Pay attention to the white icons for Mail, Maps, Photos, and Games.
Windows 8 App Types
Before developing an app, it is very important to understand the different Windows 8 app types organized by target and by their most common distribution mechanism (see Figure 2):
Target: Consumers
- Consumer apps. Tech companies and developers build consumer apps and distribute them through Windows Store. Some examples of consumer apps are Twitter, Facebook, and Calendar.
- Business-to-Consumer (B2C) apps. Enterprises build B2C apps and distribute them through Windows Store. Some examples of B2C apps are apps from airlines that enable users to perform online check-ins and review reservations, and retail apps that allow users to review online catalogs and make purchases.
Target: Business
- LOB ISV apps. Tech companies and developers build Line-Of-Business Independent Software Vendor (LOB ISV) apps and distribute them through either Windows Store or side-loading. Some examples of LOB ISV apps are vendor apps that extend CRM and ERP platforms to devices that support Windows 8.
- Custom LOB apps. Enterprises build custom Line-Of-Business (LOB) apps and distribute them through side-loading. Some examples are company-internal knowledge management systems, expense approval systems, and the implementation of specific internal workflows in LOB apps. You can think of custom LOB apps as the replacements for Silverlight LOB applications.
Figure 2. Different types of Windows 8 apps.
Understanding the New .NET Profile for Windows Store Apps
If you want to leverage your existing .NET knowledge and start developing Windows 8 apps, you must understand the new .NET Profile tailored for apps and the new native API Windows Runtime (WinRT). WinRT (sometimes also called WRT) replaces the well-known Win32 APIs for Windows 8 apps. Microsoft designed WinRT with multiple languages in mind, and therefore, it isn't like Win32 APIs, which were written to be consumed by the C programming language. WinRT is object-oriented from scratch and projects out objects to the different programming languages that consume it. Thus, WinRT represents a huge change for those used to thinking about making Win32 calls from different programming languages.
You can use many languages to create Windows 8 apps and interact with WinRT:
- C# and XAML
- C++ and XAML
- Visual Basic and XAML
- JavaScript, HTML5, and CSS3
- C++ and DirectX
Here, I'll focus on C# and XAML. However, you can also use most of the things that I'll explain for the other choices shown in the aforementioned list. Apps written in JavaScript, HTML5, and CSS3 have the same UI elements that we use with XAML. The unique case is C++ and DirectX, where the UI is usually very different.
You can also create WinRT components that you can use in Windows Store apps using any of the available programming languages — another new market for component developers.
The new .NET Profile for Windows Store apps includes many reference assemblies you may already know from .NET Framework 4.5, Windows Phone 7, and Silverlight 5 (see Figure 3). However, it is important to understand some of the differences in .NET Profiles.
Profiles
Each .NET Profile represents a subset of reference assemblies. The default location for the assemblies included in .NET for Windows Store apps is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5, provided that your operating system drive is C:. The more generic path is %ProgramFiles(x86)%\"Reference Assemblies"\Microsoft\Framework\.NETCore\v4.5.
Figure 3: An idea of reference assemblies shared between .NET Profile for Windows Store apps and other .NET Profiles.
.NET for Windows Store apps represented a great opportunity for Microsoft engineers to remove a lot of unnecessary garbage that various .NET versions have been accumulating. Thus, this new Profile removes duplicate types that aren't necessary for WinRT APIs. (They were put in the .NET Framework for compatibility with previous versions.) For example, ArrayList isn't available and if you need a list, you can use the more modern List<T>. Some types were required in early .NET Framework versions and don't make sense in modern profiles. Generics support represented a big improvement for .NET Framework and there are older types that generate confusion and don't add value.
.NET for Windows Store apps is focused on apps, and therefore, the Profile removes all the APIs that aren't applicable to apps. For example, Console applications and ASP.NET aren't included. In addition, everything that has been considered dangerous, obsolete, legacy, and badly designed isn't included in the new Profile. Operating System API wrappers aren't available in the new Profile, and therefore, you aren't able to access the performance counter or the event log.
The good news about .NET for Windows Store apps is that it has fewer assemblies, namespaces, types, and members than the Windows Phone 7 profile. The new Profile is simplified and it is easy to get used to it if you have experience with other .NET Profiles. Figure 4 shows the main high-level components for .NET for Windows Store apps. Don't forget that the Profile targets client apps, which means that you can only use the client-side of WCF. The Profile doesn't provide any server features.
Figure 4: High-level main components of the .NET Profile for Windows Store apps.
Figure 5 shows the high-level overview of the interaction between the .NET Profile for Windows Store apps and WinRT when XAML is used. Notice that the main namespace for the UI stack is Windows.UI.Xaml. The main namespace for the operating system services is Windows (notice that it is not System.Windows, just Windows).
Figure 5: .NET Profile for Windows Store apps and the interaction with WinRT.
The following table provides an overview of the namespaces that have been replaced from other .NET Profiles and their new names. You must take into account that some of the new namespaces provide completely new classes and methods that are compatible with the new asynchronous pattern. Special cases are the new System.Net.HttpClient and Windows.Networking.BackgroundTransfer namespaces, because both replace the features provided by the previous System.Net.WebClient namespace.
| New namespace | Previous namespace |
|
|
|
|
|
|
|
|
|
|
|
|
Application domains, private reflection, and non-generic collections have been removed. In addition, the following namespaces aren't included in .NET for Windows Store apps:
System.DataSystem.Reflection.EmitSystem.Runtime.RemotingSystem.Web
