There’s a New Kid in Town

Smartphones and tablets are, without any doubt, the kings of the consumer market. Traditional
computers won’t go away anytime soon, especially in the business world, but in many scenarios
mobile devices have replaced the old “mouse and keyboard” approach with a more modern and
intuitive one, based on touch and natural interfaces. For sure, the iPhone by Apple was the
product that forced all the other companies to rethink the mobile experience: first, with a new
phone concept, and second, with the idea of applications and app stores. These days, one of
the key considerations when choosing a new phone is the availability and quality of the apps,
rather than just the features offered by the platform. Developers play an important role in this.

Microsoft might have joined the party a little late, but it did so with a fresh and new approach.
Microsoft was developing Windows Mobile 7 when it realized that the phone wouldn’t be an
appealing product for consumers who were starting to get used to iPhone or Android devices.
So its developers dropped the project and started from scratch to build a totally new platform:
Windows Phone 7. The result was really different from the other competitors: a new user
interface, based on a flat design style called Microsoft Design style (once known as Metro); and
deep integration with social networks and all the Microsoft services, like Office, SkyDrive, and
Xbox.

The current version of the platform (which will be covered in this series) is Windows Phone 8; in
the middle, Microsoft released an update called Windows Phone 7.5 that added many new
consumer features but, most of all, improved the developer experience by adding many new
APIs.

Windows Phone 8 is a fresh start for the platform: Microsoft has abandoned the old stack of
technologies used in Windows Phone 7 (the Windows Mobile kernel, Silverlight, XNA) to
embrace the new features introduced in Windows 8, like the new kernel, the Windows Runtime,
and the native code (C++) support.

For this reason, Windows Phone 8 isn’t available as an update for old Windows Phone 7
devices. To help users in the transition, Microsoft has released an intermediate update called
Windows Phone 7.8, which has ported some of the new Windows Phone 8 features (like the
new Tile formats) to the old devices.

Since the release of Windows Phone 8, Microsoft has released three updates:

Update 2 (or GDR2), which improved support for Google accounts, Xbox Music, and
Skype, added FM radio support, and expanded the availability of the Data Sense
application to keep track of the data traffic

Update 3 (or GDR3), which added support for a new resolution (1080p), driving mode,
screen lock orientation, and better storage management, and improved the Bluetooth
and Wi-Fi stack

The Hardware

Talking about the hardware is important because it’s strictly connected to the development experience and the features you can use while developing an application. With Windows Phone, Microsoft has introduced an approach that is a hybrid between Apple’s and Google’s.

Like Android, Windows Phone can run on a wide range of devices, with different form factors and hardware capabilities. However, Microsoft has defined a set of hardware guidelines that all manufacturers need to follow to build a Windows Phone device. In addition, vendors can’t customize the user interface or the operating system; all the phones, regardless of the producer, offer the same familiar user experience.

This way, Windows Phone can take the best from both worlds: a wide range of devices means more opportunities, because Windows Phone can run well on cheap and small devices in the same way it works well on high-resolution, powerful phones. A more controlled hardware, instead, makes the lives of developers much easier, because they can always count on features like sensors or GPS.

The Windows Runtime

The Windows Runtime is the new API layer that Microsoft introduced in Windows 8, and it’s the foundation of a new and more modern approach to developing applications. In fact, unlike the .NET framework, it’s a native layer, which means better performance. Plus, it supports a wide range of APIs that cover many of the new scenarios that have been introduced in recent years: geolocation, movement sensors, NFC, and much more. In the end, it’s well suited for asynchronous and multi-threading scenarios that are one of the key requirements of mobile applications; the user interface needs to be always responsive, no matter which operation the application is performing.

Under the hood of the operating system, Microsoft has introduced the Windows Phone Runtime. Compared to the original Windows Runtime, it lacks some features (specifically, all the APIs that don’t make much sense on a phone, like printing APIs), but it adds several new ones specific to the platform (like hub integration, contacts and appointments access, etc.).

Microsoft faced a challenge during the Windows Phone 8 development: there was already a great number of applications published on the Windows Phone Store that were based on the “old” technologies like Silverlight and XNA. To avoid forcing developers to write their apps from scratch, Microsoft introduced three features:

