Build Windows® 8 Apps with Microsoft® Visual C#® and Visual Basic® Step by Step (2013)

Chapter 1. Introduction to Windows Store apps

After completing this chapter, you will be able to

§ Understand the main features of a Windows Store app.

§ Evaluate the key benefits of creating an app for Microsoft Windows 8.

§ Recognize the main capabilities and features of the new Windows 8 operating system.

This chapter provides an overall introduction to Windows 8 and the new world of the Windows Store apps from a developer perspective. In this chapter you will learn the basics of the Windows 8 user interface (UI), as well as gain an overview of the new features and capabilities that this new platform provides. The chapter targets any developer—even those who have not yet seen Windows 8. You will also learn how to set up a development environment for building your own Windows 8 apps.

The Windows 8 experience

Windows 8 is one of the most innovative and revolutionary operating systems investments made by Microsoft in the last decade. Before Windows 8, the operating systems market was divided into at least three main families: server operating systems, client/desktop operating systems, and mobile/tablet-oriented operating systems.

Windows 8, together with its sibling on the server side, Windows Server 2012, introduces a new paradigm where the client/desktop OS and the mobile/tablet-oriented OS can be exactly the same, sharing features, capabilities, user interfaces, and behaviors. In the last few years, there has been an explosion of tablet devices, and the number of people working at home and in their offices using the same small tablet devices is increasing. Nevertheless, until the release of Windows 8, it was not so simple to combine the preferences and needs of users with the infrastructure constraints of corporate networks. For example, employees would like to be able to install software on their own tablets, taken from a more-or-less checked and trustable marketplace available on the Internet, regardless of the corporate policies of their companies. Moreover, these employees would like the ability to check their corporate email accounts, as well as any private email accounts, using a unique device and unique email client software. Furthermore, the emerging social-oriented consumption of devices leads to the sharing of private contacts, agendas, tasks, pictures, and instant messages through business contacts, meetings, and corporate network instant communication and video-conferencing.

However, technology without governance could become a nightmare both for users and IT professionals. With Windows 8, employees can leverage a corporate-provided tablet device that allows them to install their choice of software from a safe and secure marketplace, either publicly or corporately constrained. Using this single device, they can check multiple email accounts or socialize with friends, colleagues, and business contacts—all while remaining compliant with their employer’s security policies within a safe and sandboxed environment.

Moreover, for the sake of backward compatibility, most of the software targeting Windows 7 desktops will still continue to work on Windows 8, using the old-style desktop-oriented approach.

So, let’s explore the new Windows 8 UI and the key features of this new operating system. Figure 1-1 shows the new Start screen, which is one of the most apparent changes introduced with Windows 8.

Figure 1-1. The new Windows Start screen.

As shown in Figure 1-1, the new Start screen is composed of a set of squares and rectangles, called Tiles, each of which represents a link to a software application, and can provide animated feedback to users. Tiles can be either square or wide tiles. Many apps provide both sizes so users can choose the one that best suits their needs. For example, in the upper-left corner of Figure 1-1, just under the Main title, there’s a wide tile for the Mail App, which indicates that there are 15 email messages in the inbox. The tile also provides a brief preview of the messages.

To reduce the size of the tile you can right-click it, or swipe down on the tile, which selects it and activates a command bar, called the App Bar, which will be discussed later. Figure 1-2 shows how the Mail App tile looks after it has been selected.

Figure 1-2. The Mail App tile is selected, and the App Bar is visible.

Several commands are available in the App Bar. For example, you can select the Smaller command to reduce the tile’s size from wide to square. You can also turn off the dynamic update feature of the tile, by clicking Turn Live Tile Off, or you can click Uninstall to remove the app from your device. If you click the Smaller command, the tile becomes square and the preview of unread email disappears (see Figure 1-3).

Figure 1-3. The Mail App tile after clicking the Smaller command on the App Bar.

