Chapter 1. A new phone, a new operating system

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Chapter 1. A new phone, a new operating system

This chapter covers

Introducing Windows Phone 8
Understanding the hardware platform
Porting applications from other mobile operating systems
Developing for Windows Phone

Windows Phone 8 is more than a new operating system. It’s an operating system, powerful hardware platform, and collection of web services combined into one great experience for the busy individual, as shown in figure 1.1. Phone consumers demand the most from their phones as they balance work and life and use their phones to manage their busy lifestyles. Windows Phone 8 was designed to let users tailor the phone experience to their individual needs so that they can get tasks done faster and get back to the important aspects of their lives.

Figure 1.1. A variety of screen shots from Windows Phone 8: Starting with the Start Screen at bottom center and moving clockwise, you can see the Application List, Office Hub, People Hub, Email application, and Lock Screen.

The Windows Phone 8 operating system is Microsoft’s latest entry into the fiercely competitive mobile market. Windows Phone 8 is both an upgrade of the Windows Phone 7 operating system and a slimmed-down version of Windows 8, Microsoft’s latest desktop and tablet operating system. With the release of Windows Phone 7 in October 2010, Microsoft re-imagined what a mobile operating system should be and completely changed the rules on how to build mobile applications. With the release of Windows 8, Microsoft has redefined how to build and market applications for touch-enabled desktop, laptop, and tablet computers. By bringing together Windows Phone 7 and Windows 8 into a single phone platform, Microsoft is ensuring a consistent foundation for touch-enabled application development, regardless of form factor.

In this chapter we present the motivation behind this revolution in the Microsoft OS for mobile devices. We detail how Windows Phone 8 differs from other mobile operating systems so that you can assess the capabilities of the new platform and understand how existing designs and code can be ported. We describe the various hardware specifications common to the different Windows Phone 8 devices so that developers can confidently target equipment that will always be available. And we introduce the developer tools that you’ll use throughout the book to build applications targeted at the Windows Phone.

1.1. Rebooting the Windows Phone platform

Microsoft has been building operating systems for mobile devices and phones for more than a decade. One of the earliest versions was Pocket PC 2000, running on palm-sized devices such as the Hewlett-Packard Jornada and the Compaq iPAQ. These early devices weren’t smartphones but were portable computers or PDAs targeted for business users and didn’t initially include phone hardware or network connectivity. Users interacted with these devices using a stylus on a single-point touch screen and an awkward hardware input panel. Pocket PC 2000 was initially built on Windows CE 3.0 and later added the first version of the .NET Compact Framework. Device manufacturers often created custom builds of the operating system tightly coupled to specific hardware on a single device—making operating system upgrades impossible for most users.

Until Windows Phone 8, the most recent versions of Microsoft’s operating system for mobile devices were Windows Mobile 6, Windows Phone 6.5, and Windows Phone 7.x. Windows Mobile 6 was built on Windows CE 5 and includes the .NET Compact Framework 2.0 SP1. Windows Mobile 6 came in three editions: Standard, Professional, and Classic. Windows Phone 7.x was built on Windows CE, the .NET Compact Framework, and Silverlight. Prior to Windows Phone 8, there were two releases of Windows Phone 7: 7.0 and 7.1/7.5. A third release of Windows Phone 7, version 7.8, was released shortly after the release of Windows Phone 8 and includes a few Windows Phone 8 features back-ported to the older operating system.

Note

For the remainder of the book, when we use the term Windows Phone without a version number, we’re referring to Windows Phone 8. We’ll use Windows Mobile, Windows Phone 6.5, or Windows Phone 7.x to refer to older versions of the phone operating system.

Mobile phones have evolved rapidly and incredibly in the past several years. Once intended solely for business users, mobile phones are now predominately consumer devices and in many cases have replaced land-line services to become the user’s only phone. Smartphones now include music players, cameras, global positioning systems, compasses, and accelerometers. Single-point touch screens that required a stylus have been replaced with multipoint touch screens that work with your fingertips. Awkward hardware input panels have been replaced with software input panels and optional hardware keypads (although at the time of this writing, none of the available Windows Phone 8 devices includes a hardware keypad).