The XAML stack has been ported directly from Windows Phone 7 instead of from Windows 8. This means that the XAML is still managed and not native, but it's completely aligned with the previous one so that, for example, features like behaviors, for which support has been added only in Windows 8.1, are still available). This way, you’ll be able to reuse all the XAML written for Windows Phone 7 applications without having to change it or fix it.

Thanks to a feature called quirks mode, applications written for Windows Phone 7 are able to run on Windows Phone 8 devices without having to apply any change in most cases. This mode is able to translate Windows Phone 7 API calls to the related Windows Runtime ones.

The Windows Phone Runtime includes a layer called .NET for Windows Phone, which is the subset of APIs that were available in Windows Phone 7. Thanks to this layer, you’ll be able to use the old APIs in a Windows Phone 8 application, even if they’ve been replaced by new APIs in the Windows Runtime. This way, you’ll be able to migrate your old applications to the new platform without having to rewrite all the code.

Like the full Windows Runtime, Windows Phone 8 has added support for C++ as a programming language, while the WinJS layer, which is a library that allows developers to create Windows Store apps using HTML and JavaScript, is missing. If you want to develop Windows Phone applications using web technologies, you’ll have to rely on the WebBrowser control (which embeds a web view in the application) and make use of features provided by frameworks like PhoneGap.

This series will cover the development using C# as a programming language and XAML as a user interface language. We won’t talk about C++ or VB.NET (the available APIs are the same, so it will be easy to reuse the knowledge acquired by reading this series). Plus, since this series is about Windows Phone 8, I will cover just the Windows Runtime APIs. In the areas where APIs are duplicated (meaning that there are both Windows Runtime and .NET for Windows Phone APIs to accomplish the same task, like storage or sensors), I will cover only the Windows Runtime ones.

The Development Tools

The official platform to develop Windows Phone applications is Visual Studio 2012, although support has also been added to the Visual Studio 2013 commercial versions. The major difference is that while Visual Studio 2012 still allows you to open and create Windows Phone 7 projects, Visual Studio 2013 can only be used to develop Windows Phone 8 applications.

There are no differences between the two versions when we talk about Windows Phone development: since the SDK is the same, you’ll get the same features in both environments, so we’ll use Visual Studio 2012 as a reference for this series.

To start, you’ll need to download the Windows Phone 8 SDK from the official developer portal. This download is suitable for both new developers and Microsoft developers who already have a commercial version of Visual Studio 2012. If you don’t already have Visual Studio installed, the setup will install the free Express version; otherwise, it will simply install the SDK and the emulator and add them to your existing Visual Studio installation.

The setup will also install Blend for Windows Phone, a tool made by Microsoft specifically for designers. It’s a XAML visual editor that makes it easier to create a user interface for a Windows Phone application. If you’re a developer, you’ll probably spend most of the time manually writing XAML in the Visual Studio editor, but it can be a valid companion when it comes to more complex things like creating animations or managing the visual states of a control.

To install the Windows Phone 8 SDK you’ll need a computer with Windows 8 Pro or Windows 8 Enterprise 64-bit. This is required since the emulator is based on Hyper-V, which is the Microsoft virtualization technology that is available only in professional versions of Windows. In addition, there’s a hardware requirement: your CPU needs to support the Second Level Address Translation (SLAT), which is a CPU feature needed for Hyper-V to properly run. If you have a newer computer, you don’t have to worry; basically all architectures from Intel i5 and further support it. Otherwise, you’ll still be able to install and the use the SDK, but you’ll need a real device for testing and debugging.

The Emulator

Testing and debugging a Windows Phone app on a device before submitting it to the Windows Phone Store is a requirement; only on a real phone will you be able to test the true performance of the application. During daily development, using the device can slow you down. This is when the emulator is useful, especially because you’ll easily be able to test different conditions (like different resolutions, the loss of connectivity, etc.).

The emulator is a virtual machine powered by Hyper-V that is able to interact with the hardware of your computer. If you have a touch monitor, you can simulate the phone touch screen; if you have a microphone, you can simulate the phone microphone, etc. In addition, the emulator comes with a set of additional tools that are helpful for testing some scenarios that would require a physical device, like using the accelerometer or the GPS sensor.