A user with a tablet device can tap (that is, touch using a single finger) a tile to start an application instance or to resume an already running instance. A user with a desktop PC and a mouse can click the tile to get the same result. The Start screen is based on the idea of the panorama view, which has been available in the Windows Phone since version 7.0. You can scroll horizontally, using either touch gestures on a touch-enabled device or the mouse wheel, or if you are working on a desktop, the keyboard. You can also use the traditional scrollbar that appears at the bottom of the screen.

As soon as you tap an app tile, that app will become the foreground application. If you are starting that app for the first time in a given session, Windows will create and load the app instance in memory. Subsequently, when the app is already running, tapping the app tile switches that app to the foreground application. In both cases, the previous application is sent into the background and may eventually be suspended by the operating system. Suspension means freezing; a suspended app uses no CPU threads and no I/O functionality is provided to the application, leaving all the computer resources to the main (foreground) application. When you return to a suspended application, the operating system resumes it in its previous state. In Chapter 4, you will learn more about the application lifecycle for Windows Store apps. Figure 1-4 shows the Bing Weather App running in the foreground.

Figure 1-4. The Bing Weather App running in the foreground.

By default, an app uses the entire screen, in order to satisfy one of the main concepts of the user experience design of Windows Store apps: “content, not chrome.” In Chapter 2, you will discover more about exactly what user experience design means.

Not all apps that run under Windows 8 are Windows Store apps. If you start an old-style desktop application, you will see the classic and familiar Windows Desktop UI, just as if you were running a previous version of Windows. Figure 1-5 shows an old-style application, in this case SQL Server Management Studio, running in desktop mode. Notice the absence of the classic “Start” button.

Figure 1-5. SQL Server Management Studio running in the classic desktop mode.

You aren’t always limited to a single full-screen application, however. If you have a device with a 1366 × 768 or higher resolution, you can leverage the Windows 8 capability to “snap” two applications into the display area. Figure 1-6 shows the Bing Weather App snapped together with the new Microsoft Internet Explorer 10 for Windows 8.

Figure 1-6. The Bing Weather App snapped together with Internet Explorer 10.

Of course you can also switch the relative sizes of two snapped apps, as shown in Figure 1-7.

Figure 1-7. An example of switching two app panes, with the Weather App in the larger pane and Internet Explorer 10 in the smaller pane.

From a developer perspective, the important thing to understand and master is that every Windows Store app must support snapping; otherwise, it won’t be certified by the Windows Store. The Bing Weather App, as shown in the previous figures, supports the snapped view. When snapped, it adapts its page layout to present information in a small horizontal portion of the screen. If your apps are unable to present information in a snapped view, you must fill the snapped pane where your application would be with a clear message for the user. You should never use the “full-screen” view for a snapped view because the user would not be able to interact properly with the application.

In fact, whenever you want to develop and publish a Windows Store app you have to submit it to the Windows Store, or eventually to a corporate catalog. From the official and public Windows Store viewpoint, an app must adhere to a clear set of requirements to be certified. Any application that does not adhere to these requirements will be rejected. You can find more details about the requirements in the Windows 8 developer section of MSDN (Microsoft Developer Network): http://msdn.microsoft.com/library/windows/apps/hh694083.aspx. For example, one rule states that you have to provide a privacy information page if your app connects to the Internet for any purpose. Thus, if your app invokes a remote web service, which is a common situation, you must provide a privacy page illustrating how you manage users’ data. In Chapter 4, you will learn how to submit an app to the Windows Store.

Turning the focus back to the Start screen, another useful feature is that you can collect tiles into groups to organize them better in the menu. To move a tile from one group to another you just drag it, using touch gestures or the mouse. To create a new group you need to move a tile into the middle region between two existing groups. A gray bar will appear that represents the frame of the new group, and dragging the tile onto this gray bar will create the new group. By using a specific gesture (pinch) that will be explained in Chapter 2, or rolling the mouse wheel backward while pressing the Ctrl key, the Start screen zooms out so you can see more groups. By clicking a group, or swiping your finger down on a group to select it, you can give that group a name using a command in the App Bar. In Figure 1-8, you can see the UI of the Start screen while zoomed out, with a group of tiles selected and the App Bar showing the available commands.