Apple led the smartphone revolution with the release of the iPhone in June 2007 and the introduction of the App Store in July 2008. Google followed with the introduction of the Android OS and Android Market, since renamed Google Play, in October 2008. Since then, Microsoft has seen declines in Windows-powered device market share as consumers and manufacturers turned to smartphones running new mobile operating systems.

But phone hardware and mobile operating systems aren’t all that have changed in the last decade. It’s now an online world where users are in nearly constant contact with friends, coworkers, family, high school buddies they haven’t seen in 20 years, and random followers they’ve never met. Applications that once worked only with local copies of documents and data are now interacting with services running in the cloud. And with all this online presence and exposure, security has become extremely important. It’s no longer acceptable to give software full access to hardware or to data stored in the file system.

Application development platforms and paradigms have changed as well. With the rise of web applications, a whole new style of application development came into power. Rich interactive applications are the norm, complete with animations, dynamic transitions, and cool graphics. User interfaces are no longer built by developers but are created by designers who use a whole different set of tools.

Microsoft set out to build a new Windows Phone operating system designed to meet the demands of the altered smartphone market. The company realized it would need a new operating system, backed by a reliable hardware platform, to compete with Apple and Android.

1.2. Windows Phone foundations

Every application developer must understand the hardware and software platforms on which their code will run. This is true whether you’re building desktop applications, web services, or mobile applications. When building Windows Phone applications, you should understand the hardware specifications and know how much memory you can expect to be installed as well as the supported screen resolutions. Windows Phone provides a unique look and feel that developers should respect when designing user interfaces. You should also know how to use or extend the features of built-in applications and services. In this section we talk about the Windows Phone hardware specifications, user interface look and feel, native applications, and the platform APIs you’ll use to build your own applications.

1.2.1. Hardware specs

With the redesign of the operating system, Microsoft has taken the opportunity to define clear hardware specifications for Windows Phone 8 devices. All devices must meet the minimum hardware requirements.

Windows Phone 8 devices come in one of three screen resolutions: 800 * 480 (WVGA), 1280 * 768 (WXGA), and 1280 * 720 (720p). For the most part, you don’t have to worry about the different screen resolutions because XAML applications are automatically scaled to fit the screen. WXGA screens are scaled by a factor of 1.5, and 720p screens are scaled by a factor of 1.6. A common scaled resolution allows the same user interface to be reused across different Windows Phone devices. But you do need to know that even at the scaled resolution, a 720p screen is slightly taller than the WVGA/WXGA screens, as shown in figure 1.2.

Figure 1.2. The three screen resolutions of Windows Phone 8: 800 * 480 (WVGA) on the left, 1280 * 768 (WXGA) in the center, and 1280 * 720 (720p) on the right. All three images are running the sample application you’ll build in chapter 5. Notice how the 720p image has extra space at the bottom of the screen due to the different scale factor.

All Windows Phone devices provide the user with at least a four-point multitouch experience. The operating system provides a software-based input panel (SIP) to enable text input for devices without a physical keyboard. Phone manufacturers can add additional user input mechanisms, such as a landscape or portrait physical keyboard, but extra hardware can’t add extra features to standard typing. The touch screen is capacitive to give the best experience possible on a mobile device.

Windows Phone devices come with an accelerometer, a proximity sensor, a light sensor, an optional compass, and an optional gyrometer. Developers access the raw data from each sensor or use wrapper APIs such as Motion, Inclinometer, or OrientationSensor, which wrap up multiple sensors into a simple-to-use interface. The operating system detects when a device has been rotated from portrait to landscape orientation. The sensors can also be used as an input mechanism for controlling an application or game. The sensors are covered in more detail in chapters 10 and 16.

The Windows Phone hardware specifications also include the following:

GPS receiver to enable location-aware applications
Rear-facing camera having a minimal resolution of 5 megapixels
Optional low-resolution, front-facing camera
GPU supporting DirectX 9 acceleration
Dual-core Snapdragon S4 processor
Minimum of 512 MB of RAM and 4 GB of Flash storage
Optional expandable memory in the form of a microSD slot