You’ll be able to launch the emulator directly from Visual Studio. There are different versions of the emulator to match the different resolutions and memory sizes available on the market.

The Developer Experience

Windows Phone applications are published on the Windows Phone Store, which is the primary way for developers to distribute their applications. However, there are two exceptions: enterprise companies and developers for testing purposes.

To start publishing applications, you’ll need a developer account, which can be purchased from the official portal. The fee is $19 per year and allows you to publish an unlimited number of paid apps and a maximum of 100 free apps. Recently, Microsoft has merged the developer experience for its two main platforms. This means that with the developer account, you’ll also be able to publish Windows Store apps for Windows 8 on the Windows Store.

The developer account is also connected to testing. In fact, by default, phones are locked and the only way to install third-party apps is through the Windows Phone Store. All developers can unlock phones for free, even if they don’t have a paid account; the difference is that with a free account, only one phone can be unlocked and only two applications can be loaded on the phone. With a paid account, developers are able to unlock up to three phones and can load up to 10 applications on each.

The app deployment can be performed directly from Visual Studio or by using a tool installed with the SDK called Application Deployment.

To unlock your phone, you’ll need another tool that comes with the SDK called Windows Phone Developer Registration. You’ll have to connect your phone to the computer and sign in with the same Microsoft account you’ve used to register the developer account.

The application to be published on the Windows Phone Store needs to be certified. The certification process (in which both automatic and manual tests are executed) makes sure that your app is acceptable from a technical (the app doesn’t crash, the user experience isn’t confusing, etc.) and content (no pornography, no excessive violence) point of view.

We’ll cover more details about the publishing process in the last article of this series.

Preview for Developers

Microsoft has introduced a new program for developers to grant early access to new Windows Phone updates. This way, developers are able to test their apps against the latest OS releases before they are distributed to users.

To subscribe to the program you have to:

own a developer unlocked phone

have a paid developer account or a free account on App Studio, the web tool created by Microsoft for easily creating Windows Phone apps without programming skills

Once you’ve met these requirements, you can download the Preview for Developers application from the Store.

After installing it, you’ll have to run it and enable the preview program by accepting the terms and conditions. Once you’ve completed the process, preview updates will be delivered like regular updates: you’ll have to go to the Updates section of the Settings page and check for new updates. At the time of writing, Microsoft is delivering GDR3 with this preview program.

Just keep in mind that depending on the manufacturer, installing a preview version can break the phone’s warranty. It’s a safe procedure, but if something goes wrong, your manufacturer may not be able to support you.

The First Project

The starting point of every Windows Phone application is Visual Studio 2012. Let’s see how to create a project and how it is structured.

The first step is to open Visual Studio 2012 and click on New project. In the available installed templates, you’ll find the Windows Phone section that contains all the templates related to Windows Phone development.

We’re going to use the simplest one, Windows Phone app, which contains only a starting page. Give it a name and click OK. You’ll be asked which platform you’re going to support. Since we’re covering Windows Phone 8 development, choose Windows Phone 8.0. The designer will automatically load the starting page and, in the Solution Explorer window, you’ll see the structure of the project. Let’s look at it in detail:

App.xaml

The App.xaml file is the starting point of every Windows Phone application: it takes care of initializing the application and the frame that will contain the pages. Plus, since an instance of the App class (which is defined in the App.xaml.cs file) is always kept alive during the application execution, it’s also used to define all the global settings. For example, you can intercept the life-cycle event we’ll cover later in this series, or you can define global XAML styles and resources that will be used across the application.

MainPage.xaml

This is the main page of the application that is launched after the app is initialized. It’s the default one included in a project, but you can add as many pages as you want in your project. Every page has the same structure: it’s composed of a file with the extension .xaml, which defines the user interface, and a file with extension .cs, which is the code behind that defines the logic for interacting with the user interface. Every page inherits from a class called PhoneApplicationPage that offers built-in support for properties and events that are connected to the page life cycle, such as navigation events, orientation, system tray management, and more.

Assets

