Building New Windows* 8 Desktop Applications: Using New Windows RT Features

Download Article

Download Building New Windows* 8 Desktop Applications: Using New Windows RT Features [PDF 771KB]

If you are a developer who uses Microsoft tools, you have heard about the new Windows* Store apps in Windows 8. I have even written about using geolocation in Windows Store apps. The fact is, a lot of us—perhaps even the majority of us—are still writing traditional Desktop apps and will be for the foreseeable future. There are simply too many things that Windows Store apps can’t do.

That said, a ton of Windows RT and Windows 8 features are sure bets for inclusion in Desktop apps. Handling touch in the user interface (UI) is the elephant in the room. Most of Microsoft’s push for Windows 8 has been in the area of touch, taking advantage of the new touch-enabled hardware like Ultrabook™ devices. Windows 8 contains significant improvements in networking and operations application programming interfaces (APIs) that have a place in Desktop apps. And we can’t ignore deployment. The operating system has a new deployment API, and it is possible to market Desktop apps in the store alongside the new Windows Store apps.

Windows Store Apps versus Desktop Applications

If you go to http://msdn.microsoft.com/en-US/windows/apps/br229512 and click Windows Store Apps, you will find that Windows Presentation Foundation and Windows Forms aren’t there—they are now called Desktop apps. There isn’t a decline in Desktop app development or support, but it is clear that the new development model for Windows is the Store app. Understanding the differences is going to be paramount in the new development environment.

The Deployment Model

One of the most significant differences is how apps are installed. Only Windows Store apps can be sold on the Windows Store. Desktop app deployment hasn’t changed much, but the Windows Store apps are totally different.

How Desktop Apps Are Installed

Generally speaking, an understanding of how desktop applications are deployed and installed for Windows 7 applies to Windows 8 as well. There is little that requires change in the new operating system. A few of the features I discuss below constitute new Windows 8 functionality, but for right now, it is enough to know that the core options are pretty much the same:

  • Direct executable (.exe) download from a website or FTP site
  • Physical media, like CD, DVD, or USB flash drive
  • ClickOnce deployment

Desktop apps are still deployed to the Program Files folder (or Program Files (x86) in emulation mode) and have more or less the same registry, network, and resource considerations as in Windows 7.

How Windows Store Apps Are Installed

Windows Store app deployment isn’t just a little different than Desktop apps. It’s totally different:

  • The only way to deploy a Windows Store app to a normal user is through Windows Store. You can make private stores for the enterprise, and developers have side-load options, but to get the app in the hands of users, you have to use the Windows Store model.
  • Apps have to be reviewed by Microsoft.
  • Neither the developer nor the user has any control whatsoever as to where the app is installed. The Windows Store places apps on Windows 8 clients, and the apps are protected by the system.

The Sandbox

Once installed, Windows 8 Desktop apps run the same way they always have. If you are a Microsoft .NET programmer, you have access to the full framework. Microsoft Foundation Classes and Win32* work as they always have.

Windows Store apps are not like that. Only a significantly restricted portion of the Win32, Microsoft .NET, and Windows RT libraries are available. Beyond that, file system and network constraints exist. On top of that, the review process checks for things that can’t be used under certain circumstances, and you will be rejected if you do them. They are poorly documented, too, so you might not even know that you are breaking the rules.

In short, Windows Store apps live in a sandbox not unlike Java* apps, and the restrictions are significant. This will be the largest factor when you’re deciding whether to go with a Desktop or Store app.

What You Can’t Do in Windows Store Apps

The biggest single thing that developers find annoying is the lack of any database support in Windows Store apps. That’s not totally the case because some kinds of databases are acceptable, but if you are trying to use Microsoft ADO.NET (for instance) to connect to a Microsoft SQL Server* or Oracle* database, forget it. You can’t do it.

That restriction isn’t about the databases—it’s broader than that. The restriction actually has to do with the lack of socket connection support in Windows Store apps. It is possible to make an outgoing network connection for mail, FTP, or web calls, but direct socket connections are not supported.

