Author: Jeffrey Richter, Maarten van de Bospoort
Pub Date: 2013
Size: 12 Mb
Delve inside the Windows Runtime – and learn best ways to design and build Windows Store apps. Guided by Jeffrey Richter, a recognized expert in Windows and .NET programming, along with principal Windows consultant Maarten van de Bospoort, you’ll master essential concepts. And you’ll gain practical insights and tips for how to architect, design, optimize, and debug your apps.
With this book, you will:
Learn how to consume Windows Runtime APIs from C#
Understand the principles of architecting Windows Store apps
See how to build, deploy, and secure app packages
Understand how apps are activated and the process model controlling their execution
Study the rich features available when working with files and folders
Explore how to transfer, compress, and encrypt data via streams
Design apps that give the illusion of running using live tiles, background transfers, and background tasks
Share data between apps using the clipboard and the Share charm
Get advice for monetizing your apps through the Windows Store
About This Book:
Requires working knowledge of Microsoft .NET Framework, C#, and the Visual Studio IDE
Targeted to programmers building Windows Store apps
Some chapters also useful to those building desktop apps
Microsoft Visual Studio 2013
Important Because background tasks typically execute in a different process than the app’s process and because the app’s process might be terminated when the background task code executes, the background task code is not allowed to update the app’s user interface. However, a background task can update its app’s tiles or badges, or cause the display of a toast notification. In addition, the background task process runs in the package’s app container. This means that the manifest’s package capabilities and app declarations doapply to the background task process. In addition, the background task process can write to the package’s data settings and folders (discussed in Chapter 4, “Package data
and roaming”), and the package’s app can subsequently read this information. Similarly, an app can write to its package data, and its background tasks can read this data. This is the easiest way for an app and its background tasks to communicate data with each other. One
process can signal when data is ready by calling ApplicationData’s SignalDataChanged method, which raises a DataChangedevent.
Maintenance and time triggers
Maintenance triggers and time triggers behave identically: they execute some code at some future time. To allow the system to sleep as much as possible (conserving battery), these triggers fire at most 96 times a day (every 15 minutes). You can configure these triggers so that Windows runs your code just once, or you can have Windows run your code repeatedly (like once an hour).
The difference between these two triggers is that a maintenance trigger executes your code only if the PC is running plugged in on AC power.
On the other hand, a time trigger executes your code when the PC is on AC or battery power. Most people think that a time trigger is the better choice because your code is more likely to run. However, users must put your app on their lock screen in order for a time trigger to execute your task’s code, and users might decide not to do this. Putting an app on their lock screen is how users indicate that they are willing to let your app’s background tasks consume battery power. I’ll talk more about lock-screen apps later in this chapter’s “Lock-screen apps” section.
Although maintenance and time triggers behave identically, they serve different purposes. You typically use maintenance triggers fornonurgent opportunistic work, such as content indexing and renewing a Windows Push Notification Service (WNS) channel for updating tile, toast, and raw notifications.(See Chapter 8.) On the other hand, you typically use time triggers for urgent work that an end user really cares about—for example, an email program that periodically polls a server looking for new mail messages.
The system trigger allows your code to execute when a system-related event occurs. Table 9-2 lists all
the system trigger types and their lock-screen requirements.
Step 3: Add manifest declarations
Once you have implemented your background task code and decided which trigger you want to use, you must inform Windows of your background task WinRT components. You do this by adding declarations to the package manifest for your app. Figure 9-2 shows Visual Studio’s manifest designer with its Declarations tab selected. To add a background task to your app, select Background Tasks and then click the Add button. Then select the trigger you wish to use from the Supported Task Types list. Note that Audio is not a trigger; it allows your app to play audio when it is not in the foreground. For example, the Windows Music app enables this declaration. You’ll also notice that Maintenance is missing from the list. If you want to use a maintenance trigger, select System Event (do not select Timer).
The Windows Store commerce engine
Many Windows Store apps are available to users for free. Maybe the app didn’t take much effort to develop and the developer just wants to make it available. Or maybe the app is a rich client app over a service that users purchase in some other way (like the Netflix app, which is free because users must already have a valid Netflix subscription) to use the app. Some apps are also free because they incorporate advertising into the app using an advertising SDK, such as the Microsoft Advertising SDK for Windows. Be aware that advertising requires network access, forcing you to provide a privacy statement for your app, and advertising also works only when the user’s PC is connected to a network.
Developers can also integrate a commerce engine into their app, which allows them to collect revenue when users purchase the app or any in-app products. The Windows Store provides a commerce engine you can use within your app. However, you do not have to use the Windows Store commerce engine. You can use third-party commerce engines instead. In fact, PayPal offers a commerce engine and an SDK exposing WinRT components, which is available from Services.WindowsStore.com/PayPal. If you use a third-party commerce engine, you must list your app as Free on the Windows Store and notify users who the provider is when they make a purchase. (See the certification requirements, section 4.7.)
This section focuses on the Windows Store’s commerce engine because it is expected that many developers will use it and because the WinRT APIs to integrate with it are built into the Windows operating system itself.
The Windows Store commerce engine supports many features, including the following:
- Free app trials (time-based and feature differentiated). Providing users a free trial of your app is strongly encouraged because statistics show that users are more likely to purchase an app that they have tried and liked. Users are much less likely to purchase an app before they have the opportunity to try it out.
- A wide range of price points, ranging from $1.49 all the way up to $999.99.
- The ability to accept money in local currencies for 200 different markets around the globe.
- After a user purchases an app, the app can sell in-app products (like the ability to turn off inapp advertising or enabling the viewing of some video). In-app products can expire after some period of time like 1 day, 1 month, 1 year, or never.
If you choose to use the Windows Store commerce engine, Microsoft pays you 70 percent of the first $25,000 and 80 percent for all revenue beyond the first $25,000. Having different versions of your app does not affect this. That is, the total revenue earned does not reset if you create a newer version of your app.
Developers use the Dashboard’s Selling Details page to specify the price tier of their app, whether the app offers a trial period, and when this trial period expires. This is also where developers indicate if they want to use a third-party commerce engine for in-app purchases. If the developer wants to use the Windows Store’s commerce engine, users go to another webpage to specify the list of inapp products they wish to make available. Each product has a string ID, price tier (Free, or $1.49 to $999.99), and details about how long the user can use the product before it expires. Altogether, this information is referred to as the app’s listing information. An app’s listing information is not cached on
the user’s PC, so an Internet connection is required for an app to gets its own listing information at runtime.
When users purchase an app, they acquire a license for that app. Similarly, whenever users purchase an in-app product, they acquire a license for that in-app product. Windows maintains the user’s acquired licenses on the user’s PC. In fact, the license information is synchronized across all the user’s PCs. This allows the user to purchase an app or in-app product on one PC and, shortly thereafter, the app or product will be licensed on the user’s other PCs as well. Of course, the user must be connected to the Internet so that Windows can synchronize the license information. But, once a license is on a PC, an app can always check a license, even if the PC is not currently connected to the Internet.
Note Packages downloaded from the Windows Store are licensed to a user’s Microsoft account. This is usually the same account the user uses to log in to her PC. However, they do not have to be the same. In fact, a user can go to the Store app, display the Settings charm > Your Account pane, and change the Microsoft account she used to download packages from the store. I do this when I want to install a package I have already purchased on another family member’s PC (where that family member logs in as himself).
The Windows Store commerce engine WinRT APIs
Your app integrates itself with the Windows Store commerce engine by way of WinRT’s static Windows.ApplicationModel.Store.CurrentAppclass. However, when you’re developing an app, using CurrentAppis a problem because your app can’t interact with the Windows Store commerce engine if your app is not in the Windows Store. So, during development, WinRT offers another static class you use instead, CurrentAppSimulator. This class’ methods are identical to the CurrentApp class’ methods, but internally the methods simulate the Windows Store’s behavior. This allows you to test your app’s integration with the commerce engine during development. Here is what the CurrentAppand CurrentAppSimulatorclasses look like: