“Oh, no, not another cliché ‘Hello, World’ example,” you might be thinking as you examine this book. However, the length of this chapter alone should tell you that it is not about creating a typical “Hello, World” app.

Sure, we’re going to get started with a simple, contrived app to demonstrate the anatomy of any Windows Store XAML app and the tooling available in Visual Studio. But we’ll also see how to make it really say “hello” to the entire world; not just English-speaking people with no disabilities. This means understanding how to localize an app into other languages so you can exploit the vast, global scale of the Windows Store. It also means understanding how to make your app accessible to users who require assistive technologies such as screen readers or high contrast themes. No app deserves to be called “Hello, World” without considering these features.

Creating, Deploying, and Profiling an App

In Visual Studio, let’s create a new Visual C# Blank App (XAML) project called HelloRealWorld. This gives us a project that’s ready to compile and run. Although pressing F5 or clicking the Start Debugging button in Visual Studio launches the app locally, you’ve got three slick options to choose from via the button’s dropdown menu, shown in Figure 1.1 under Visual Studio’s light theme (used throughout this book).

FIGURE 1.1 The three ways to launch your app in Visual Studio

With the Remote Machine option, you can deploy and debug to any other Windows 8.x computer reachable on your network (although not over the Internet). This is extremely handy for testing things on a Surface or other tablets. The target device must have the Remote Tools for Visual Studio installed and running, which you can download from the Windows Dev Center.

The Simulator option is the next best thing to having a real tablet, as it provides mechanisms to simulate touch input, device orientations, network conditions, location services, and more. The simulator is shown in Figure 1.2. In fact, it has one huge advantage over testing on a physical device: It enables you to experience your app in a number of different resolutions and virtual screen sizes, including different aspect ratios. Given the wide variety of shapes and sizes of screens out there that run Windows Store apps, testing your app in this fashion is a must.

FIGURE 1.2 Testing your app on the simulator is like testing it on an army of different-sized devices.

The simulator is your actual computer!

Although the simulator simulates several things, what you see on the virtual device is your real “host” computer running with your actual user account, apps, files, and so on. (Running the simulator is like initiating a special kind of remote desktop connection to yourself.) Changes you make inside the simulator affect your computer just as if you made them outside the simulator.

How do I run my app outside of Visual Studio?

Although compiling your app produces an .exe file in the bin\Debug or bin\Release subfolder, you can’t simply double-click it from the Windows desktop to run it. If you try, you get an error that explains, “This application can only run in the context of an app container.” (An “app container” refers to the sandbox in which all Windows Store apps run.)

Instead, you can launch it from the searchable list of apps underneath the tiles on the Start screen. Visual Studio automatically installs your app the first time you launch it. Like all Windows Store apps in Windows 8.1, however, its tile does not automatically get pinned. Because the Start screen has been enhanced to make it easier to find apps, pinning is now meant to be done selectively by a user, the same as with pinning apps to the desktop taskbar.

When you run the HelloRealWorld project without any changes, you’ll see why the project type was called “Blank App.” The app doesn’t actually do anything other than fill the screen with darkness. (If you launch the app in debug mode, you’ll also see four numbers on the top edge of the screen. These are frame rate counters described in Chapter 17, “Animation.”) It does, however, set up a lot of infrastructure that would be difficult and tedious to create from scratch. The project contains the following items:

The package manifest, a temporary certificate used to sign it, and some images

The next section examines the package manifest and the images used by it. After that, we’ll look at the XAML and C# files and make some code changes.

Visual Studio provides some amazing tools for diagnosing performance problems in your app. You can access them by clicking Performance and Diagnostics on the Debug menu. On this page, select a tool to collect data while your app is launched. You perform the scenario you want to measure, and then stop the data collection. A rich, interactive report is then presented to you. The three tools on the Performance and Diagnostics page are:

XAML UI Responsiveness—Attributes the time spent to activities such as parsing XAML and layout of your elements. Shows you the performance cost of each UI element. You can also investigate times when you’re not achieving the desired 60 frames per second on the UI thread.

Energy Consumption—Estimates how power-hungry your app is, based on its usage of the CPU, display, and network.

In addition to the Visual Studio tools, you can download the Windows Performance Toolkit for additional analysis. This includes a Windows Performance Recorder tool for capturing a trace, and a Windows Performance Analyzer tool for analyzing the trace.