The Windows Phone hardware specifications require certain hardware buttons to be present. Many of these keys aren’t exposed to developers, and applications can’t detect when they’re pressed (you’ll learn how to access the camera button in chapter 8). The physical buttons that are mandatory for all Windows Phone devices are the following:

Volume Up
Volume Down
Back
Start
Search
Camera
Power On/Off

Minimum hardware specifications have simplified the task of developing a Windows Phone application. These common hardware specifications have allowed Microsoft to create several different emulator images that cover most of the possible user interactions with the device so that you can test most experiences in your emulator.

Microsoft defined clear hardware specifications to ensure that users and developers have the same experience on every device. Microsoft also designed a new user interface to provide a clean look and feel.

1.2.2. A new user interface

Windows Phone has completely redesigned the user interface, moving from an icon-centric style to the new graphical interface previously developed for the Zune HD media player. Microsoft designers spent some time looking for a proper way to present content and realized an intuitive style already existed. Signage and typography in railway and metro stations, shown in figure 1.3, are concise ways to present information to people coming from different cultures. Why not port this concept to Windows Phone?

Figure 1.3. Common signs in railways and airports. On the left are icons integrated with text, whereas on the right only icons are used.

The second pillar of the user interface is full-touch support. The success of devices implementing a full-touch user interface is due to the immediacy provided by this natural way of interacting with applications. Concise indications and full-touch support play an important role in developing applications because you must align with these concepts when you design your user interface.

One well-known defect of the applications written for Windows Mobile was the lack of a common user experience. We’ve seen applications aligned with the template generated by Visual Studio but implemented with a user interface built to match the iPhone user experience. This is confusing to the user, and you should make every effort to match your creations to the Microsoft design language adopted by the native Windows Phone applications.

Last but not least, when developing your application you want to target as many users or customers as possible. Globalizing an application means making it right not only in terms of functionality but also in terms of its contents. We strongly recommend avoiding expressions or icons that don’t have a global meaning. Also remember that your application will be inspected by Microsoft prior to publishing it to the Store. Store guidelines specify what content can and can’t be presented through a Windows Phone application. You can find the Windows Phone Store guidelines at http://mng.bz/Fefo.

1.2.3. User experience

Understanding the user experience of the Windows Phone is important for building an application that feels like it belongs on the phone. The built-in applications, called hubs, establish the look and feel of the device and provide integration and extensibility points for third-party applications.

Note

All the standard applications and hubs that ship on a real Windows Phone are available in the Windows Phone emulators that are installed with the developer tools.

The hubs are built with two new UI controls named Panorama and Pivot. You can read more about using the XAML versions of Panorama and Pivot in chapter 14.

Start Screen

The Start Screen is the home screen for Windows Phone. It’s the screen displayed when the phone is started. When the user presses the Windows button, they’re brought back to the Start Screen. A user can pin their favorite applications, games, and contacts to the Start Screen so they can launch them quickly.

The images displayed on the Start Screen (shown in figure 1.4) are called tiles. Tiles can be dynamic, displaying information relevant to an application. The tile for the Weather Channel application updates with the latest weather conditions. Other tiles are badged when notifications are ready to be viewed. The tiles for Email display a count of new mail messages. Tile images, text, and format are provided by the developer.

Figure 1.4. The Start Screen from the emulator containing several tiles of various formats and sizes

Applications can pin multiple tiles to the Start Screen, each launching to a different spot within the application. Tiles can be updated from code running on the phone or remotely using the Microsoft Push Notification Service. Tiles are displayed in one of three formats: Flip, Iconic, or Cycle. Each of the tile formats can be one-quarter size, normal size, or double-wide size.