Blocking the user thread is something else that is frowned on. If an operation takes longer than 50 milliseconds, it is expected to use the Microsoft .NET or JavaScript* async libraries. This is one of those things that will be blocked in the review process.

Access to hardware is severely restricted and can only be accomplished through contract agreements that users will be notified of on installation. For example, it is much easier to use the webcam than ever before, but you have to put it in the application manifest, and users have to give it permission at installation and run time. If they decline, you will have to handle that case in the application code.

What You Can Do in Windows Store Apps

There is strong support for Representational State Transfer (REST) and SOAP services, and that is the recommended way to get databases, off-site processing, and external access from Windows Store apps. All service calls have to be asynchronous, but that is well supported too. In fact, both C# 5.0 and the Windows Library for JavaScript (WinJS) were specifically designed to support async better than ever before in the Windows environment, and it is not only easy to do but works well too.

You have a lot of control and availability to build a beautiful UI. In the JavaScript world, jQuery is well-supported, and all of the user controls in that community work on Windows 8 as they do on the Web. The eXtensible Application Markup Language (XAML) controls for Windows 8 tend to be slightly different, but there is good support for the controls that third parties are producing.

The new Contracts have remarkable support for a whole litany of device, file, social, and inter-application sharing. You can share to Facebook, touch the Global Positioning System, and consume global search requests with just a few lines of code. It makes for a totally integrated, seamless user environment, and it’s pretty easy to code for too. If what you are writing falls into to the category of a client app, Window Store might be the way to go. No weird Twitter API code required. Windows 8 just handles “share to Twitter” for you. All this makes development faster and much easier to future-proof.

Finally, you can consume “old” Microsoft .NET or C++ business logic. A component format called Windows Runtime Metadata requires a recompile, but it is supported in Windows 8. For example, if you have a physics library for your game that was carefully crafted to fit your particular style, it will probably work with no code changes at all.

What Do You NEED to Do?

It all comes down to your requirements, really. If you have a stack of user stories and are going to need a menu as long as your arm to handle them all, then Desktop is your path. If you need a direct database connection or socket connection, then Desktop is your path. If you need to converse directly with the hardware or the file system, then Desktop is your path.

However, if you are writing a client app, consider Windows Store development. A single user app can be well-structured for Windows Store, and I would recommend that you check into it. Look at the store today and see what such companies as Adobe and Quicken have done. Single-use case apps are often well-suited to the Windows Store format.

New Windows 8 Functionality for Desktop

If a Desktop app is best for your use cases, you should certainly look at adding some of the awesome new functionality built into Windows 8 to your program. Touch, new services, operations stuff, and networking improvements are a great place to start.

Touch

Windows 8 is a touch-first operating system. Don’t be fooled. Yes, you can still use a mouse and keyboard, and yes, pen support is good. But all you have to do is load up the Start screen to see that the interface is optimized for touch.

Designing for Touch

The easiest way to make your application touch friendly is to manage the size and spacing of controls. Although some special controls are optimized for touch, it is possible to use existing controls—as long as spacing and size are appropriate.

Take, for example, the HTML select element. Normally implemented, as in the example in Figure 1, the list elements are close together. This is economical for screen size but not effective for touch because the operating system may not register your intended touch spot accurately.


Figure 1. The original HTML select element

In the updated design for touch, Google Chrome* in Windows 8 mode places the items in a select list significantly farther apart, as shown in Figure 2.


Figure 2. The HTML select element in Chrome

This takes more room and requires a scrollbar, but it is infinitely more touchable.

The rule of thumb, so to speak, is not to have giant controls, just easily touchable controls. All controls should be 23 pixels at the slimmest dimension. The visible element doesn’t have to be that big, just the touchable surface. Note that the text isn’t larger in Figure 2, but the lines are farther apart.

Direct Manipulation API

