Designing Windows Store Apps with HTML and JavaScript: An Overview

Objective 1.4: Plan for an application deployment

No matter how good your app is, users won’t use it if you don’t deploy it. Planning your deployment is an important part of developing your application. Microsoft decided that not all apps are allowed in to the Windows Store. Knowing these requirements and understanding how to configure your app for deployment is the topic of this objective.

You also learn how to deploy an app for your enterprise when you don’t use the public Windows Store.

Planning a deployment based on Windows 8 application certification requirements

To publish your app to the Windows Store, the first step is to acquire a developer account. The Express editions of Visual Studio require you to purchase such an account. MSDN subscribers already have an account that they can use for free.

After you have an account, register your new app with the Windows Store to reserve the name that you want to use. This name is then reserved for you for one year. After one year, the name will be free for other developers to use.

During this process, you also have to configure the way your app will be sold. Is it free? Are you using a trial? Or maybe in-app purchases? Answering these questions forces you to think about those steps before you start your app. You can plan your app around the business model that you want to support and make sure that your app fully supports it.

When you finish your app, you can submit it to the Windows Store. If you haven’t done so, you can now supply the information on your app name, selling details, and services such as in-app purchases or trial support.

You also need a rating for your app, which can be an age rating (such as 3+ or 16+) or a rating board (such as ESRB or PEGI). Think carefully about this rating; when in doubt, choose the strictest one. Especially if your app uses some public Internet service (such as Twitter), you need to use a rating of at least 12+ or even 16+ because you never know what shows up on users’ screens.

If your app uses some form of cryptography, you need to mention it. Other very important parts are the description, feature list, and screen shots of your app. Make sure to consider these options carefully. This information will show up in the Windows Store and it should convince a user to install your app.

Another important step is to ensure that the tester can fully use your app. If your app requires a web service to be available, make sure that the web service is running when your app goes through submission. If the tester needs to log on to your app, supply a demo account that gives the tester access to all features of your app.

Creating your app package

The most important part of your submission is the actual application data. Your app is submitted in what’s called an app package.

The easiest way to create an app package is with Visual Studio. If you are running the Express edition of Visual Studio, you have a Store menu with an option to Create App Packages. If you run Visual Studio Professional or higher, you can find the Store menu as a submenu of Project.

The Create App Package allows you to build a package and upload it to the Windows Store or to create it locally.

The package that gets created is an .appx file, which is a zip file. You can open it in Windows Explorer and check out the files in it after changing the extension to .zip. The package contains everything that’s required for your app, such as JavaScript, CSS, HTML, and images. It also contains some metadata in the form of a manifest (which you will learn about in the next section), a signature, and a block map.

The block map is a description of the data in your package, split into distinct blocks of data. By splitting your package into separate parts, the Windows Store can download only the parts that have changed when an update of your app is released. Downloading only the updated parts saves users a lot of bandwidth, which is becoming more and more important with mobile devices.

Certification requirements

After creating your package and submitting all the required information, you can submit your app to the Windows Store. Your app then goes through a series of tests to check your app thoroughly before it is allowed or disallowed from the Windows Store.

Microsoft released an official document (see the following More Info box) that outlines all certification requirements for the Windows Store. This document is frequently updated, so become familiar with it before publishing your app.

Some steps in this document are obvious. You shouldn’t submit an app that doesn’t work, doesn’t add any value, or is not branded. You are not allowed to hack the system. Trying to communicate with other apps or loading remote scripts is forbidden. Be careful with privacy-related data by giving the user some consent options.

Windows App Certification Kit

The Windows App Certification Kit helps you test your app in an automated way similar to the way Microsoft will test your app upon submission. The easiest way to run the Windows App Certification Kit is to create your app package from Visual Studio. After the package is created, Visual Studio asks you whether you want to start the validation process (see Figure 1-14).

After starting the Windows App Certification Kit, some information is collected; then you see the dialog box shown in Figure 1-15. The Windows App Certification Kit runs many tests for you.

Additional certification requirements

You shouldn’t depend solely on the results of the Windows App Certification Kit; you should also perform extensive manual testing of your app.

For example, you should test your app on multiple platforms. Maybe your app works great on your local PC, but that doesn’t mean it will work on a Microsoft Surface tablet or other less-resource-intensive systems. In some countries/regions, Microsoft helps by having special app development days during which you can come in and test your app on a series of devices. Microsoft also advises you about any issues your app may have.

Preparing an app manifest (capabilities and declarations)

When you create a new Windows Store app, Visual Studio adds a file called package.apxxmanifest to your project.

This file is called an application manifest. When you open the manifest, the Manifest Designer loads (see Figure 1-16).

The Manifest Designer includes pages that you can use to configure your app:

• Application Allows you to set some application-wide settings such as a start page and supported rotations. You can also configure notifications and tile update settings.
• Visual Assets Allows you to configure different resolutions for images that are shown in the Windows Store. You can also configure tile images and your splash screen.
• Capabilities Specifies the features or devices that your app can use on the user’s system.
• Declarations You configure how your app integrates with Windows and other apps.
• Content URIs Your app can load web pages into an iframe. Those pages are normally restricted and have limited access to the user’s system. Here you can specify URIs that can access geolocation devices and the Clipboard, and can send script notifications to your app.
• Packaging Allows you to configure the display name of your package, version, and publisher information.

The exam requires you to understand all elements of the manifest, but it pays special attention to the capabilities and declaration settings.

Why are those settings so important? They configure what your app is allowed to do on a user’s system. Instead of allowing every integration by default, Windows Store apps need to explicitly ask for permission. Users can see the list of required permissions when installing an app from the Windows Store and can decide whether they trust your app enough to allow those permissions.