The Assets folder contains the graphic assets of the application. The standard project includes some default icons and images for the various Tile sizes and templates.

Resources

The Resources folder contains all the files needed to manage localization. By default, you’ll find just one file called AppResources.resx, which contains the base language (usually English, but you can select another). Every other language will be supported by adding a new AppResources file. The LocalizedStrings.cs file is added by default in the project’s root, and it is the class that we will use to manage localization. We’ll cover this more deeply later in this series.

The Manifest File

Inside the Properties folder you’ll find a file called WMAppManifest.xml. This is a very important file. It is called manifest because it’s used to declare all the capabilities and features of the application. Its role is crucial during the certification process; thanks to this file, the automatic process is able to extract all the needed information about the application, like its title, supported resolutions, features that are used, etc.

Visual Studio 2012 provides a visual editor for the manifest file; simply double-click on the file to open it. It’s important to note that not all use-case scenarios are supported by the visual editor. Sometimes we’ll have to manually edit the XML to extend our application.

The editor is split into four different sections:

Application UI: Features all the information about the look of the application once it is installed on the phone, like the title, supported resolutions, template, and standard images to use as the main Tile.

Capabilities: Lists all the hardware and software features the application can use, like the camera, geolocalization services, networking, etc. In most cases, using a feature for which the specific capabilities have not been declared will lead to an exception when the application is executed. In this series I will note every time we use a feature that requires a specific capability.

Requirements: Lists specific hardware features that can be used by your app, like the camera or NFC. If you set requirements, people that own phones without these specific hardware features won’t be able to download the app.

Packaging: Defines the features of the package that will be published in the store, like the author, publisher, default language, and supported languages.

The Splash Screen

If you’ve already developed apps for Windows Phone 7, you should be familiar with the splash screen. It’s a static image that is immediately displayed when the app is opened and disappears when the app is fully loaded and ready to be used.

The splash screen was part of the standard Visual Studio template for Windows Phone 7 projects, but it has been removed in Windows Phone 8 projects. Due to the performance improvements introduced in the Windows Runtime, apps now start much faster, so typically a splash screen is not needed.

If you do need a splash screen, you’ll have to manually add it to the project following a specific naming convention: it has to be in JPG format, the file name has to be SplashScreenImage.jpg, and the required resolution is 768 × 1280. This way, the image will be automatically adapted to the resolution of the device. If you want full control over the device’s resolution, you can add three different images, one for each supported resolution. In this case, the naming convention to follow is:

SplashScreenImage.screen-WVGA.jpg for 480 × 800 devices.

SplashScreenImage.screen-WXGA.jpg for 768 × 1280 devices.

SplashScreenImage.screen-720p.jpg for 720 × 1280 devices.

The 1080p resolution, from an aspect ratio point of view, behaves like 720p: if your application is launched on a 1080p device, the 720p splash screen will be used if one exists.

Testing the Application

When you’re ready to test your application, you can deploy it on a device or in the emulator directly from Visual Studio. In the toolbar area you will find what looks like a play button, together with a description of a deployment target. You can choose between five different targets: a real device, two versions of the WVGA emulator (one with 512 MB of RAM and one with 1 GB of RAM), a WXGA emulator, and a 720p emulator. From time to time, the list may be longer because Microsoft periodically releases SDK updates to add new emulators that match the new release of the operating system. For example, Microsoft has already released an SDK update that adds the emulator images aligned with the GDR2 release.

When the application is running in debug mode, two features are automatically enabled to help you work:

The right side of the screen displays performance counters like the number of frames per second or the memory usage. They will help you identify potential performance issues with your app (see image below for more detailed information).

The phone or emulator will never be suspended—the “auto lock” feature that turns the screen off after not being used is usually enabled on devices, but in debug mode, this feature is disabled.

A Quick Recap

In this first article we’ve started to get comfortable with some important concepts that every Windows Phone developer should be familiar with:

We’ve learned the main software and hardware features of the platform that developers can take advantage of.

We discussed the Windows Runtime that is the core of the newest Microsoft technologies, like Windows 8 and Windows Phone 8.

We’ve seen how to start working with Windows Phone: which tools to download and install, how to create the first project, and the structure of a Windows Phone application.