In-Depth

Top 10 Tips for Building a Windows Phone App

There's a right way and a wrong way to build Windows Phone applications. These 10 tips can help you do it the right way.

• By Max Zilberman
• 02/03/2012

We all love devices. As a matter of fact, one of the first things people do with a PC, phone or tablet is customize it. We change backgrounds, install apps, change the ringtone; all to make it "personally mine." Over the last year, as the application ecosystem has grown, so has the number of applications available. Although the development tools for the Windows Phone platform are the best in the industry for building mobile applications, the quality range of applications developed for Windows Phone is similar to other platforms. In this article, I'll explore some development "gotchas" and see why some apps (apart from content) achieve greater customer response than others. Some issues are code-related, while others are design-based.

Rule No. 1: Embrace Metro
For most smartphones -- excluding Windows Phone -- the reality is that beyond some style magic, they are, in general, the same. Each has chrome, status indicators, pagination, app icons and the like. This commonality sometimes leads to the question, "What should my application look like?" What's a seemingly simple decision for some is extremely hard for others. Some publishers assume that all users across all platforms want, or need, the app to look the same. This is understandable, but an incorrect assumption in most cases.

As Microsoft designed Windows Phone, it took a different approach from other smartphones. The idea of a mobile app with the look, feel and functionality of an iPhone app being used on Windows Phone feels unnatural. In the same way, a Windows Phone application would look completely out of place on an iPhone. This leads to our first rule of Windows Phone development: Embrace, rather than fight, the Metro-style interface. Your app will feel natural to any consumer who uses Windows Phone.

Rule No. 2: Leave Some Space
Unlike other phone platforms, Windows Phone application design gives full edge-to-edge control over the design layout. This approach allows the designer to feel in complete command. The chrome and typical dressings like the Back button, chevrons (>) on lists as well as item separator lines are all elements that fill the screen without enhancing overall usability.

That's why the lack of these items in Windows Phone isn't an oversight; instead, it's an effort to condition users to expect that almost every piece of information in a list is actionable. This is true for all core apps that ship as part of the OS: For the Settings, Outlook or People Hubs, it should be clear that detail views are available for every item represented.

It takes as little as 24 pixels between list items for the user to differentiate them; thus, there's no need for lines (see Figure 1). Additional tricks can be done using different font size or colors; but nothing more than open space between items is pretty powerful.

[Click on image for larger view.]

Figure 1. These items are strongly differentiated, although there are no separation lines between items.

Rule No. 3: Respect Margins
Applications aren't static: they evolve over time. They're born out of ideas on a napkin or a conversation you had with a friend. Then they go through stages of prototyping, design mockups, developer prototyping and, finally, a formal design.

In very few cases does this mean that different people are doing the work, especially in smaller companies. Sometimes you're the owner, developer, designer -- even the janitor -- doing everything yourself.

Because of these factors, the pressure and irresistible desire to ship sometimes gets in the way of producing what would've been a perfect application. What keeps it from being perfect? Often, it's the seemingly tiny details; but they can turn out to be not so tiny in the competitive market of mobile apps. That applies to the subject of our third rule: Getting stuff to line up properly.

This simple rule -- proper margins -- is for some reason lost when trying to get controls on the screen. If there was only one thing I could impress upon developers, it would be this: one margin for all content works best; make it 24 pixels from the left.

Rule No. 4: Get Controls out of the Way
Controls within the Windows Phone developer toolbox allow you to build infinite combinations of visual styles and artistic designs. The ability of one of those tools, Silverlight, to style controls provides a lot of power. But this flexibility brings with it some potential challenges.

Consider an example of using a panorama or a pivot page with a Map Control. These two controls on the page don't represent an issue. However, when you place Map Control inside the PanoramaItem, the map will directly interfere with the "swipe" gesture of the Panorama Control, because this gesture is applicable to both controls. This can be seen in Figure 2.

[Click on image for larger view.]

Figure 2. The end result when two controls interfere. It isn't pretty.

Similar issues exist with other controls when a wide range of gestures is supported. As a general rule, don't nest controls that require side-to-side gestures. Bottom line: Make it obvious to the user how to use the app.

Rule No. 5: Make Navigation Predictable
An application is a street; your experience back and forth through the functionality is the path. Just as we do with our navigational landmarks in our daily life, application navigation is something that should stay the same.

The Windows Phone Home button will get many developers in trouble. A Home button inside an app is needed on phones that lack a dedicated Back button; an iPhone is a good example. All Windows Phone devices instead have a dedicated hardware button, removing the need to have an embedded Home button. This is a place where design religion comes in: Because iPhone, Android and Symbian apps all have embedded Home buttons, the belief is that a Windows Phone app needs one, too.