For example, it would be strange if your RSS Reader app needed access to your webcam. It is a lot more likely for a chat application that features video chat. You can ask permission for the following capabilities:

• Enterprise Authentication Typically not needed for an app; it allows your app to connect to resources on an intranet that requires domain authentication.
• Internet (Client) Requests Internet action over public networks. This option is enabled by default and should be disabled if your app does not require the Internet.
• Internet (Client & Server) Allows both inbound and outbound connections.
• Location Requests access to the current location (from a GPS sensor or from network information).
• Microphone Requests access to the microphone’s audio feed.
• Music Library Requests access to the music library to add, change, or delete files.
• Pictures Library Requests access to the pictures library to add, change, or delete files.
• Private Network (Client & Server) Requests access to inbound and outbound network access for a user’s trusted places (such as home and work devices that are on the same network).
• Proximity Requests the capability to connect to other devices through Wi-Fi Direct or near field proximity radio.
• Removable Storage Requests access to removable storage devices. Allows you to add, change, or delete file types that you have defined in the Declarations page.
• Shared User Certificates Gives you access to application programming interfaces (APIs) for requesting the user to authenticate through a security card, certificate, and so on.
• Videos Library Requests access to the videos library to add, change, or delete files.
• Webcam Requests access to the webcam’s video feed so you can take snapshots or movies.

Although you should never select more capabilities than are strictly required, trying to access a restricted area of the system without the required capability results in an error.

Next to capabilities, you also need to configure your declarations, which are required to support contracts and extensions. (A contract defines an agreement between apps; an extension is an agreement between your app and Windows.)

The declarations that you can configure are the following:

• Account Picture Provider Allows users to use your app to change their account pictures.
• AutoPlay Allows users to choose your app in the auto play dialog box.
• Background Tasks Apps can use background tasks to run app code even when the app is suspended. Background tasks are intended for small work items that require no interaction with the user.
• Cached File Updater If your app caches file is on local disk, you can subscribe to events such as the user opening the file (so you can check to see whether there is a newer version) or to download newer versions of a file as soon as they are available. OneDrive (formerly known as SkyDrive) is a good example of this kind of behavior.
• Camera Settings Allows you to customize the flyout that displays camera options.
• Contact Picker Enables your app to show up in the list of apps that can provide contact data whenever a user looks for a contact.
• File Type Associations Allows your app to register for handling certain file types (files with the same extension). The file type can be an existing file type or a new file type that’s specific for your app.
• File Open Picker Allows users to directly select files from your app while using another app.
• File Save Picker Allows users to save files directly to your app from another app.
• Print Task Settings Allows you to customize the flyout that displays advanced print settings.
• Search Adds a search pane to your app that allows users to search in your app and in the data of other apps.
• Share Target Allows users to share data from your app with other apps.

There are many possibilities for integrating your app with other apps and with Windows. Whenever you want to implement any of these features, you should update your manifest accordingly.

An exception is when you add a Share or File Open contract. You can add these contracts in Visual Studio in the Add New Item dialog box (see Figure 1-17). When you use this dialog box, your manifest is updated accordingly.

Signing an app

To publish your app in the Windows Store, it has to be signed with a certificate. When locally testing your app, Visual Studio generates a certificate that can be used to install your app on a machine that has a developer license.

After creating your package through Visual Studio, you can find the package in the AppPackage folder. Inside this folder, you see a .cer file containing your certificate. When you publish your app to the Windows Store, a new certificate is generated that is linked to your publishers account. This certificate is then used by users to install the app.

Planning the requirements for an enterprise deployment

When deploying an enterprise app to users outside of your company, the easiest option is to use the Windows Store. By adding a sign-in page to your app, you can manage licenses and restrict access to your app.

However, if you want to deploy an app to internal users only, you probably don’t want to use the Windows Store. This process is called sideloading.

Although your app is not validated for the Windows Store, you should make sure that you still follow the certification requirements for the Windows Store. Use the Windows App Certification Kit to validate your app before distributing it inside your company.

The Windows Store normally creates a trusted certificate for you, but you have to create it if you deploy your app without the Windows Store. Make sure that your app is signed with a certificate that’s trusted by the PCs on which you will install your app. You can use a certificate that’s already installed on your company’s network or install a custom certificate specifically for your app.

When your company devices are domain-joined, you can easily configure a Group Policy that allows apps to be sideloaded. You can then install the apps by using the Deployment Image Servicing and Management (DISM) command-line tool or by running Windows PowerShell cmdlets.

Another option is to use Microsoft System Center Configuration Manager or Windows Intune. These commercial products that can manage Windows installations in a corporate environment are available from Microsoft.

Objective summary

• Microsoft has created specific requirements for apps that want to be distributed through the Windows Store.
• Use the Windows App Certification Kit to validate your app.
• An app manifest describes your app and states which integration with the operating system and other apps it supports.
• A certificate is required to distribute your app to other users. The Windows Store helps you generate a certificate.
• You can distribute your app within an enterprise by a process called sideloading, so you don’t have to use the Windows Store.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. What is contained inside your app package? (Choose all that apply.)

   1. HTML, JavaScript, and CSS files
   2. A block description
   3. A certificate
   4. A manifest

2. You want to access an external web service from your app. Which capability do you require?

   1. Internet (Client & Server)
   2. Internet (Client)
   3. Private network (Client & Server)
   4. Home Network (Client & Server)

3. You want to send your Windows 8 app to a group of testers. What should you do?

   1. Ask them to install Visual Studio and send them the source code of your app.
   2. Send them an app package with Windows PowerShell scripts.
   3. Create a Windows Installer to install the app on their devices.
   4. Submit the app to the Store so they can install it.