Flip tiles display a title, a count, and a background image on the front of the tile. The count is shown as a small badge in the upper-right corner. The back displays a message, as well as a title and image, but doesn’t display the count. The operating system periodically animates the tile by flipping from front to back, then back to front, showing the user both sides of the tile. If the application hasn’t assigned any properties for the back of the tile, the tile is never flipped over. The small version of the tile doesn’t display a title and doesn’t flip. You can see the different-sized Flip tiles in figure 1.5. If a Flip tile doesn’t specify a background image, the background of the tile is filled with the accent color from the system-wide theme chosen by the user.

Figure 1.5. The three different sizes of a Flip tile. At the top of the image is the small-sized Flip tile showing only the background image and count badge. The front and back of both the normal-sized and double-wide-sized tiles are also shown—displaying the tile title, background image, count badge, and back-of-tile message.

Iconic tiles have only a single side, which displays a title, icon, and count. Small and normal-sized tiles display the icon on the left side, with the count occupying the right side, as shown in figure 1.6. Small versions of the tile don’t display the title. The icon and count are shown in the lower-right corner of double-wide tiles. Double-wide iconic tiles also display a message. The message shown on the large tile is specified in three parts, comprising a header and two rows of text. Iconic tiles can specify the background fill color, and if a color isn’t specified, the accent color from the system-wide theme is used.

Figure 1.6. Three different sizes of an iconic tile. Both the small and normal-sized tiles display the icon and the count centered in the tile. The double-wide tile moves the icon and count to the corner to make room for three rows of text.

Cycle tiles cycle through a number of different background images. Up to nine different images can be specified. The current image runs in a panning animation that slowly moves the image from the bottom of the tile to the top. The transition between images, shown in figure 1.7, is also animated, quickly scrolling the next image into view. Cycle tiles display both a title and a count, with the count shown as a badge in the upper-right corner of the tile. The small Cycle tile doesn’t cycle but rather shows a static image. The small tile also doesn’t display a title.

Figure 1.7. A Cycle tile caught in transition from one image to another

Tiles are designed for WXGA resolution and are scaled by the operating system for WVGA and 720p displays. Tile sizes are 159 * 159 for one-quarter-sized tiles, 336 * 336 for normal tiles, and 691 * 336 for double-wide tiles.

Application List

The Application List (figure 1.8) is where all native and third-party applications appear. It doesn’t matter whether the application is built using XAML or Direct3D, or if it’s a native application built by Microsoft, a device vendor, or a mobile carrier. The developer determines the application title and icon that are shown in the Application List.

Figure 1.8. The Application List showing the tap-and-hold menu through which the user can uninstall an application or pin it to the Start Screen

Unlike Start Screen tiles, Application List images are static and don’t animate or display counts. The image is determined at compile time and can’t be dynamically updated by the application. Application list icons are 100 * 100 pixels. The system theme accent color will show through any transparent pixels in the application’s icon. The user can pin an application to the Start Screen or uninstall it from the context menu shown when the user taps and holds the application’s tile or icon.

Games Hub

If your project is declared to be a game, it’ll be listed in the Games Hub instead of the Application List. The Games Hub is divided into three areas:

The Collection view lists the games installed on the device.
The Spotlight view displays news from Xbox Live.
The Xbox view provides access to the user’s Xbox gamer profile and Xbox Friends.

The game developer declares the title and icons displayed in the Collection view in the same manner that Application List images and titles are declared.

Music + Videos Hub

The Music + Videos Hub is the central place where you can find all music, video, and podcast activity on the device. The Music + Videos Hub is divided into five areas, as shown in figure 1.9:

The Collection view is the central point for playing music, videos, and podcasts, as well as a link to the Windows Phone and Xbox Music Stores.
The History view contains the list of music, videos, playlists, artists, and podcasts that you recently played. This includes media played by third-party applications that integrate with the Hub.
The New view contains the list of new music, videos, or podcasts that you synced to the phone or downloaded from the Windows Phone or Xbox Music Stores. Third-party applications can add items to the New view.
The Apps view contains the list of Music + Videos Hub applications that are installed on the device. Third-party media applications are listed here.
The Xbox view displays artists and other content offered by the Xbox Music Store.

Figure 1.9. The Music + Videos Hub showing the Collection, History, New, Apps, and Xbox views