Unlike some other platforms, Windows Phone apps maintain a page stack in the navigation model. This model fits the normal user expectation for a Back button: it returns to the previous view. In this environment, a Home button would cause an unpredictable navigation pattern. If the user navigates deep into the interface and at some point presses Home, then continues navigating throughout the app, the number of navigation frames will continue to grow; then the Back button will have to unwind the entire path. In a Windows Phone application with no Home button, navigation is clear and simple: the Back button will always return the user back to the previous page.

In the Windows Phone 7.1 SDK, a new API was added that allows developers to access and modify the Page stack prior to returning to the previous page. This has given a large amount of new flexibility to developers.

The change was made to support a number of non-linear navigation scenarios such as Shopping Carts and payment and service subscriptions. These non-linear scenarios require a Wizard to be completed by the user, but the Back button should not unwind the navigation stack through seven steps of the checkout Wizard. In this case the developer would use the new API to modify the stack and return the user to the shopping experience once a confirmation page is shown, for example.

Although this flexibility in the API is now available, developers still should ensure that the overall experience of the application is highly predictable. That means the user should always know what happens when he clicks the Back button.

Rule No. 6: Learn How to Pin Tiles
One of the features most embraced by developers has been support for multiple tiles. The ability to pin single or multiple tiles to the home screen is very similar to a bookmark in a book. When pinned, the tile is added to the home screen, and when pressed, the tile should take the user directly to the content or feature.

There have been numerous debates on how this feature should be used. Should it be a link to a specific place in an app, while retaining the full app experience? Or should it limit the app to a smaller set of features, like a mini-app? A number of articles have been written, but questions of the original intent continue to surface on forums and at various events.

The concept of a pinned tile, shown in Figure 3, was as a deep bookmark that exposes a subset of features within the application. For example, weather of a single city, or a category of news, or a single contact card; similar to the way it's done in the Person Hub.

[Click on image for larger view.]

Figure 3. Pinning tiles.

Stated another way: a pinned tile should be a shortcut to information typically located deep in the app -- not a bookmark that continues to provide access to the entire application.

Rule No. 7: Limit Results on Map Control to What the User Can See on the Viewport
As with Textbox and List, the Windows Phone SDK 7.1 includes Map Control. This is integrated with Bing mapping. This versatile control supports a number of features that allow developers to create great experiences with native Bing mapping.

The most common issue developers run into is trying to map the world in the control. Map Control has good performance, but you can never forget that you're running the application on a phone. There are a few rules to remember when using the control.

First, developers should check whether the point is in the map's visible area; in other words, in the viewport. A trivial method for checking would look something like this:

 protected bool CheckPinInViewport(double width, double height, Point coords)
{
  if (coords.X > 0 && coords.Y > 0)
  {
    return coords.Y < height && coords.X < width;
  }
  return false;
}

There's no point in showing anything outside of viewport. The code example applies to pins, but the problem is wider, as Map Control supports more types of elements such as tiles, layers, shapes and controls. Each adds complexity when the map view is moved or repositioned, adding calculations that affect the CPU.

The second issue is a little more complex: What if a large set of results is returned; condos in Manhattan, for example? The results even at a relatively low map resolution could produce a high number of pins. In this case you need to figure out how to cluster results together; at a very high number of results, separate overlapping pins are of little use to the user. In the end, this causes frustration and dissatisfaction.

Once a point is reached where the amount of data is more than both the user and phone can handle, there are a few options to consider. The data can be filtered, or the results of adjacent pins can be clustered.

Here's an example of clustering in a real-world scenario. Your app is showing a real estate listing, and there are 50 results at the same address (with different unit numbers). A traditional view of the results would have all 50 pins stacked on top of one another. In a clustered view, those pins can be represented by a single pin. In the same manner, you can take it a level higher and represent an entire block or a section of blocks by a single result, if the density of the pins at that location is higher.

Mapping is generally an immersive experience; everyone expects to be wowed by your custom template pins. Touch input should activate your pin with sufficient detail to allow the user to interact with the data without getting frustrated.

Rule No. 8: Tombstoning Should Be Transparent
This is all about how your application responds to the phone's signal that it needs more memory. Let's start with a description of the way the phone allocates memory and manages application state. In the Mango update of the OS, applications not in view aren't evicted from memory; they're literally paused and allowed to stay resident in memory.

The rest of memory management follows the pre-Mango rules: applications requesting memory are granted the request if sufficient memory is available.

Nothing actually happens unless the active application is exerting more pressure on the currently available memory pool. If the active app needs more memory, the OS evicts the app in the least-recently used (LRU) order. As shown in Figure 4, the foreground application -- being the most recently launched -- could evict an application not in the view, based on the LRU rule.

[Click on image for larger view.]

Figure 4. How tombstoning works in Windows Phone Mango.

In the tombstoning process, the OS Memory Manager signals the application; that application is given a finite amount of time to shut down (it's forcefully killed if time runs out). Note that there's a great variance between what developers think should happen versus what actually happens when the application's reactivated.