The Direct Manipulation API provides event handling for manipulation and gestures in the UI via touch. The Windows handles (HWNDs) of elements on the application surface provide pointer input messages for touch events just as if through mouse or pen.

Microsoft Account Integration

Windows 8 uses the user’s Microsoft Account as a local login, which allows developers to integrate the Microsoft Account (with the user’s permission) via the Identity API. Desktop applications do not have built-in login control, so you start with the WL.ui function to create a Windows Live* Connect sign-in control. In HTML, you simply provide a named <div> tag and initialize it in the JavaScript code:

 WL.ui({ name: "signin", element: "signin" }); 

When the control is in place, the WL namespace provides a simple login function that adds the Windows login experience to your app. The login method is an async call that passes the credentials to a callback function, from which you can get user information like name and profile photo:

 function signInUser() { WL.login({ scope: "wl.signin" }, onSignIn); } 

Operations

Microsoft has fleshed out a lot of its “under the covers” operations APIs for better Windows 8 integration, no matter the development platform of choice. Taking advantage of these APIs is another way to bring your app to the Windows 8 ecosystem.

Help API

The Help API provides a programmatic interface for the Windows Help Runtime. In Windows 8, Microsoft replaced the Microsoft.VisualStudio.Help DLL with the Windows.Help.Runtime.DLL to benefit users by codifying help file access.

User Access Logging

User Access Logging (UAL) is another consolidation framework, this one assisting with licensing management by reporting user software access to a central server. To report use to a server, include ual.h and use UalRegisterProduct at application setup. Then, each time the application starts, it calls UalStart to register a session. You can log the user information and IP address and then reference the information later for tracking usage statistics.

State Management

The new User State Management API assists with maintaining status for users across roaming profiles and other flexible usage patterns. Specifically, it:

  • Puts all user application settings in a central storage area for enterprise management and information protection
  • Gives users a more consistent view of their data
  • Makes bring-your-own device and PC replacement more palatable

New Deployment API

Developers can take advantage of centralized deployment that is similar to the Windows Store app deployment in their Desktop apps. The Windows.ApplicationModel and Windows.Management.Deployment classes hold the key to consuming services from the Windows Deployment Services Server (WDSS)

The Deployment API is especially helpful in the enterprise environment, where access to applications should be controlled by user role. A selection of allowed applications can be configured in the WDSS service that allows users to quickly set up applications on any workstation that supports the app.

It is also possible to reference Desktop apps in the Windows Store. The deployment model doesn’t support Desktop apps, but it is worth mentioning because of the visibility offered. Even with the new Deployment API, all you can provide is a link to another site for purchase and download, but it is a start.

Conclusion

Building a new app for the Windows Store certainly has some benefits, but it is easy to take advantage of Windows 8 features in Desktop applications as well. If your app is taking advantage of desktop features, there is no reason it can’t also build on some of the new Windows 8 features too. Embracing touch, taking advantage of the new deployment opportunities, and integrating services like Microsoft Account help make an app shine on new Windows 8 devices.

For More Information

About the Author

In 1992, Bill Sempf was working as a systems administrator for Ohio State University where he formalized his career-long association with internetworking. While working for one of the first ISPs in Columbus, Ohio, in 1995, he built the second major web-based shopping center, Americash Mall, using ColdFusion* and Oracle. Bill’s focus started to turn to security around the turn of the century. Internet-driven viruses were becoming the norm by this time, and applications were susceptible to attack like never before. In 2003, Bill wrote the security and deployment chapters of the often-referenced Professional ASP.NET Web Services for Wrox and began his career in pen testing and threat modeling with a web services analysis for the State of Ohio. Currently, Bill is working as a security-minded software architect specializing in the Microsoft space. He has recently designed a global architecture for a telecommunications web portal, modeled threats for a global travel provider, and provided identity policy and governance for the State of Ohio. In addition, he is actively publishing, with the latest effort being Windows 8 Application Development with HTML5 for Dummies.

如需更全面地了解编译器优化,请参阅优化注意事项