The Music + Videos Hub provides a few integration points to third-party applications. You can read more about the Music + Videos Hub in chapter 9.

Photos Hub

The Photos Hub, shown in figure 1.10, is where you can see all of your photos from different sources. All photos you take with the phone, sync from the computer, download from the internet, or open in email are included in the Photos Hub. The Photos Hub is integrated with Outlook.com and Facebook, and all photos you upload to those websites are displayed in the Photos Hub as well. It also shows the latest photos of your friends on Facebook.

Figure 1.10. The Photos Hub showing the Collections, Favorites, What’s New, and Apps views

The Photos Hub can be extended by third-party applications that implement photo editing or sharing features. Extending the Photos Hub is described in chapter 9.

People Hub

The People Hub is the contacts application for Windows Phone. Here’s where you find your contacts, along with their phone numbers and addresses. The People Hub also displays the latest status and activity obtained from Outlook.com, Facebook, Twitter, and other social networks. Third-party applications can read data directly from the contacts database and can read and write contacts data with launchers and choosers, which are introduced in the next section. Third-party applications can also create their own contact stores that are integrated into the People Hub. You’ll learn more about working with built-in and custom contact stores in chapter 6.

Understanding Windows Phone’s hubs and how they can be extended is key for building applications that enhance user productivity and that are integrated with the operating system. Third-party integrated applications and extensions are built on top of the features exposed in the platform APIs and frameworks.

1.2.4. Platform APIs and frameworks

At its core the Windows Phone 8 operating system is Windows 8—not the full-blown Windows 8 you run on your desktop, but pieces of the Windows 8 kernel and the Windows Runtime designed to run on mobile devices and tablets equipped with ARM processors. Because of this shared lineage, Windows Phone 8 includes a subset of the Windows Runtime, Win32, and .NET APIs found in Windows 8.

In addition to being built on top of the Windows 8 kernel, Windows Phone 8 inherits the features and APIs introduced in Windows Phone 7. This hybridization of Windows 8 and Windows Phone 7 means that in some places two different APIs exist for the same set of features. One example is the Isolated Storage APIs from Windows Phone 7 and the Local Storage APIs from the Windows Runtime. Other examples include the Networking and Sockets API and the APIs for the accelerometer, gyroscope, and other sensors. Throughout the book we try to indicate where we use APIs that have alternate implementations.

Like Windows Store applications on Windows 8, Windows Phone applications run in a sandbox and can’t communicate with other processes or read from the file system. These security measures limit the ability to integrate with native applications and databases. To ease these limitations, native applications also expose various integration points. These integration points come in the form of launchers, choosers, and extensions. The platform also provides access to network APIs so that applications can use web services external to the device. Finally, facilities such as location and notification services are available to third-party developers.

Launchers

Launchers allow your code to activate a native or built-in application. Data can be passed to the launched application. When the native application is launched, your application is deactivated. Launchers are provided to activate the phone dialer, media player, web browser, and other native applications. Launchers are the only way to initiate a phone call or send an SMS message; see figure 1.11. Launchers are covered in depth in chapter 5.

Figure 1.11. The sample application you’ll build in chapter 5 uses a launcher to send an SMS text message.

Choosers

Choosers return data to an application. Choosers are provided to retrieve email addresses, phone numbers, physical addresses, and photographs. Choosers also launch a native application, resulting in the deactivation and/or termination of your application. Choosers are also covered in chapter 5.

Extensions

Extensions allow an application to integrate their features seamlessly into a native application. For example, the Photos Hub allows photo-editing applications to be launched from its Apps list and from the Share and Apps menus, as shown in figure 1.12. The Music + Videos Hub allows applications to appear in its Apps list.

Figure 1.12. The Photo Editor application you’ll build in chapter 9 extends the Photos Hub.

Associations

Associations allow one application to open another application, even if the second application is built and distributed by another third party. Associations come in two forms: file associations and URI associations. File associations are used so that your application is opened when the user opens a file with an extension you’ve registered with the operating system. The file might have come from an email attachment, been downloaded from the internet, or located on an external SD card. URI associations allow your application to launch, or be launched by, another application using a registered URI protocol. You’ll learn more about URI associations in chapter 11.