Figure 1-8. The Start screen zoomed out with the App Bar available.

Charms and App Bars

Other new and key features of Windows 8 are the App Bars and Charms. In Chapter 2, you will see more information about these features and the philosophy behind them. For now, simply consider that the need to support new devices, such as tablet and mobile devices, and the need to make the apps usable with just your hands, introduced new tools through the new touch-oriented perspective and solutions. In Windows 8 you have two kinds of App Bars: the bottom App Bar and the top App Bar. As their names indicate, these two kinds of App Bars are shown, respectively, in the lower and upper regions of the screen. Using the bottom App Bar, you manage tasks and actions related to the current context or item. Figure 1-9 shows an example with Internet Explorer 10, where you use the bottom App Bar to edit the current URL or enter a new URL, refresh the page, pin the page to the new Start screen, or change browser settings.

Figure 1-9. Internet Explorer with the bottom App Bar showing the URL.

In contrast, the top App Bar is used to provide navigation aids. For example, you can use it to show such things as a top-level menu or a list of main sections available in the current app. Figure 1-10 shows the top App Bar of the Windows Store app, which is an app you can use to search, download, buy, and install other apps.

Figure 1-10. The Windows Store app with the top App Bar showing.

To show the App Bars, you can swipe your finger from the top or bottom border of the screen to the center of the screen. Alternatively, you can press Windows+Z on the keyboard, or right-click.

Charms allow you to access the most useful features and actions provided by the operating system. For example, you can use Charms to access system settings, the local search engine, the sharing features, and so on. Figure 1-11 shows Charms in action.

Figure 1-11. Charms are on the right side of the screen.

To display Charms, you can swipe your finger from the right border of the screen to the center of the screen, or you can press Windows+C. You can also move the cursor to either of two invisible “hot spots” in the lower-right or upper-right corner of the screen. Finally, you can directly activate specific Charms using keyboard shortcuts. For example, pressing Windows+Q activates a search for the installed applications (Q stands for query), whereas pressing Windows+F (F stands for Find Files) activates the search for files function. To activate the sharing feature, press Windows+H.

Through Charms you can also activate specific panels, such as the Settings Panel, which can be activated by pressing Windows+I. In Figure 1-12, you can see the Settings Panel in action.

Figure 1-12. The Settings Panel is visible on the right side of the screen.

One key feature of Charms is that you can also host custom commands and custom panels in it. For example, if you are developing a Windows Store app and you want to provide some custom settings for users, you can add a custom Charm. By selecting the custom command while the app is in the foreground, you can activate a fly-out panel, which is a custom control that renders within the Charms. Figure 1-13 shows the fly-out panel.

Figure 1-13. A custom fly-out panel rendered within Charms.

The Charms shown in Figure 1-13 provides Support Request and Privacy Policy commands, which are custom and specific to the app currently in the foreground. The latter command leads users to the privacy page required for any Windows Store app that consumes a remote service over the Internet, as you learned earlier in this chapter.

The Windows Runtime

A Windows Store app is a software solution that adheres to the UI and technical specifications of the Windows Store. You can create a Windows Store app using any language that supports the Windows Runtime (WinRT). The WinRT is a rich set of application programming interfaces (APIs) built upon the Windows 8 operating system, providing direct and easy access to all the main primitives, devices, and capabilities for any language available to develop Windows 8 apps. The WinRT is available only for Windows 8 apps and its main goal is to unify the development experience of building a Windows 8 app, regardless of the programming language you use.

