Introduction

The .NET Compact Framework 1.0 and GUID.NewGuid(). . . that’s where it all began . . . or rather didn’t, as I was discouraged from really getting started at that point. The problem was that the static NewGuid method returned an empty string. Many trade-offs were made in the PocketPC operating system and the initial version of the Compact Framework in order to strike a balance between performance, footprint, and time to market. Several of the Windows API functions upon which NewGuid relied were not included in PocketPC, and the Compact Framework didn’t implement an alternative, so you just ended up with not so much as a NotImplementedException for your troubles. Just an empty string. The prescribed workaround took you on a journey into the depths of the Crypto-API, COM Interop, and P/Invoke. I just didn’t want to know that much about it. This is probably why at the time I had never met a single happy mobile developer.

The next problem faced by PocketPC developers was that there was no hardware standardization. You couldn’t count on anything being the same from one device model to the next even within the same manufacturer. Some devices had hardware-based buttons for certain actions while others did not. Writing an application that would work on any device running the PocketPC operating system was an opportunity for personal growth, to put it somewhat euphemistically. Android developers right now will know exactly what I’m talking about. An even greater challenge awaits them in that not only do they face hardware differences but they also have to cope with the fragmentation of the Android operating system. No thank you.

My dear friend and coauthor, Lori Lalonde, relates a similar experience when developing for BlackBerry. The sheer amount of ceremonial code that needed to be written to accomplish certain seemingly simple tasks was discouraging.

With the introduction of Windows Phone 7 there dawned a new age. Manufacturers that wanted to produce Windows Phone devices were required to support a rigid design specification. Certain hardware elements were required to be present, and certain device interactions were tied to the hardware. The Back button, Windows button, and Search button were the main examples.

The Windows Phone OS as well could now provide a consistent API for interaction with the device. Many of the functions that you used to have to code yourself are now provided as native services or exposed via Launchers and Choosers. You’ll see examples of Launchers and Choosers in Chapter 6 on appointments and contacts as well as Chapter 8 on maps and navigation. Chapter 7 on the camera, photos, and media introduces you to the Background Audio Service that you can use. There’s no need for DirectX knowledge here.

This is one of the main design goals of Windows Phone. Providing these services through a common operating system–provided API enables developers to focus on providing greater value in their applications rather than having to reinvent the wheel. This also helps protect the user of the device. For example, as shown in Chapter 6, there is no way to flood the contact store with contacts or to even add a single contact without the user’s consent. Also, because you must interact with the built-in contact management UI, there is no way to subvert the process

Who This Book Is For

Windows Phone 8 Recipes is for the developer who has a .NET background, with familiarity in either WPF, Silverlight, or C#, and is ready to tap into a new and exciting market in mobile app development. The Windows Phone 8 SDK provides a platform that makes it easy for developers to create and publish quality Windows Phone apps in record time. The book provides the necessary information for developers to get their development environment up and running, build engaging apps that leverage the capabilities and features available in the Windows Phone 8 SDK, and walk through the steps needed to publish those apps to the Windows Phone Store.

How This Book Is Structured

This book is structured so that it does not have to be read from cover to cover. Each chapter is focused on a specific area of functionality and attempts to cover common problems you may encounter. As much as possible, each recipe has been written as a stand-alone solution to a single problem statement.

Some chapters, such as Chapter 12 on Windows Azure Mobile Services, for example, can be read in order from start to finish as the information in each recipe builds upon concepts introduced in the previous one. Having said that, each recipe can still stand on its own. Recipes that may build upon concepts that have been discussed in other recipes or even other chapters will contain references to these dependencies so that you can find them quickly.

Conventions

The style of text in the book follows the standard Apress format, so many of you will already be familiar with it. This introduction follows the same standard. For example, when code is presented inline with body text, it will LookLikeThis. This style is used to call out ClassNames, Types, variableNames, and just about any other text that would normally appear in your code. When code is presented in a block, it will be captioned, referred to in the body text by number, and have a consistent code style applied to it. See Listing 1 for an example.

Listing 1. Device Resolution Enumeration

public enum Resolution
{
    WVGA,
    WXGA,
    HD720p
}

Text that appears in bold is generally reserved for something you need to type into the interface.

Downloading the Code

The code for the examples shown in this book is available on the Apress web site, www.apress.com. A link can be found on the book’s information page on the Source Code/Downloads tab. This tab is located underneath the “Related Titles” section of the page.

The sources for this book may change over time to provide new implementations that incorporate the most up-to-date features in Windows Phone 8 or to correct errata that is identified postpublication. As we go to press, we are also working to refine some of the samples into full applications and deploy them to the Windows Phone Store. You can contact Lori or Dave via the book’s email address at [email protected] should you have trouble running any of the samples or if you want to inquire about the progress of the sample application publishing process.

Contacting the Authors

Should you have any questions or comments—or even spot a mistake you think we should know about—you can contact both Lori and Dave at [email protected].