Networking

Windows Phone provides HTTP and sockets network communication. HTTP communication is implemented in the WebClient, HttpWebRequest, and HttpWebResponse classes found in the System.Net namespace. TCP and UDP communications are implemented with the Socket class in the System.Net.Sockets namespace in the .NET API or with the StreamSocket and DataGramSocket classes in the Windows.Networking .Sockets namespace in the Windows Phone Runtime API.

Notifications

The Microsoft Push Notification Service provides an API where a phone user can subscribe to a set of custom events. The notification events are defined by third-party applications and must be sent from a dedicated web service implemented by the application developer. Notifications are displayed to the phone user either on the application’s tile in the Start Screen, at the top of the screen as a toast notification (figure 1.13), or within the running application.

Figure 1.13. A toast notification appears at the top of the screen and displays a title and a message.

A toast notification is made up of a title and short message. The user can dismiss the notification by flicking to the right. The user can tap the toast to launch the application. The application developer can define a custom launch URI as part of the toast. We show how to build a notification application in chapter 11.

Location

The Location service uses data from the wireless and cellular networks and GPS to allow you to create location-aware applications. Calls to the location cloud service are abstracted behind the Geolocator class in the Windows.Devices.Geolocation namespace found in the Windows Phone Runtime API. In chapter 16 we show how to use Geolocator in an application that uses location and maps.

Custom web services

Beyond providing access to business application data or social networks, custom web services can be used to overcome some of the limitations of phones. If you have a suite of applications that share data, you can use a web service to share the data among them.

1.2.5. The Dev Center and the Windows Phone Store

The Dev Center is the portal where Windows Phone developers can find the tools and resources for building and selling applications and games. The Dev Center is where you can download the developer tools. You can also find sample code, tutorials, and documentation. If you need advice on a tricky problem, you can submit a question to the developer forums in the Dev Center. The Dev Center is located at http://developer.windowsphone.com.

Before you can deploy and debug your application on a real phone or publish your application to the Windows Phone Store, you must purchase a $99 yearly subscription to the Dev Center. Depending on what you’re building, you may consider waiting to purchase a Dev Center subscription until your application is nearly complete, using the emulator to build and test your application. MSDN subscribers receive a Dev Center subscription as part of their MSDN subscription.

Tip

College students receive free Dev Center subscriptions through the DreamSpark program. DreamSpark is a Microsoft program providing students with free copies of retail development tools and servers. You can learn more about DreamSpark at http://dreamspark.com.

Once the application has been developed, it must go through an approval process run by Microsoft before it can be published to the Windows Phone Store. This ensures that the application conforms to Microsoft requirements for a Windows Phone application. Microsoft’s requirements are detailed in the document App Certification Requirements for Windows Phone available from the Dev Center and MSDN at http://mng.bz/Fefo. More details about the Dev Center and submitting an application to the Windows Phone Store are provided in chapter 18.

1.3. Comparing Windows Phone to other mobile platforms

This book is written primarily for developers who have some experience working with C# and XAML. We focus on the features and APIs that have been introduced specifically for the phone or have been modified to fit the phone’s unique characteristics.

If you already use WPF, Silverlight, or XAML to develop applications, you know they’ve matured rapidly over the last few years. Silverlight’s success as a lightweight application framework demonstrates how XAML is ideal to use as the application framework on the mobile device. XAML is rich in features and has been proven with browser and desktop applications. You’ll find many familiar features and tools in Windows Phone.

If you’ve used Direct3D to build games for the Windows Desktop, then Windows Phone is one more platform. Developers can easily build and port games for the new devices. Windows Phone introduces a new game development model by integrating XAML with Direct3D, which is beyond the scope of this book.

If you’re not already a XAML developer, don’t despair. The appendixes include a quick primer for XAML and an introduction to the Model-View-ViewModel (MVVM) pattern used by many XAML developers. And Manning has published several books on C# and Silverlight, which you can find in their catalogue at http://mng.bz/44nv.