Saying that you can use any language supporting the Windows Runtime means that, currently, you can choose from C++, .NET (C# or VB), and JavaScript. Nevertheless, there are no technical limitations to support the Windows Runtime from any other language, as long as it adheres to the Windows Runtime specifications.

In Chapter 5, you will learn more about this topic and the architecture of the Windows Runtime. For now, you can imagine the Windows Runtime as an infrastructural framework of libraries that allows easy development of Windows Store apps, hiding all the inner details of the operating system from the common and everyday developer perspective. For instance, you can ask the Windows Runtime to open the webcam standard UI to capture photos or videos without knowing anything about the underlying driver or Win32 API.

For example, in the following code excerpt you can see how simple it is to capture a picture from the camera of your PC, using the C# language.

private async void TakePhoto_Click(object sender, RoutedEventArgs e) {

var camera = new CameraCaptureUI();

var img = await camera.CaptureFileAsync(CameraCaptureUIMode.Photo);

if (img != null) {

var stream = await img.OpenAsync(FileAccessMode.Read);

var bitmap = new BitmapImage();

bitmap.SetSource(stream);

image.Source = bitmap;

}

}

You can perform the same action using JavaScript, with the following code excerpt:

var dialog = new Windows.Media.Capture.CameraCaptureUI();

dialog.captureFileAsync(Windows.Media.Capture.CameraCaptureUIMode.photo).done(function (file) {

if (file) {

var photoBlobUrl = URL.createObjectURL(file, { oneTimeOnly: true });

document.getElementById("capturedPhoto").src = photoBlobUrl;

}

};

Moreover, you can achieve the same result using C++, as shown in the following code excerpt:

void CaptureWin8::MainPage::TakePhoto_Click(Platform::Object^ sender,

Windows::UI::Xaml::RoutedEventArgs^ e) {

CameraCaptureUI^ dialog = ref new CameraCaptureUI();

concurrency::task<StorageFile^> (

dialog->CaptureFileAsync(CameraCaptureUIMode::Photo)).then([this]

(StorageFile^ file) {

if (nullptr != file) {

concurrency::task<Streams::IRandomAccessStream^> (

file->OpenAsync(FileAccessMode::Read)).then([this] (

Streams::IRandomAccessStream^ stream) {

BitmapImage^ bitmapImage = ref new BitmapImage();

bitmapImage->SetSource(stream);

image->Source = bitmapImage;

});

}

});

}

Badges, Live Tiles, Toasts, and Lock Screen

Another set of new features found in Windows Store apps includes Badges, Live Tiles, Toasts, and the Lock Screen. Badges and live tiles show dynamic information to users even while they are not directly using the app providing the information—the tiles display such information directly on the Start screen. You can use a badge and/or a live tile to provide information about news, new items to check, new tasks to execute, or whatever else is meaningful for the user to best experience your app from the Start screen, without opening the application. For example, the out-of-the-box Mail App uses the badge to show the number of unread emails in the inbox, and a live tile to show a rotating list of excerpts from all the unread messages. Moreover, the Windows Store App notifies you through a badge about the number of updates available for apps you have installed. In Figure 1-14, you can see these badges and live tiles in action.

Figure 1-14. The Start screen with badges and live tiles in action.

Notice the number 4 in the bottom-right corner of the Windows Store app; this badge indicates that there are four pending updates. You can also see the badge with 15 in the bottom-right corner of the Mail app, indicating 15 new emails in the inbox. Furthermore, the Mail app uses a live tile to show an excerpt of the most recent unread emails, but a live tile can do even more. For example, a live tile can completely change its content in order to be dynamic and fresh and to trigger curiosity in the mind of the user. Figure 1-15 shows four different states that the tile of a single app can assume (the Bing Travel app that ships with Windows 8).

Figure 1-15. The Bing Travel App tile assuming four different states.

The official guidelines for Windows Store apps (see http://msdn.microsoft.com/en-us/library/windows/apps/hh465403.aspx) suggest using a wide tile only when your app has live tiles to show. Otherwise, you should use square tiles when your tiles contain static content, and simply use a badge for small and lightweight notifications. In Chapter 9, you will learn how to create a live tile.

Toasts are another technique for providing asynchronous alerts to the user. For example, an alert or alarm application can ask the operating system to send to the user a toast at a preset time; the Windows Runtime will send the toast even if the application is not running at that time. Moreover, when users are working on an app in the foreground, background apps will not be able to interact with them unless the app uses a toast.

In fact, as you will see in Chapter 4, due to the architecture of Windows 8 and because of the application lifecycle management of Windows Store apps, only the foreground app has the focus and is running; all the other background apps can be suspended (or even terminated) by the Windows Runtime. A suspended app cannot execute or consume any CPU cycle. However, you can define a background task (more on this topic later in this chapter) that will work in the background, even in a separate process from the owner app, and you can define background actions. When these actions need to alert users about their outcomes, they can use a toast.

A toast can be plain text, an image, or any combination of the two. In the upper-right corner of Figure 1-16, you can see a toast provided by the Windows Store app informing the user that an app installation task has completed in the background.

Figure 1-16. An example toast message shown in the upper-right corner of the screen.

In Chapter 9, you will learn how to create a toast for your own Windows 8 apps.

One other option you possess while developing a Windows Store app is to provide lightweight information to the user through the Lock screen. The Lock screen is the screen that is shown when a Windows 8 user session is locked out, for example after a period of inactivity or when a user presses Windows+L to lock the session.

Figure 1-17 shows the Lock screen providing some information about the current date and time, the next appointment in the user’s agenda, and a set of small icons, in the lower part of the screen.

Figure 1-17. Lock screen showing status information.

Those icons provide information about the network connection status, battery status (for a device running on battery power), number of unread emails in the inbox, and some other lightweight information. A user can choose what information appears in the Lock screen by using the proper panel in the system configuration. However, you are limited to no more than seven Lock screen items simultaneously providing detailed information. All seven apps will be able to show badges and toasts in the Start screen, but only one of those apps will be allowed to show the text of its latest tile notification in the Lock screen. Figure 1-18 shows the configuration panel for the Lock screen. To reach it, you need to display the Charms; for example, press Windows+C, and then select the Settings command. Finally, click the Change PC Settings command. Under the Personalize section in the Lock screen tab, you will find the Lock screen configuration.

Figure 1-18. The Lock screen configuration panel in the PC Settings.

The Lock screen configuration allows you to choose a background image, select which seven apps will execute in the background to provide information through the Lock screen icons, and—last but not least—choose the app that will be allowed to display detailed text status. The last one, by default, is configured to be the Calendar app. For your apps to be available as Lock screen apps, your software must declare that capability within an app manifest file, which will be explained later in this book, starting with Chapter 3.

The information shown by a Lock screen–enabled app is the same as the information provided by the app’s tile on the Start screen. In fact, the text shown beside the Lock screen icon is taken from the badge of the app, whereas the detailed text status is taken from the tile text of the app.

Background tasks

As stated earlier in this chapter (and as will be explored more in Chapter 4), a Windows Store app executes code only when it is the foreground app. However, there are situations where you want to execute some code when your app is in the background. A background task can execute code even when the corresponding app is suspended, but it runs in an environment that is restricted and resource-managed. Moreover, background tasks receive only a limited amount of system resources. You should use a background task to execute small pieces of code that require no user interaction. You should not use a background task to execute complex business logic or calculations because the amount of system resources available to background apps is both tight and limited. In addition, complex background workloads consume battery power, reducing the overall efficiency and responsiveness of the system.

To create a background task, you have to define a class and register it with the operating system. A background task is just a class that implements a specific interface (IBackgroundTask in C#, for example) defined by WinRT and that is registered by using a BackgroundTaskBuilder class instance. There are many types of background tasks available, and these respond to different kind of triggers, such as the following:

§ ControlChannelTrigger. Raised when there are incoming messages on the control channel.

§ MaintenanceTrigger. Raised when it is time to execute system maintenance tasks.

§ PushNotificationTrigger. Raised when a notification arrives on the Windows Notifications Service channel.

§ SystemEventTrigger. Raised when a specific system event occurs.

§ TimeTrigger. Raised when a time event occurs.

In particular, a SystemTrigger can occur in response to any of the following system events:

§ InternetAvailable. An Internet connection becomes available.

§ LockScreenapplicationAdded. An app tile is added to the Lock screen.

§ LockScreenapplicationRemoved. An app tile is removed from the Lock screen.

§ ControlChannelReset. A network channel is reset.

§ NetworkStateChange. A network change, such as a change in cost or connectivity, occurs.

§ OnlineIdConnectedStateChange. An online ID associated with the account changes.

§ ServicingComplete. The system has finished updating an application.

§ SessionConnected. The session is connected.

§ SessionDisconnected. The session is disconnected.

§ SmsReceived. A new SMS message is received by an installed mobile broadband device.

§ TimeZoneChange. The time zone changes on the device (for example, when the system adjusts the clock for daylight saving time).

§ UserAway. The user becomes absent.

§ UserPresent. The user becomes present.

Whenever such an event occurs, you can check a set of conditions to determine whether your background task should execute. The conditions you can check include the following:

§ InternetAvailable. An Internet connection must be available.

§ InternetNotAvailable. An Internet connection must be unavailable.

§ SessionConnected. The session must be connected.

§ SessionDisconnected. The session must be disconnected.

§ UserNotPresent. The user must be away.

§ UserPresent. The user must be present.

To optimize resource consumption, some trigger notifications are provided only to apps that have been included in the Lock screen. For example, a TimeTrigger can be leveraged only by an app in the Lock screen. The same requirement holds true for PushNotificationTrigger andControlChannelTrigger. Even some of the SystemTrigger events are reserved for apps in the Lock screen, including events such as SessionConnected, UserPresent, UserAway, or ControlChannelReset. Because you should register for these events and triggers only if your application is in the Lock screen, you use the SystemTrigger events LockScreenApplicationAdded and LockScreenApplicationRemoved so that your app can register and unregister such triggers accordingly.

Generally speaking, in common language runtime (CLR) and C++ apps, you can execute a background task in the app itself or in a system-provided host (BackgroundTaskHost.exe). Additionally, you can also execute tasks for triggers of the type PushNotificationTrigger orControlChannelTrigger in the app process.

One last topic to properly complete the introduction of background tasks is resource management. Every background task must execute its code using a constrained amount of CPU and network bandwidth. For example, each app on the Lock screen receives two seconds of CPU time every 15 minutes, plus two more seconds allotted to background task execution just after the previous two seconds. In contrast, apps that are not on the Lock screen receive one second of CPU time every two hours.

From a network bandwidth perspective, these constraints are a function of the amount of energy consumed by the network interface. For example, with a throughput of 10 Mbps, an app on the Lock screen can consume about 450 MB per day, whereas an app that is not on the Lock screen can consume about 75 MB per day.

These constraints are defined to reduce battery and resource consumption. It’s worth noting that these rules do not apply to apps that rely on critical background tasks, such as ControlChannelTrigger and PushNotificationTrigger. Instead, these kinds of tasks receive guaranteed resources. Finally, there is a global pool of resources (CPU and network) that is shared across apps and can be used to provide some extra resources to those apps that need them. Of course, an app should not rely on such resources being available because they are shared between all background tasks for any app—in other words, another app could have already consumed all the global pool resources. The global pool is refilled every 15 minutes, with a refill quota related to the power source of the device (AC adapter or battery).

Contracts and extensions

Another powerful set of features available for developing Windows Store apps are WinRT Contracts. The Windows Runtime and Windows Store apps can share data, information, features, and behaviors through shared communication contracts. A contract is an agreement between an app and the Windows 8 operating system that allows an app to talk to and exchange data with any other app, without directly knowing anything about the other app, using the operating system and WinRT as a proxy.

For example, launch the Bing Travel app from the Start screen and navigate to a target travel location, such as Rome in Italy. Then show the Charms (Windows+C) and select the Share command. You will see a fly-out panel within the Charms that lets you select how you want to share that location: by email, to friends using the People app, or via any other Windows Store app configured as a sharing target for the current content. Figure 1-19 shows an example of this process.

Figure 1-19. Sharing a location by taking advantage of a communications contract baked into the Bing Travel app.

As soon as you have made a choice, for example by selecting Mail, Windows will take you into the sharing target app, and you can handle the shared content there. For example, Figure 1-20 shows how you can send the Rome information to someone via email in Windows Mail.

Figure 1-20. Sharing Rome information by email via the Windows Mail app.

It’s worth reiterating that neither of the apps involved in this sharing transaction (Bing Travel or Windows Mail) is aware of the other. The Windows Runtime, sitting in the middle, joins them through a contract called a Share contract.

Similarly, when you are using an app such as the Windows Store app, and you activate the search feature (Windows+Q), the operating system uses a Search contract to query the Windows Store app for apps that satisfy the search criteria provided.

The Windows Runtime exposes a rich set of contracts, as shown in the following list:

§ Cached File Updater contract. You can leverage this contract to keep track of file changes and cache them. For example, an app like SkyDrive uses this contract to monitor file changes.

§ File Picker contract. You can register your app as a target for the File Picker UI.

§ Play To contract. This allows your app to be enlisted in the list of apps available in the Play To section of the Connect command in the Charms.

§ Search contract. This provides search capabilities to your app.

§ Settings contract. This contract provides a panel for custom settings of your app.

§ Share contract. This contract shares content between apps.

There are also extensions that allow an app to adhere to an agreement with the operating system instead of with a third-party app. You can use these extensions to extend standard Windows features. For the sake of simplicity, consider what happens when you connect a new device or insert a disk into the CD/DVD reader. An operating system message appears that informs users that they can play the new device or media, providing a list of available actions and players. For example, you can register your app as supporting the AutoPlay extension, and subsequently your app will be listed in the list of available autoplay targets.

You can see an enumeration in the following list:

§ Account picture provider. When a user changes his or her account picture, you can register an app as an account picture provider.

§ AutoPlay. The app will be listed as an autoplay target.

§ Background tasks. The app can run background tasks.

§ Camera settings. The app provides custom UI for camera settings.

§ Contact picker. The app is registered as a contact picker provider.

§ File activation. The app is registered as being associated with a specific file type based on the file extension.

§ Game Explorer. You can register the app as a game, providing a Game Definition File (GDF), and your app will be available as a game only if compliant with the target machine’s family safety rules.

§ Print task settings. This declares that your app has a custom printer UI and can print by talking directly to a printer device.

§ Protocol activation. You can register a protocol moniker associated with your app. For example, Windows Mail can be activated with a mailto: protocol moniker. Internet Explorer 10 can be activated with an http: protocol moniker. You can register your own moniker and use it to activate your app.

§ SSL/certificates. Enable your app to install a digital certificate onto the target device.

As you will see in Chapter 3, registering or consuming a contract through WinRT is very straightforward.

Visual Studio 2012 and Windows 8 Simulator

To develop a Windows Store app, you will need to install a development environment such as Microsoft Visual Studio 2012. To accomplish this task, you can buy and install a regular license of Microsoft Visual Studio 2012 directly from Microsoft or from an authorized reseller. However, you can also get started by downloading and installing a free edition of Visual Studio 2012, called Visual Studio 2012 Express edition. In particular, the Express family contains one product named Visual Studio 2012 Express for Windows 8. Using this development tool, you can create Windows Store apps by starting from scratch or starting with a set of prebuilt application templates and models. You can download Visual Studio 2012 Express for Windows 8 from the Microsoft website at http://www.microsoft.com/visualstudio/, or you can find it in the Windows Store app, under the “Tools” app category. Figure 1-21 shows the page dedicated to Visual Studio 2012 Express for Windows 8 in the Windows Store app.

Figure 1-21. The Visual Studio Express 2012 for Windows 8 page in the Windows Store app.

After installing Visual Studio Express 2012 for Windows 8, you will be able to create custom apps and publish them to the Windows Store—a process discussed in much more detail in Chapter 3 and Chapter 4.

Note that you can download and install a retail version of Microsoft Visual Studio 2012 (that is, Professional, Premium, or Ultimate) even on previous editions of Windows. For example, suppose you don’t have a Windows 8 PC; instead, you have a machine running Windows 7. You can still install Visual Studio 2012 and develop your software solutions on Windows 7, but you will not be able to develop Windows Store apps on it.

NOTE

You cannot download and install the free Microsoft Visual Studio 2012 Express for Windows 8 edition on a computer without Windows 8; that edition requires you running Windows 8 or later.

One useful option for testing and executing your apps is to use the Windows 8 Simulator, which is part of the Windows 8 SDK included in Visual Studio 2012.

Figure 1-22 shows the Windows 8 Simulator in action.

Figure 1-22. The Windows 8 Simulator.

As you can see, the simulator looks like a small tablet PC running Windows 8. On the right side there is a set of commands to simulate various scenarios. These commands are, from top to bottom:

§ Always on top. Puts the simulator always on top.

§ Mouse mode. When you move and click your mouse, the simulator will react to mouse interactions as well.

§ Basic touch mode. Your mouse pointer will become like a finger and when you click the simulator it will be handled as a finger touch.

§ Pinch/zoom touch mode. Similar to the previous option, but used to simulate zoom in and zoom out via touch gestures.

§ Rotation touch mode. Similar to the previous option, but used to simulate touch rotation gestures.

§ Rotate clockwise (90 degrees). Rotates the device clockwise 90 degrees.

§ Rotate counterclockwise (90 degrees). Rotates the device counterclockwise 90 degrees.

§ Change resolution. Changes the screen resolution of the simulator device. The available resolutions are:

§ 10.6” 1024 × 768

§ 10.6” 1366 × 768

§ 10.6” 1920 × 1080

§ 10.6” 2560 × 1440

§ 12” 1280 × 800

§ 23” 1920 × 1080

§ 27” 2560 × 1440

§ Set location. Allows simulating a GPS location for testing location-based apps.

§ Copy screenshot. Creates a screenshot of the simulator screen. This is useful for creating promotional pictures of your apps and the required images to publish an app on the Windows Store.

§ Screenshot settings. Configures copy screenshot behavior, such as the destination directory of the image files.

§ Help. Provides a link to the simulator’s Help.

Using the Windows 8 Simulator, you can test your apps fully, even without a real tablet device or a Windows 8 environment.

One of the most important features of the simulator is the ability to change the resolution, orientation, and form factor of the screen to test the application behavior for many different “devices” without the need to buy real ones.

Also, remember that you cannot develop a Windows Store app using Microsoft Visual Studio 2010 or any other earlier edition of the product. The only edition of Microsoft Visual Studio suitable for developing Windows Store apps is Visual Studio 2012 or later.

Summary

In this chapter, you have been introduced to some basic information about Windows 8 and Windows Store apps. You learned the key new features of the Windows 8 UI, as well as the main goals behind the development of a Windows Store app. You saw several apps and features, including the Windows Store, badges, live tiles, toasts, background tasks, the new Lock screen, the new Start screen, and more. You also learned about the development environment required to develop Windows Store apps.

Quick reference