Note

You can develop games for the Windows Phone 8 operating system with XNA Game Studio, but XNA Game Studio can only build Windows Phone 7.1 projects. The Windows Phone 8 operating system will run both Windows Phone 7.1 and Windows Phone 8 applications. Windows Phone 7.1–style applications and games aren’t covered in this book.

But what if you’re coming to Windows Phone from some other background? How does the Windows Phone differ from Windows Store applications on Windows 8, for example? Where do you begin when porting your iOS or Android application? In this section we get you started with Windows Phone development by identifying similarities with and differences from other application platforms.

1.3.1. Windows 8

Although Windows 8 Store applications have a great deal in common with Windows Phone 8 applications, there are also differences in the two platforms. Significant portions of the .NET and Windows Runtime APIs have been implemented for Windows Phone, enabling sharing of concepts and code across both platforms.

One area where the two platforms differ is that of building user interfaces. You can build user interfaces for Windows 8 Store applications using C# with XAML, C++ with XAML, C++ with Direct3D, or JavaScript with HTML. Windows Phone applications are limited to C# with XAML or C++ with Direct3D.

On Windows 8, XAML controls exist in Windows.UI.Xaml and related namespaces, which are new to Windows 8. On Windows Phone 8, XAML controls exist in the same System.Windows and related namespaces used by WPF and Silverlight. That being said, the names of the classes and controls that exist in Windows 8 XAML also exist in Windows Phone 8 XAML—such as Grid, TextBox, UserControl, and so on. The similarities may allow you to share code. The differences—in the XAML markup, for example—may be problematic.

Problems with sharing XAML aren’t quite as severe as you may think. The screen sizes and interaction models available to a Windows 8 Store application are significantly different from those available to a Windows Phone application. If you adhere to the UI design principles established for each platform, you should end up with different user interfaces.

1.3.2. Apple iOS

At first glance, you might think there’s little in common between developing applications for an iOS device and the Windows Phone. On the iOS platform you use Xcode and Objective-C to write native applications; on the Windows Phone you use Visual Studio and C# (or Visual Basic) to write managed applications. It’s our opinion that programming languages and frameworks are tools in a developer’s tool belt, and good developers make use of several languages and frameworks. If you look beyond the languages and development environments, many of the same fundamental concepts exist on both platforms.

Apple and Microsoft both provide free development tools, complete with device simulators. Each platform has a set of style guides that applications should adhere to, and each also requires a fee-based subscription in order to deploy an application to a device. Each platform has a certification process and application store.

Building your interface

One thing to keep in mind when porting an iOS application is the differences in the user interface guidelines. You shouldn’t build an application with an iOS look and feel for the Windows Phone. An iOS application ported to Windows Phone will have a different look and feel, user-interaction model, and workflow. Don’t use chrome and icons from iOS.

Is your application built with controls from UIKit or does it use OpenGL ES? The XAML framework offers many of the controls and widgets provided by UIKit. On the other hand, OpenGL developers will use Direct3D to build applications. You can also mix application-style widgets from XAML with Direct3D-type graphics.

You’ll build your XAML applications using Visual Studio and Blend. Your views will be built using XAML, an XML-based markup language. XAML can be coded by hand in Visual Studio’s text editor or with the visual editors in Visual Studio and Blend. The core XAML Framework along with the Windows Phone Toolkit provide most of the controls you’ll need when building an application.

If your iOS application uses Core Animation, you’ll use the animation and storyboard classes from the System.Windows.Media.Animation namespace. Learn to use Blend’s storyboard editor if you’re doing anything beyond simple animations.

XAML applications are navigation-style applications, driven by the Navigation-Service. The NavigationService is similar to the UINavigationController provided by the iOS framework and is used to move between different pages or views. The difference is that all XAML applications use the NavigationService, even the simplest one-page applications.

Interacting with native applications

Like the iOS SDK, Windows Phone provides limited access to the phone dialer, SMS text application, and email. On iOS, the phone dialer is accessed via the tel URL; on Windows Phone you use the PhoneCallTask. MFMessageComposeViewController and MFMailComposeViewController are replaced by SmsComposeTask and EmailComposeTask.

The iOS SDK provides access to the address book with several classes in the Address Book and Address Book UI frameworks. On Windows Phone, read-only access to the address book is exposed via classes in the Microsoft.Phone.UserData namespace. Developers can also interact with the contacts database via a few launchers and choosers. You can prompt the user to choose a phone number, email address, or physical address with PhoneNumberChooserTask, EmailAddressChooserTask, and AddressChooserTask. You can prompt the user to save a phone number, email address, or contact with SavePhoneNumberTask, SaveEmailAddressTask, and SaveContactTask. You can read more about launchers and choosers in chapter 5 and access to the contacts database in chapter 6.

Using the sensors

Like the iPhone, the Windows Phone has an accelerometer, compass, and camera. Some Windows Phones also have a gyroscope, compass, and/or proximity sensor. The Windows Phone APIs provide access to all these sensors. Using the Camera-CaptureTask, you can launch the camera UI and manipulate a photo taken by the user. You can take direct control of the camera by using the PhotoCamera, Photo-CaptureDevice, or WebCamera APIs. Working with the camera is covered in chapter 8.

The Windows Phone complement to UIAccelerometer is either the Microsoft.Devices.Accelerometer class or the Windows.Devices.Sensors.Accelerometer class. The Compass class is the Windows Phone equivalent to CL-Heading. Motion-detection features available by the Core Motion framework are provided by the Gyroscope and Motion classes in the .NET API or the Gyrometer, OrientationSensor, and Inclinometer classes in the Windows Phone Runtime API. We show how to use the accelerometer, compass, and gyroscope, shown in figure 1.14, in chapter 10.

Figure 1.14. In chapter 10 you’ll build applications that use the accelerometer, compass, and gyroscope.

Storing data

An iOS application can store its data in user defaults, on the file system, or in a database. The iOS SDK makes use of SQLite for local database management.

Windows Phone does provide limited access to the file system. An application can only write files to local storage and has no access to any other part of the file system. Local storage is similar to an iOS application’s Documents folder.

Another way to store data is with the IsolatedStorageSettings class. This class is similar to the NSUserDefaults class in the iOS framework. It’s intended to be used to store lightweight data objects and is ideal for storing user preferences. One difference between NSUserDefaults and IsolatedStorageSettings is that IsolatedStorageSettings isn’t global, and settings can’t be shared between different applications.

Applications can store data in a Microsoft SQL Server Compact Edition (SQL CE) database using the LINQ to SQL framework. SQL CE is a lightweight database engine designed to run on mobile devices. The database files are written to a special folder in local storage and can’t be shared with other applications. Chapter 7 demonstrates how to use each of the data storage options in your applications.

Media

The iPhone uses the iPod software to play audio and video files. The iOS SDK’s Media Player framework allows developers to access the library of music and videos and play them inside their applications. The Windows Phone uses Xbox Music for its media library, shown to users in the Music + Videos Hub. Applications can play audio and video files with the MediaPlayerLauncher class. Developers can also access the media library using the classes in the Microsoft.Xna.Framework.Media namespace. The MediaPlayer class can be used to play songs, whereas the videos are played with the VideoPlayer class.

XAML applications can use the XNA Media framework, but XAML also has its own media controls in the System .Windows.Media namespace. The MediaElement control supports audio and video playback. The MediaStreamSource class can be used to manipulate audio and video playback or implement custom media containers.

The Windows Phone equivalent to iOS’s AVAudio-Recorder class is the Microsoft.Xna.Framework.Audio .Microphone class.

Your application can integrate into the Music + Videos Hub on the phone. Your application can be listed in the hub’s Apps list, as shown in figure 1.15, and media played by your application can be shown in the hub’s History page.

Figure 1.15. In chapter 9 you’ll build VoiceRecorder, an application that integrates with the Music + Videos Hub.

You can read about working with media, the microphone, and the Music + Videos Hub in chapters 9 and 15.