Architecting Mobile Solutions for the Enterprise -

Architecting Mobile Solutions for the Enterprise

Dino Esposito

Copyright © 2012 by Dino Esposito All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher. ISBN: 978-0-7356-6302-2 1 2 3 4 5 6 7 8 9 LSI 7 6 5 4 3 2 Printed and bound in the United States of America. Microsoft Press books are available through booksellers and distributors worldwide. If you need support related to this book, email Microsoft Press Book Support at [email protected] Please tell us what you think of this book at Microsoft and the trademarks listed at Trademarks/EN-US.aspx are trademarks of the Microsoft group of companies. All other marks are property of their respective owners. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred. This book expresses the author’s views and opinions. The information contained in this book is provided without any express, statutory, or implied warranties. Neither the authors, Microsoft Corporation, nor its resellers, or distributors will be held liable for any damages caused or alleged to be caused either directly or indirectly by this book. Acquisitions and Developmental Editor: Russell Jones Production Editor: Kristen Borg Production Services: S4Carlisle Publishing Services Technical Reviewer: Marco Bellinaso Copyeditor: Sue McClung Indexer: Margaret Troutman Cover Design: Twist Creative • Seattle Cover Composition: Karen Montgomery Illustrator: S4Carlisle Publishing Services

To Silvia, because you’re stronger than you think. To Michela, because you’re just the daughter I always dreamt of. To Francesco, because you’re a terrific, quick learner. —Dino

Contents at a Glance Introduction xiii Part I

Going Mobile

Chapter 1

Pillars of a Mobile Strategy

Chapter 2

Mobile Sites vs. Native Applications

Part II

Mobile Sites

Chapter 3

Mobile Architecture

Chapter 4

Building Mobile Websites


Chapter 5

HTML5 and jQuery Mobile


Chapter 6

Developing Responsive Mobile Sites


Part III

Mobile Applications

Chapter 7

Patterns of Mobile Application Development


Chapter 8

Developing for iOS


Chapter 9

Developing for Android


Chapter 10

Developing for Windows Phone


Chapter 11

Developing with PhoneGap


3 25


Index 417

Contents Introduction xiii

Part I

Going Mobile

Chapter 1 Pillars of a Mobile Strategy


What Does “Going Mobile” Mean? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Toward a Mobile Strategy


Defining a Mobile Strategy


Development and Costs


Outlining a B2C Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Focus on Your Audience


Delivery Models


Outlining a B2B Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Serve Your (Limited) Audience


Mobile Enterprise Application Platforms


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 2 Mobile Sites vs. Native Applications


Not a Pointless Matter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 A False Dilemma—but True Differences


Reasons for the Perceived Dilemma


Aspects of Mobile Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 What’s Good About Mobile Sites


What’s Bad About Mobile Sites


What do you think of this book? We want to hear from you! Microsoft is interested in hearing your feedback so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit: vii

Aspects of Native Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 What’s Good About Native Applications


What’s Bad About Native Applications


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Part II

Mobile Sites

Chapter 3 Mobile Architecture


Focusing on Mobile Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Stereotypes to Refresh


Analysis First


Mobile-Specific Development Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Toward a Mobile Application Layer


Server-Side Device Detection


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Chapter 4 Building Mobile Websites


From Web to Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Application Structure


Amount of JavaScript


Application Device Profiles


Optimizing the Payload


The Offline Scenario


Development Aspects of a Mobile Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Reaching the Mobile Site


Design of the Mobile Views


Testing the Mobile Site


The Device-Detector Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Routing to Mobile Views


Detecting Device Capabilities


Putting the Site Up


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104



Chapter 5 HTML5 and jQuery Mobile


jQuery Mobile Fast Facts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Generalities of jQuery Mobile


Building Mobile Pages with jQuery Mobile


Working with Pages


HTML5 Fast Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Semantic Markup


Web Forms and Data Entry


Programmer-Friendly Features


Using HTML5 Today


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Chapter 6 Developing Responsive Mobile Sites


A Developer’s Perspective of Device Detection . . . . . . . . . . . . . . . . . . . . . 138 The Client-Side Route


The Server-Side Route


Inside WURFL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Structure of the Repository


Top 20 WURFL Capabilities


Using WURFL from ASP.NET


Implementing a Multiserving Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Key Aspects of Mobile Views


Creating Device Profiles


Device Profiles in Action


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Part III

Mobile Applications

Chapter 7 Patterns of Mobile Application Development


Mobile Applications Are Different. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Critical Aspects of Mobile Software


New Patterns and Practices




Patterns for Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 The Back-and-Save Pattern


The Guess-Don’t-Ask Pattern


The A-la-Carte-Menu Pattern


The Sink-or-Async Pattern


The Logon-and-Forget Pattern


Patterns for Presentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 The Babel-Tower Pattern


The Do-as-Romans-Do Pattern


The List-and-Scroll Pattern


Behavioral Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 The Predictive Fetch Pattern


The Memento-Mori Pattern


The As-Soon-As-Possible Pattern


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Chapter 8 Developing for iOS


Getting Ready for iOS Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 A Brand New Platform for (So Many) Developers


Choosing the Development Strategy


Programming with Objective-C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 A Quick Look at Objective-C


The HelloWorld Program


Examining a Sample Application


Other Programming Topics


Programming with MonoTouch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 The .NET Framework on iOS


Examining a Sample Application


Deploying iOS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Testing the Application


Distributing the Application


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265



Chapter 9 Developing for Android


Getting Ready for Android Development . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Development Tools and Challenges


Choosing the Development Strategy


The Android Jungle


Programming with the Android SDK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Anatomy of an Application


Defining the User Interface


Examining a Sample Application


Other Programming Topics


Testing the Application


Distributing the Application


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Chapter 10 Developing for Windows Phone


Getting Ready for Windows Phone Development. . . . . . . . . . . . . . . . . . . 324 Development Tools and Challenges


Choosing the Development Strategy


Programming with the Silverlight Framework. . . . . . . . . . . . . . . . . . . . . . . 329 Anatomy of an Application


Defining the User Interface


The MVVM Pattern


Examining a Sample Application


Other Programming Topics


Deploying Windows Phone Applications . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Testing the Application


Distributing the Application


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

Chapter 11 Developing with PhoneGap


The Myth of Cross-Platform Development . . . . . . . . . . . . . . . . . . . . . . . . . 382 The Virtual Machine Approach


The Shell Approach

386 Contents


Building an HTML5 Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 JavaScript Ad Hoc Patterns


The Sample Application


Integrating with PhoneGap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Supported Platforms


Building a PhoneGap Project


Final Considerations


Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

Index 417





s far back as 1999, some smart guys predicted that mobile would become the primary focus of development in only a few years. Although it has taken a bit more time than expected, the era of mobile software has arrived at last. Why did it take so long? The answer is surprisingly simple: mobile software needed a critical mass of users to develop before it could take off. The process of accumulating mobile users ­probably started with the release of the first iPhone back in 2007, but today, it has reached a large enough mass to trigger all sorts of chain reactions. Back in 1990 (yes, you read that right), Bill Gates gave a keynote talk at Comdex titled “Information at Your Fingertips.” Let’s be honest—for 20 years, we pretended we really had information (that we needed) at our fingertips, but at most, we had that ­information only at hand—which makes a huge difference. Now is the time, though, that we can cover the short distance from hand to fingertips. With mobile devices ­everywhere, and especially with a revolutionary version of Windows on the horizon, I believe we’re truly entering a new era of development—a paradigm shift. Paradigm shifts just happen—and mobile represents a big one. Mobile enables new business scenarios and new ways of doing the same business. Mobile affects nearly everybody—users, professionals, and clearly developers. Writing mobile applications is a challenge that the vast majority of developers will face in the near future. Overall, mobile applications are simpler than desktop or web applications—but that’s true only if you count just the number of functions. The hardest part of mobile development is to identify the right set of use-cases and the right user experience and interaction model. It turns out that the typical mobile application user is much less forgiving than the average user of web or desktop applications. As developers, we forced users to play by the rules of software for decades. In contrast, mobile developers will be forced to play by the rules of user experience and conform to user expectations. This is how software always should have been; but it’s definitely not how software has been built for at least the past 20 years. Moreover, before too many more years pass, mobile may well be the only software that we will be called upon to write. The term mobile refers to a variety of platforms, each with its own set of c­ apabilities and features, and each of which requires significantly different skills: ­different ­operating systems, different programming languages, different application ­programming ­interfaces (APIs), and even different computers. A mobile application is more ­sophisticated and more complex than web applications with regard to resource ­management, data entry, sensors, data storage, and life cycle. Furthermore, each o ­ perating system has its own set of development guidelines and a proprietary deployment model.


This book is intended as a quick-but-juicy guide to issues that you may face while developing a mobile project for one or multiple platforms. The book starts by a ­ nalyzing the various types of mobile solutions, which include websites, websites optimized for mobile devices, and native mobile applications, and then identifies a few design ­patterns common to all mobile applications and technologies available on the ­various platforms. Predictive fetch, back-and-save, and guess-don’t-ask are just a few of the patterns being discussed and implemented. The book puts considerable emphasis on mobile sites and frameworks, and on techniques to detect browser capabilities ­accurately. For example, the book offers a chapter on Wireless Universal Resource FiLe (WURFL)—the framework being used by Facebook for mobile device detection—and compares that to the detection capabilities in plain ASP.NET. Furthermore, the book offers an overview of mobile development for the three major platforms—iOS, Android, and Windows Phone. In particular, this book builds the same application for all three platforms, discussing tools, frameworks, practices, and ­illustrating architectural and structural differences along the way. Finally, the book ­covers PhoneGap and HTML5-based development for mobile devices. After reading this book, you probably won’t be a super-expert in any of those ­ latforms, but you’ll know enough to start producing code on any of the most p p ­ opular devices. You’ll also know enough to advise your customers and help them define ­effective mobile strategies for their business.

Who Should Read This Book As companies start going mobile, they need a strategy long before they need a ­mobile site or an iPhone app. But when companies have developed the strategy and start looking into implementing it, they face the rough issue of not having or fi ­ nding architects and developers that know the mobile world from a variety of angles. Today, they can easily find great iPhone or Android developers, but they can hardly find a ­consultant that can suggest, based on strong evidence, whether a mobile site is ­preferable for them. This book is aimed at providing an architect summary of what you need to know to design and implement mobile solutions. Today, a mobile solution often means ­arranging the same application for several different platforms (iPhone, Android, ­Blackberry, and Windows Phone), and doing that using a very specific set of design patterns with little in common with desktop or web apps. Last but not least, the ­effort must be done in the context of the customer’s needs, expectations, and existing ­business. xiv  Introduction

Not a Mobile Developer? Not a Developer! For a company with a consolidated business, mobile is a way to expand its horizon. The new expansion stage of mobile is reaching out to companies and enterprises and prospecting new ways of doing business. This is a paradigm shift with a deep impact that will give rise to new professional jobs, much as the web itself did more than a decade ago. That’s why I maintain that in only a couple of years, every developer will be either a mobile developer or no developer at all. Being a mobile developer surely includes ­knowing iOS, Windows Phone, HTML5, and Android, and perhaps BlackBerry, p ­ ossibly Bada, and even developing for smart TVs—and, of course, for the mobile web. More than anything else, though, developers must acquire a “mobile mindset.” You can always figure out fairly easily how to play a video on iOS, or how to make an Android device vibrate. But what isn’t as easy to acquire is the intrinsic nature of mobile applications and the patterns behind them, and which aspects to focus on for optimization. Mobile is different. Overall, it’s simpler, but it’s also much less forgiving than other types of applications. Therefore, this book is for everybody who needs to acquire some mobile ­development insight. The book’s contents won’t become obsolete in just a few months because I made a serious attempt to reach and report from the heart of the ­mobile ­experience. This book discusses technology, but it is not based on any particular ­technology; therefore, it’s an introductory text for any form of mobile development.

Who Should Not Read This Book This book won’t make you a top-notch iPhone or Android developer; it’s intended to help everybody (including those of you who are already top-notch iPhone or Android developers) understand the entire mobile world. The goal is to get readers prepared for architecting effective mobile solutions after a mobile plan has been finalized and accepted. If you’re looking for detailed, step-by-step examples of how to play an ­animation, make the phone vibrate, or making an Internet call on all possible platforms, you won’t usually find them here. But I hope that you will find enough to help you get started with every aspect of mobile development.

Introduction  xv

Organization of This Book This book is divided into three sections. Part I, “Going Mobile,” is about the possible strategies to approach the mobile world. Part II, “Mobile Sites,” covers the architecture and implementation of mobile sites and also touches on HTML5 and jQuery Mobile. Part III, “Mobile Applications,” is about the three major mobile platforms of today— iOS, Android, and Windows Phone—and also covers PhoneGap as a way of unifying ­development in a single codebase.

Finding Your Best Starting Point in This Book The different sections of Architecting Mobile Solutions for the Enterprise cover a wide range of technologies associated with mobile development. Depending on your needs and your existing understanding of mobile, you may wish to focus on specific areas of the book. Use the following table to determine how best to proceed through the book. If you are

Follow these steps

New to mobile and spent your entire career doing other software-related work

Read the chapters as they are laid out in the book.

A web developer looking into how to build mobile sites

Focus primarily on Part II.

A chief technology officer (CTO) or chief architect

Focus on Part I first, and then move to Part II and/or Part III, depending on whether mobile sites or mobile apps are more likely to be relevant in your context. But read the entire book anyway.

Familiar with mobile app ­development in one (or more) ­platforms

You might want to start with the chapters that cover topics that you are familiar with. These chapters are essential guides, so it is likely that you won’t learn anything new there. But if you find that you miss some of the points discussed, then you’ve got something already from the book. Next, I ­suggest you focus on Chapter 7, “Patterns of Mobile Application Development,” and Chapter 11, “Developing with PhoneGap.”

Note  This table simply attempts to provide some guidance on how to learn best from this book. In any case, I heartily recommend that you read all the chapters thoroughly.

xvi  Introduction

Conventions and Features in This Book This book presents information using conventions designed to make the information readable and easy to follow. ■■

■■ ■■

Boxed elements with labels such as “Note” provide additional information or alternative methods for completing a step successfully. Text that you type (apart from code blocks) appears in bold. A plus sign (+) between two key names means that you must press those keys at the same time. For example, “Press Alt+Tab” means that you hold down the Alt key while you press the Tab key.

System Requirements You will need the following hardware and software to set yourself up for development on the various mobile platforms and compile the sample code that accompanies this book: ■■



For iOS, you need a Mac computer with Xcode and the latest iOS software development kit (SDK). If you plan to use MonoTouch, then you also need to get at least a trial version of the product from Note that to deploy applications on a iOS device, you also need to be a registered Apple developer enrolled in one of the Apple pay programs. For Android, you can use a Windows PC, preferably equipped with Windows 7. Note, however, that you can do Android development from a Mac or Linux PC as well. You can use Eclipse or the IntelliJ IDEA as your integrated development environment (IDE). You will need the Java SDK and the Android SDK installed. You don’t need to be a registered developer to compile and deploy Android applications on a device. For Windows Phone, you need Microsoft Visual Studio Express for Windows Phone, as well as a Windows PC.

Code Samples This book comes with a few examples organized as follows: ■■

Two ASP.NET websites configured to use WURFL

Introduction  xvii


The Guess application for iOS


The Guess application for Android


The Guess application for Windows Phone


The HTML5 Guess application for PhoneGap

The sample code contains files that you can incorporate in your own projects using the tools that you prefer. Many of the chapters in this book include examples that let you try out new material discussed in the main text. You can download all the sample projects from the following page: Follow the instructions to download the file.

Note  In addition to the code samples, your system should have Visual Studio 2010 and Microsoft SQL Server 2008 installed. The instructions that follow use SQL Server Management Studio 2008 to set up the sample database used with the practice examples. If available, install the latest service packs for each product.

Installing the Code Samples Follow these steps to install the code samples on your computer so that you can use them with the exercises in this book: 1. Unzip the file that you downloaded from the book’s website (name a

specific directory, along with directions to create it, if necessary). 2. If prompted, review the displayed End User License Agreement (EULA). If you

accept the terms, select the Accept option, and then click Next.

Note  If the license agreement doesn’t appear, you can access it from the same webpage from which you downloaded the file.

xviii  Introduction

Acknowledgments It took me several months of deep dive to make sense of the many facets of mobile: the customer’s angle, the developer’s perspective, the architect’s vision, and the myriads of devices, operating systems, SDKs, and products. Many friends helped me out along the way. First and foremost, I want to thank Marco Bellinaso of Mopapp, who first introduced me to the world of mobile apps and then served as an invaluable technical editor for this book. Marco also tried to make me a fan of Objective-C, but I’m afraid his efforts failed in that regard. Devon Musgrave of Microsoft Press and Russell Jones of O’Reilly believed in this book and made it happen, along with Kristen Borg and the other members of the ­editing team. I was surprised to see how many friends asked to review chapters and enthusiastically shared their feedback. I could see an underlying passion and pleasure in their work and I’m not sure my monumental THANK YOU here is enough. In particular, I wish to thank Luca Passani of ScientiaMobile. I met Luca at a web conference in London in 1999, where he tried to sell me mobile as a hot business even back then. It took a bit more time, but his vision was definitely right. I really enjoyed the feedback about mobile site development and HTML5 that I got from Jon Arne Saeteras of MobileTech and Daniele Bochicchio of 5DLabs. IT and Microsoft Regional Director for Italy. The chapters on mobile apps and PhoneGap benefited from the feedback of many people, including Davide Zordan, Ugo Lattanzi, Leon Zandman, Catalin Georghiu, and Davide Senatore. All these people shared their real-world experience with me concerning Windows Phone and PhoneGap. Near-final thanks go to my team at Crionet and As I write these notes, we are finalizing the mobile apps for the worldwide audience of tennis fans ­following the Rome ATP Masters 1000 tournament. It’s the first tournament to offer a ­comprehensive mobile, web, and social experience and the first one to offer mobile apps on a full range of platforms, including not just iOS and Android, but also Windows Phone and BlackBerry. Working with you guys is a privilege. What else? Well, just a final note. Take note of this name: Francesco Esposito. I’m sure you’ll hear this name in the future. He’s 14 and he’s already an all-round mobile developer. My use of the word developer is no accident, because that’s what he is, ­irrespective of schooling and age. In his way of coding, learning, thinking, and speaking, I see crystal-clear talent. Being his dad, well, I feel proud.

Introduction  xix

Errata & Book Support We’ve made every effort to ensure the accuracy of this book and its companion ­content. Any errors that have been reported since this book was published are listed on our Microsoft Press site: 9780735663022 If you find an error that is not already listed, you can report it to us through the same page. If you need additional support, email Microsoft Press Book Support at [email protected] Please note that product support for Microsoft software is not offered through the addresses above.

We Want to Hear from You At Microsoft Press, your satisfaction is our top priority, and your feedback our most valuable asset. Please tell us what you think of this book at: The survey is short, and we read every one of your comments and ideas. Thanks in advance for your input!

Stay in Touch Let’s keep the conversation going! We’re on Twitter:

xx  Introduction

Par t I

Going Mobile chapter 1

Pillars of a Mobile Strategy . . . . . . . . . . . . . . . . . . . . . 3

chapter 2

Mobile Sites vs. Native Applications . . . . . . . . . . . . 25


C hapter 1

Pillars of a Mobile Strategy In preparing for battle, I have always found that plans are useless, but planning is indispensable. —Dwight D. Eisenhower

In this chapter: ■■

What Does “Going Mobile” Mean?


Outlining a B2C Strategy


Outlining a B2B Strategy




he modern era of mobile technology began with the release of the first Apple iPhone in the ­summer of 2007.

The mobile conquest of the world has been a “soon-to-be” matter for quite some time in the past decade. I still remember the first-ever mobile-related conference being held in Amsterdam in the summer of 2000—the Wrox Wireless Developer Conference. I was a speaker there, and the implicit message for attendees was “Mobile development is here—hurry up.” There was no hurry, actually. Only a couple of years later, Microsoft released ASP.NET with its own set of mobile controls for ­ ptimized mobile websites. Later, mobile frameworks such as Microsoft .NET Compact Framework o and Java Micro Edition (J2ME) appeared; meanwhile, richer native operating systems such as Symbian also appeared. However, the mobile conquest of the world never happened—and perhaps hadn’t even begun—which begs the question: Why not? The main reason is that the technology never reached a critical mass of users, and without that, developers and software houses had no good reason to address the mobile space. But when the Apple iPhone appeared, everything changed. Although the iPhone was not an entirely new idea, it was an extremely well-done implementation. And, more importantly, a lot of people (on the order of millions) liked it. That immediately created a breeding ground for new applications and gave mobile technology a new form and immediacy.


The lesson to learn from this is that software is the effect (not the cause) of the mobile ­ henomenon. People buy devices long before they have much compatible software to run on them. p Therefore, a compelling device, bought by a critical mass of users, creates a compelling market for specific software over time. Today, there are a few popular mobile operating systems and a growing number of users willing to pay to get nice applications to run on them. The popularity and convenience of mobile devices drives companies to create their own mobile applications that can reach their customers while they’re traveling. Mobile sites are still an excellent way to do that, but whether companies build mobile sites or mobile applications targeted to a particular platform (today, that would include iPhone, Android, BlackBerry, and Windows Phone), companies need to be part of the mobile revolution in much the same way they became part of the web revolution a decade ago.

What Does “Going Mobile” Mean? This book is aimed at architects and developers who are willing (or need) to implement mobile ­solutions for customers. A solution, however, is not necessarily and not simply a mobile application. Today, and even more in the near future, a mobile solution will be created as a combination of a ­classic website for desktop browsers, a website specifically designed for classes of mobile devices (known as an “m-site”) and one or more applications for specific mobile operating systems. The definition of a mobile solution is not carved in stone, for two excellent reasons. First, the ­ obile industry never sleeps; it churns out requirements and opportunities at an impressive pace, so m any current definition of a mobile solution may change to incorporate new aspects in a matter of just one or two years. Second, a mobile solution applies to a particular business scenario. The business scenario ultimately determines the details of the solution and technologies, patterns, and platforms that architects and developers will deal with. As an example, you may need to add some Facebook applets or multiplatform desktop applications if the business has social networking implications. Similarly, you might restrict the range of mobile platforms to just one if you’re building a vertical enterprise-class solution for a single customer. As I see things, going mobile is a far more serious task than simply writing an iPhone application. Companies investing in mobile need a strategy long before they need a mobile site or a set of mobile applications. This means companies must establish goals as well as review processes for achieving those goals—simply put, they must have a strategy. To paraphrase the quote from Dwight Eisenhower at the beginning of this chapter, in mobile ­development, plans are useless, but planning is indispensable.

Toward a Mobile Strategy So the first step for a company “going mobile” is to define a strategic plan. The strategic plan is more conceptual than it is an operational plan with comprehensive implementation details. The ­strategic plan is visionary; it identifies the future direction of the business. Outlining a mobile strategy ­essentially consists of reviewing the current business processes with regard to a few mobile axioms. 4  Part I  Going Mobile

Three Mobile Axioms Gone are the days in which a website optimized for a bunch of desktop browsers was the only way for a company to deliver an application. Today, there’s a growing demand for applications that users can reach from a variety of platforms and browsers. In the past, software architects once reached for the Holy Grail of multiplatform development—and we failed to grasp it. Now, as users increasingly demand multiplatform applications, failure is simply not an option. Mobile axioms are statements about mobile applications that are self-evident and assumed to be true. You should have these concepts clear in your mind before you start planning your strategy: ■■

Provide your services through multiple channels.


Look for new opportunities and new ways to provide your services.


Aim at making your customers’ lives easier.

Like the web a decade ago, mobile is about new ways of doing both a selection of old tasks and entirely new actions. Mobile is highly attractive to users because they can get the services they need in a variety of ways and using a variety of devices. As a company, “going mobile” means being ­committed to making your customers’ lives easier through ad hoc and personal services. The fundamental point, however, is that this challenge is not limited to just a few segments of the industry; it’s a global challenge.

Multiple Channels As you can guess, going mobile likely involves significant investments on your side to restructure existing processes, implement new ones, and fix—or at least extend—a portion of your back end software. Delivering services to a variety of channels is challenging. Mobile channels (tablets, devices, or mobile sites) are more personal and typically involve smaller amounts of information. Your existing back end must be able to serve these new requests effectively while preserving both scalability and performance, and while still ensuring at least the same level of security. A good example of an application delivered through multiple channels is Facebook; other ­examples are airline booking and home banking services.

New Ways to Provide Services Mobile is both about bringing existing services to people’s fingertips and about creating brand-new services. A mobile device is a personal device, so everything that shows up there is potentially “at your fingertips.” The real estate of a mobile device is considerably smaller than a laptop, but most ­applications and websites are padded with extra information (including menus and layout) that is not necessarily required. The advantage of a mobile solution in this context is that it can provide exactly what’s needed whenever the user needs it—instantly.

Chapter 1  Pillars of a Mobile Strategy   5

A mobile user is typically traveling around. Your application may query the user’s current ­location and use that information to offer new, unique, and tailor-made services. Location-aware services are really at the heart of the extra power of mobile applications. This is not so much because a desktop site is unable to detect the user’s location, but because a site can use the location details in much more compelling and useful ways when the user is out of the office. This is definitely an area to ­explore if your business is in any way related to location. As an example, an application that provides information about transportation can use your ­location data to restrict search or sort results automatically, winnowing out nonessential data for other locations. The same concept applies to mass retail applications, which might notify users of special offers when they are close to a shop, or provide them with free coupons in a nearby shop that they can reach within a few minutes.

Simplify Customers’ Lives I see more and more companies from a variety of industry segments strongly committed to making their customers’ lives easier and better. I believe that is a key challenge for attracting new customers and keeping existing ones. On the other hand, by not going mobile, you risk alienating customers from your brand. As mentioned earlier, mobile applications are more personal than desktop applications. They’re often relatively simpler in terms of logic and complexity, and they often consume smaller amounts of information. That’s precisely what makes a customer’s life simpler—the application is more focused; ideally, it can handle more related information aggregated from multiple remote sources. Basically, an effective mobile application should be able to give users what they need at any particular moment. Architecting the system around these new needs is the effort that companies should invest in. It’s not simply a matter of software architecture, though. Architects may be able to tell the best way of realizing an idea, but they can hardly identify what makes your users happier. In general, an ­appropriate analysis and prioritization of use-cases selects the range of features that—once ­implemented—put more information at the user’s fingertips and make life easier.

Mobility and the Industry According to a Gartner report presented in the spring of 2010, mobility occupies a relevant position in the list of top priorities for chief information officers (CIOs) of various industry sectors through 2013. According to this report, transportation and retail are the industry sectors that are paying the most attention to mobility. In these sectors, there’s a strong sentiment that it is an “either now or never” matter; there’s less and less space left for companies that hesitate or just skip going mobile. The mobile space is open for business (for now) and companies need to establish their presence as soon as possible. If they don’t, others will fill the gap and become your toughest competitors. Also, according to Gartner, beyond transportation and retail, other sectors interested in m ­ obility are healthcare, utilities, education, and—guess what—software publishers. Media and financial ­services are also there, lower on the list. 6  Part I  Going Mobile

The trend that Gartner excerpts from CIOs’ priorities may be different from country to country; however, past history shows that a general trend is always a trend that applies worldwide (though at a different pace in various locations). I can contribute my direct experience in Italy, where most leading mass retail companies are only now experiencing what many experts call the first stage of mobility—merely establishing a static presence. Typically, this process is initiated via nearly functionless mobile sites that go hand in hand with existing primary desktop sites. The next step usually involves adding a bit of context through proactive alerts, and advertising based on location, identity, or perhaps barcode recognition. Finally, the third level of mobility awareness concentrates on providing all-round services at users’ fingertips.

Defining a Mobile Strategy Each business has its own mission, expressed as purposes and activities. A mobile strategy revisits and extends these purposes and activities in light of new devices and a new lifestyle. The mobile axioms should just inspire a realistic vision for the mobile business. If this scares you, don’t worry: it’s nothing new—in fact, you’ve been there already, a decade ago. Although different in features and results, the mobile revolution follows the same pattern that the web revolution did. Early adopters content themselves with just being there and show customers they’re online. Then, executives start developing a new vision of the business and architects ­actually build it. It’s not a waterfall-like process; actually, it has a lot of inherent agility and looks like an ­intertwined process. In the end, every company ends up with what the management envisioned in their future—good and bad.

What Do You Want to Achieve? Personally, I think that for most companies, embarking on mobile projects is not a choice related to gaining an immediate profit. Of course, that mostly depends on the type and size of company. If your business is selling ringtones, then naturally you expect profits from your mobile software right away. However, if your business is selling news, you might want to use mobile channels to make your readers’ lives easier, so long as you can add such services at a reasonable cost to you. With the all-free model becoming less affordable every day, going mobile and attracting readers with mobile device capabilities is an immediate expense that hopefully will help achieve better results in the medium term or in the long run. With a strategy defined in terms of expectations and requirements (covering growth, profitability, and markets), you can look at your overall mobile technology strategy. All in all, there are two (not mutually exclusive) possible expectations: reaching the largest possible audience and ­improving the experiences of existing customers by building a rich, jaw-dropping application. Implementing each scenario may require a different set of concrete technologies, languages, and platforms. And each scenario may have different costs.

Chapter 1  Pillars of a Mobile Strategy   7

Reach Out to Users You reach mobile users by making your application available on the devices they use. This ­apparently obvious, no-brainer statement hides all the complexity (and costs) of mobile ­development. Take a closer look at this statement, though, and you’ll find two huge questions whose actual ­implementation determines the actual level of complexity (and costs) of reaching out to users: ■■

Which devices are your customers using?


How do you make your application available on all of them?

Before you can answer those questions, you need to think about this: What’s a mobile device, anyway? According to one widely accepted definition, a mobile device is one that you might have with you at any time, can be used more or less instantly, is a personal item, and can be used to connect to a network. A laptop, for example, seems to match most of these requirements—except that you are hardly likely to take it with you when you go out for a walk or buy groceries—and laptops don’t usually start instantly. Cell phones mostly fall into the category of mobile devices (many cell phones have at least some browsing capabilities). Finally, smartphones and tablets match all the definitional requirements.

Note  Recently, I used the preceding words, more or less, to introduce mobile development challenges to a developer audience. One of the attendees winked and playfully replied: “So, you mean that my Windows Mobile phone is not a mobile device? It takes ages to boot up.” A mobile strategy also depends on the level of control you can exercise over the devices your users have. For example, if in your context, user means “employee,” then the company can decide to support just one mobile platform and focus development on that. If you think that user means “consumer,” however, then reaching out to a large audience usually means developing multiple similar applications for various devices. The same applies to scenarios where user means “employee,” but the company is giving its employees the option to use the device of their choice. Deciding how to approach the technology is a delicate and critical point of a mobile strategy that I’ll address in more detail in the section “Outlining a B2C Strategy,” later in this chapter.

Offer Rich Applications If you know that a significant share of your users connect to your site using a particular mobile device, or if the content you’re offering can best be consumed on specific popular devices, then your mobile strategy should include the development of an ad hoc application optimized for that device. You don’t have to target each possible family of devices; instead, you can establish priorities and add new applications progressively. Suppose that you own a radio station. You want to increase your audience so you can sell more ad slots. Most radio listeners are faithful, so despite the switch to mobile, they may well still be listening to their favorite radio station while out and about. They might be listening via radio-equipped MP3 8  Part I  Going Mobile

players, original equipment manufacturer (OEM)–applications using the embedded radio system of a mobile phone, or Internet-based free radio programs. In all cases, users can listen, but they can’t ­interact and increase your site traffic. But if you can develop a specific mobile application and let listeners interact with your back-end systems via the web, consume streamed live music, ­access ­podcasts, traffic reports, news, submit feedback, blog, and more, you can gain interactivity and ­increase user participation. Should you address all the major mobile platforms at the same time? That mostly depends on both your budget and management’s expectations. One common pattern is to build an iPhone application first, and then follow that up with an Android or iPad application. At a radio station, to continue with the example, a tablet device such as the iPad may add little extra value compared to an iPhone. So the second step in your strategy probably would be to develop an Android application, letting iPhone and iPad users share the same application. I’ll return to this point in a moment and address it more specifically in the next chapter, but keep in mind that mobile applications don’t necessarily mean iPhone or Android applications. A mobile site can be as functionally rich, and it is usually more cost-effective.

B2C and B2B The full spectrum of mobile applications falls into one of these two categories: ■■

Business-to-Consumer (B2C)


Business-to-Business (B2B)

A third label is worth mentioning, though: Consumer-to-Consumer (C2C). Although not terribly relevant at the current stage of the industry, C2C provided the spark for the whole mobile ­revolution. The mobile revolution we’re experiencing these days would probably have remained on hold for another 10 years without a lot of (initially) independent developers who enthusiastically embraced iPhone and Android programming and built clever applications (regardless of their usefulness). Some of these developers capitalized on the success and exposure of a single application to build a business and help the mobile revolution thrive. Going B2C or B2B poses different challenges and drives different implementation choices. For ­ xample, in a B2C scenario, a key decision is about how to make the application available and get e consumers to notice it—whether it’s a free or paid application. In some cases, the question is a ­no-brainer (the app pretty much has to be free). In other cases, a more sophisticated model that ­offers a free (but perhaps feature or time-limited) version of the application is offered to entice users to purchase the full-feature paid version. In still others, consumers can select either an ad-supported version or an ad-free paid version. In contrast, in a B2B scenario, you have a fixed number of users to reach. Here, your focus is on enabling users to return what you expect quickly, effectively, and securely. Security and middleware, in fact, are usually far more important in B2B scenarios.

Chapter 1  Pillars of a Mobile Strategy   9

Development and Costs Developing mobile applications is neither cheap nor quick. Many companies find this surprising when they approach mobile projects. But mobile development is only apparently similar to web or Windows development; the two have different programming frameworks and often different (and uncommon) programming languages. Furthermore, mobile suffers from the lack of a consolidated set of patterns. Another reason that raises costs for mobile is the need to produce different user interfaces (often both layout and images) for different devices. This has never been a requirement for web or desktop applications. All these factors currently make mobile development significantly more expensive and time-consuming than web development, although time will help alleviate some of these issues. It is commonly believed that outsourcing development is preferable to having in-house ­ evelopment, largely because in-house development means that you first need to invest in training. d It’s one thing to train a team of developers on ASP.NET and then have them build three sites in a row. But it’s quite another to train a team on three different mobile platforms and then have them build the same application three times from scratch—once for each relevant platform you plan to address. Outsourcing allows you to eliminate in-house training costs and speed up development. In return for this, however, you must pay more for the outside expertise. It’s worth exploring some of the ­reasons that make mobile development more expensive than many executives think at first.

Targeting Multiple Platforms The mobile ecosystem is populated by several different platforms, each of which has its own ­more-or-less unique set of features and capabilities. The most popular platforms today are iPhone, iPad, Android, Windows Phone, and BlackBerry. The list of platforms, however, doesn’t end here. Other platforms that you are likely to encounter or need to consider are Symbian, Windows Mobile, Meego, Bada, QT, and webOS. And when you begin to look at using tablet devices, the range of platforms that you may need to take into account grows even more, because there are tablet-specific variations of the aforementioned platforms, including Android Honeycomb, BlackBerry PlayBook, and the upcoming Windows 8. Each platform has its own operating system, its own programming application programming i­nterface (API), and its own set of programming guidelines. Often, each mobile platform requires ­applications be written in a specific programming language, such as Java, Objective-C, C#, or C++. So does this mean that you must port or develop your application from scratch for each of these platforms? Frankly, very few applications (e.g., content providers) need to address all these platforms. More typically, applications target a subset of no more than three or four of them. If it is crucial for your business to reach the largest possible audience, even those running on low-end devices, then you might want to look at HTML—specifically HTML5—to build a website optimized for mobile devices (i.e., an m-site). As you’ll see in more detail in the next chapter, m-sites are often the first option that you should consider when targeting multiple platforms is a true business necessity. M-sites, ­however, are not free of device issues either. In the end, building a mobile site can be considerably more ­complicated than building a website. 10  Part I  Going Mobile

Addressing the Device Fragmentation Issue If you felt frustrated by desktop browser fragmentation—too many different browsers to optimize webpages for—you have never explored the mobile jungle. Each device—and by device I don’t ­simply mean smartphones—has its own browser, and each browser has its own user agent string, which changes for each version and operating system update. And, of course, the actual set of capabilities can change for each device as well. The screen size is probably the most important capability to take into account because of real estate and pixel density. The dimension of the device fragmentation problem is far larger with mobile browsers than with desktop browsers. When it comes to mobile site development, you have thousands of different device models to take into account, not just a few dozen smartphones, often with a pre-fixed set of ­capabilities. How can you approach such a task? Writing a set of pages (if not the entire site) on a per-device basis is simply not feasible. The ­ ne-size-fits-all approach is viable, but it comes at the cost of leaving a lot of older devices behind o and giving up on advanced features that smartphones have. This is typically not good enough for companies whose success depends on online content, such as social networks, or media and news companies. The alternative is multiserving, which basically consists of three points: ■■

Group devices in classes based on their capabilities


Build a version of the site for each class of devices that you intend to support


Define a strategy to serve the right site for each connecting device

That’s easy to say, but how can you determine the capabilities of a given device? How can you know the size of the screen, the operating system, the quality of video codecs, whether the ­device supports graphic processors or certain HTML features (e.g., file upload and CSS gradients), the ­availability and accuracy of location services, and even much more specific capabilities, such as image inlining (the ability to display images from page-embedded Base64-encoded strings)? For some of these capabilities, such as screen size, you can ask the browser itself. In fact, forums are full of questions about how to determine effectively the “real” size of a screen on a particular device and model. For other capabilities, such as image inlining, there’s just no way to make such a query. You just must know it. About 10 years ago, Luca Passani had the vision of starting a community-driven project aimed at ­collecting reliable information about the effective behavior of mobile devices. He created the WURFL project, short for “Wireless Universal Resource File.” Today, WURFL is a centralized database that stores detailed information (more than 500 different capabilities) about more than 15,000 mobile devices and mobile browsers. Today, WURFL is managed by ScientiaMobile ( and made available through both commercial and open-source licenses. Multiserving takes mobile development to a new level of complexity, but this is where WURFL shows its value: WURFL makes multiserving manageable. Multiserving is inherently expensive, but using WURFL can make it considerably less expensive.

Chapter 1  Pillars of a Mobile Strategy   11

I’ll return to the topic of mobile site development in Chapter 4, “Building Mobile Websites,” and cover WURFL features in detail in Chapter 6, “Developing Responsive Mobile Sites.”

Note  WURFL is the device detection engine that powers a number of very large and ­popular mobile sites: Facebook, Google, AdMob, and a long list of mobile network ­operators and virtual network operators.

Looking for Best Practices If you are building a desktop website, you can rely on a number of tutorials, widgets, articles, books, and posts that give you guidance. The same isn’t true for mobile software. The importance and complexity of mobile site development is not yet perceived in its entirety. Too many developers (and, worse, architects) succumb to the siren call that m-sites are simply ­standard websites with different Cascading Style Sheets (CSS) and layout. Turning to native mobile applications, all you can find are official API references, long and staid ­ fficial guidelines in the form of white papers, and a ton of useful tips and tricks scattered in a variety o of question/answer sites (such as StackOverflow). This is largely because mobile applications are relatively new and the entire space is fragmented; very few developers who program for iPhones know (or are interested in) Android or Windows Phone development. Furthermore, the stereotypical iPhone/Android developer considers mobile sites old-fashioned. The bottom line is that when you are facing mobile development for business (for example, say your boss told you that you have to build an application in just a few weeks), you have no good place to look for common practices. Even when you can figure out most common practices, it’s tough to know whether those common practices are also best practices.

The Marketplace Tax Finally, development of mobile applications is subject to appstores. Apple made this model popular with i-tools (such as the iPhone, iPod Touch, and iPad); Microsoft took the same route with Windows Phone (and seems to be inclined to forge ahead with it in Windows 8); Google (for Android) and RIM for BlackBerry left their appstores optional for developers. The role of appstores is crystal clear: they are there to protect users who buy or download ­applications from an appstore to their devices. The appstore owner guarantees the quality of ­published applications. For developers, getting approval from the appstore owner requires more effort to ensure the quality of the final product—which is not a bad thing for consumers. For ­companies, the appstore model means that there’s an extra distribution cost, which I like to call the “marketplace tax.” Companies have to pay to gain the right to distribute even free applications, and for paid applications, they typically have to provide about 30 percent of the app’s revenue to the ­appstores.

12  Part I  Going Mobile

Outlining a B2C Strategy A B2C strategy is built around two pillars: reaching out to users and making them happy. Both pillars are quite generic and can be implemented in various scenarios with slight variations. You may need to reach the largest audience possible, including holders of low-end devices devoid of flat connectivity rates. Likewise, you may need to focus on holders (and potential holders) of smartphones. You may need to push a mobile application with certain characteristics to keep existing users and make them glad that they chose your brand. Alternatively, you may need a mobile application to attract and engage new users by offering new services or new ways of consuming existing services. Needless to say, a B2C approach is particularly suitable for companies that already operate their core business in B2C mode. It comes as no surprise that, according to the Gartner report mentioned earlier, the industry sectors most interested in mobile are transportation, retail, healthcare, software publishers, financial services, media, and in general, content providers.

Focus on Your Audience Any business that aims at being successful should focus on its potential audience and make ­projections about the composition of this audience in terms of age and other social and personal ­aspects. With this consolidated information in hand, you can make better plans. In this regard, a ­mobile strategy is merely a specific form of business strategy. A mobile audience is made up of people who own a mobile device and are (or may be) ­interested in the services you provide. Figure 1-1 depicts these two sets of users and shows how mobile ­applications fit in with your existing customer base.

Your existing customers

Mobile users

Figure 1-1  Mobile applications as the point of contact between existing customers and mobile users.

Note  With regard to Figure 1-1, it should be noted that the overlap between “mobile ­users” and ­“existing customers” is moving and may change from month to month. When looking at the figure, don’t take the size of overlap as truly representative of all businesses. The fact that the overlap is not null is perhaps the really important thing to remember.

Chapter 1  Pillars of a Mobile Strategy   13

Not all of your existing customers will become users of your new mobile infrastructure, but some generic mobile users will join the universe of your customers because of the mobile framework. This also should be read the other way around: If you don’t go mobile, you may lose a share of your ­existing customers who are also mobile users.

A Quick Look at Global Numbers It may sound obvious, but I’m going to say this anyway: the world is full of mobile devices. For the most part, these are low-end devices with a basic HTML browser, a quarter VGA (QVGA) screen (240 x 320 pixels), perhaps a camera, an MP3 player, and a few games and utilities. According to the 2010 statistics of the International Telecommunication Union (ITU)—the agency of the United Nations (UN) responsible for information and communication technologies—there are 78 mobile devices per 100 inhabitants distributed all over the world, and a peak of 114 per 100 ­inhabitants in developed countries (see Whichever way you look at it, the data shows that there are a few billion mobile devices of any type out there. How many of these are devices (and users) that you want to reach with your ­application? Probably as many as possible if you’re Facebook or Google; a small fraction is enough otherwise. The same ITU source reveals that there are about 30 Internet connections per 100 inhabitants all over the world, and 70 per 100 in developed countries. Although the two numbers are not directly related, this statistic gives a better approximation of the size of a potential mobile audience. ­However, according to eMarketer (, in 2011 the smartphone penetration in the world expressed as a percentage of all mobile devices is around 11 percent. That figure is expected to grow to about 50 percent over the next three years. The data is more interesting when you look at these numbers for selected areas and ­countries. For ­ xample, the smartphone share grows to 37 percent in North America and 32 percent in W e ­ estern ­Europe. It’s around 10 percent in Asia and stays below 5 percent in Africa and Latin America. A ­ mazingly, the ­country with the highest penetration is Italy, with 47 percent currently (expected to grow to 67 percent by 2014). And this in a country—my country—that still has wide areas of digital divide, and where one family out of three doesn’t even have a home broadband connection. The next section presents a few more numbers to help you understand the big picture of mobile connectivity.

A Deeper Look at Numbers If you take global numbers literally, then by focusing on an iPhone application and disregarding m ­ obile sites entirely, you cut off 90 percent of the potential worldwide audience—and even more than that if you consider that not all iPhone devices may be capable of running your application ­because of versioning issues. From this perspective, a mobile site seems to be a very reasonable choice.

14  Part I  Going Mobile

Note  That iPhone users are approximately 10 percent of the total smartphone-­using ­population is an estimate that seems to find many direct and indirect confirmations from a variety of sources. Considering only the U.S. market, iPhone users represent about ­one-third of the smartphone segment, which is reported to range around 30 percent of the total audience for mobile devices. Statistics, however, depend on a number of factors and often represent little more than an opinion! Regardless of your final choice, blindly looking at global numbers is not necessarily the correct approach. Suppose that after running a few customer surveys and having analyzed your website logs, you know that 50 percent of your real customer base use iPhones and connect from Italy. Given those ­figures, should you really focus your effort only on a mobile site? Probably not. A desktop site that looks decent on most devices, that looks good on iPhones, and features a native iPhone application is the best combination. Note that the costs of implementing the iPhone application dwarf anything else. On the other hand, if your business is selling ringtones or news, then you need to reach out to the ­ idest possible audience, regardless of the devices they’re using. A solution that reaches this objective with w the lowest cost is your Holy Grail. Today, this means developing a solution based on HTML and JavaScript.

Facebook Was Not Built in One Day In mobile, as well as in any business, time to market is critical. In laying out your strategy, consider ­applying an agile schema that lets you release applications piecemeal. Figure 1-2 presents the ­canonical Scrum process adapted to mobile projects.

Solution backlog

Sprint backlog


Working Increment of the solution

Figure 1-2  A Scrum-like model for mobile solutions.

The entire set of features and applications (“product backlog,” according to the Scrum ­dictionary, and labeled “Solution backlog” in the figure) is partitioned into multiple sprints or iterations. At the end of each sprint, you release a working segment of the entire application (such as an iPhone ­application) and then are ready to reiterate the same process for another sprint (for example, an equivalent Android application).

Chapter 1  Pillars of a Mobile Strategy   15

More often than not, sprints for mobile solutions also include the following: ■■


Arranging a website that’s usable by both mobile applications and sites. This means exposing the core functions of the website as easily callable, Representational State Transfer (REST)– based, HTTP endpoints. For example, if you’re building the website using the ASP.NET Model-View-Controller (MVC), this may mean exposing an ad hoc controller that can serve requests based on the use-cases that you implement in mobile clients. Developing a set of pages (scripts, styles, graphics, and presentation logic) for a class of mobile devices. You may want to start with high-end devices and proceed downward to enable more and more lower-end devices to access some fraction of the full site functionality.


Optimizing the behavior of these pages with more accurate device-detection capabilities.


Developing native applications for most popular mobile platforms.


At each level, you can propagate valuable user feedback through the entire stack of ­applications you’ve built thus far.

To paraphrase a popular saying, “Rome was not built in one day.” I’d say that Facebook was not ­always the huge platform we know today, either—after all, it’s been around only a few years. A ­mobile solution, therefore, will look increasingly like a small platform of integrated services; it ­requires hard work and overcoming many challenges to complete.

Delivery Models A B2C application is (ideally) distributed worldwide. The costs of spreading the word about its ­availability (not advertising…) are entirely up to you. A website is immediately available from any place in the world, but again, the costs of spreading the word about it must be borne entirely by your organization. In the mobile world, appstores rule over the publication and distribution of platform-specific ­applications. You publish your application to the appstore, giving it instant exposure to users of a ­particular platform. Each device ships with an applet so that users can access the platform’s ­appstore—where your application gets published. Users can then access your application, read release notes, check requirements (such as that your application requires Internet access, phone calls, text services, local storage, and so on), see some screenshots, test-drive a trial version (if available and supported)—and what then? What do you expect the return from investing in a mobile application to be? More generally, how do you expect to recover the costs of developing a mobile site and/or a few native applications? That’s another part of overall strategy that management has devised.

Note  Here, I’m talking about “spreading the word” and “publishing,” which you get for free for the minimal costs of being a registered developer with the platform of choice. Advertising your a ­ pplication in and out of the appstore is another story entirely. 16  Part I  Going Mobile

The Free/Paid Dilemma Mobile applications are typically very cheap when they’re not entirely free. The cost of the ­average iPhone application is around $2—even less for games. The average iPhone user is expected to ­download (and pay for, if that’s required) about 80 applications in the course of a year. Paid applications generate direct income subject to the marketplace tax (and, of course, ­ overnment taxes). Free applications are generally built for marketing and branding purposes, or as g an additional form of customer service. After reading analysis and projections, expert opinions, and analytics, I formed the idea that ­ obile applications should be free; they need to generate revenue in some other way. However, if m you’re an individual or a small company and happen to have a stand-alone (not bound to a strategic business plan) mobile application, why give it away for free? If it’s a well-done application that fills a hole in people’s mobile lives, you can likely recover your investment, and perhaps even more. A third option is advertising-supported applications, which are free for users but generate ­revenue for the author through dynamically inserted ads. Switching to a paid or ad-based model is an ­important step. If you first release the application for free, you get a lot more downloads, which are good for feedback. It also helps you understand how well received your application is and whether it really fills a hole. If you look into the most popular appstores such as the Apple App Store, Android Market, ­ indows Marketplace, and BlackBerry App World, you will find that there are almost always more W paid applications than free applications. For example, in the Android market, free applications ­outnumber paid applications by about a 60/40 ratio. The free/paid dilemma is not really a dilemma with a binary, black-or-white answer. There are a few other models that mix free and paid content according to different recipes.

The Freemium Model The Freemium model is based on the idea that you provide the full application free and then ­offer users the chance to buy a few extra services. From a realistic business perspective, however, the ­Freemium model means that the vast majority of your users will consume your application for free; only a minority will pay for any extra services. So how can this model be worthwhile (financially speaking) for mobile applications? First and foremost, you need a lot of users, preferably on the order of millions, and at minimum on the order of tens of thousands. Maintaining all these users probably has a cost as well. For example, if you need to maintain a website to provide data to the mobile application, then you have a growing cost directly related to the number of users. Even if your application can run as a self-contained device application, you still may have some costs per user because you have to support users and reply to their emails. An excellent example of a mobile application for which the Freemium model is perfect is Evernote ( These mobile applications work entirely on the devices they target; all they need is storage space. According to­in-stats, Evernote has more than 6 million users. Of those, only 3 percent pay an extra subscription fee.

Chapter 1  Pillars of a Mobile Strategy   17

Another example is Searcheeze (, a new startup that offers c­ ollaborative search. Users, both groups and individually, can run and publish a search on a given topic. This search—realized by humans, not search engines—may be left free or published to an internal marketplace. Becoming a Searcheeze user is free unless you want to buy extra services, such as installing a private engine on your company’s servers.

The Premium-with-Free-Sample Model The premium-with-free-sample model is fairly new in the media industry, but it’s already the model toward which most content providers and newspapers are moving. Basically, it consists in making a significant portion of the content available for a small fee but leaving a fraction of the content free for everybody to access. The New York Times pioneered this model. It currently gives you a number of free articles per month, after which you have to pay a fee to access more content. In contrast, the Boston Globe locked three-quarters of its digital content and offers free access only to the remaining part., Italy’s largest news site and second-best-selling newspaper, also uses this latter model. In addition, charges for access to its mobile site. In contrast, the desktop site is free, but you need a smartphone to read it effectively. It’s worth noting that the Boston Globe mobile solution is based on a HTML5-powered mobile site, which maximizes the audience without incurring the costs of developing ad hoc mobile ­applications and, importantly, without paying the typical 30 percent marketplace tax to an appstore owner. ­Appstores, in fact, may impose ad hoc policies for in-app payment. During the summer of 2011, Amazon quickly modified the Kindle iPhone and iPad applications to comply with new Apple policies for subscription-based applications. At nearly the same time, the Financial Times application—a bestselling program—was pulled from the store because it was patently in violation of the store rules. As a result, the Financial Times now encourages customers to use its new HTML5-based mobile site, which—guess what—has been optimized for iPhone browsers and looks nearly the same as a native application.

The Quid-Pro-Quo Model As an Italian, I would have used another Latin phrase to express the same concept: do-ut-des. ­According to Wikipedia, the English usage of quid pro quo in fact matches the Italian usage of do-­ut-des perfectly, meaning “I give so that I can receive.” This model is probably the one I feel most comfortable with. In my personal vision of the world, a mobile application exists as a complimentary feature, a favor that the publisher does for me. I ­reciprocate the favor by buying some of the publisher’s other content or services. The free applications are entirely free; there are no strings attached. To use them fully, however, you need to buy or consume some other services that the publisher relies on for income. Applications you use in an airport, during a tennis tournament, or at a conference are all examples that fall in this category. You get some services via the application in exchange for the simple fact that you’re there (in airports or at conferences): you don’t pay directly for these services (mostly information and news), 18  Part I  Going Mobile

but you pay in some other way. For example, you probably paid to attend the conference or bought a ticket through that airport. Here’s another example of an application that I had the pleasure of knowing from an insider’s ­perspective: I ported it from iPhone and Android to Windows Phone. The application is called Postino; you can find out more about it at Postino was originally built for the iPhone and then ported to a number of other platforms, one step at a time, as the result of a classic B2C strategy. Postino lets you snap a picture as you travel and promptly creates a (virtual) postcard that you can send to a friend. The postcard contains a message, a signature that you draw on the screen with your finger, and an address. If the address is an email address, everything is free. If the address is a physical address, then you must buy a virtual stamp and upload the card to a server, which will print and send a real postcard. An application built around a simple but good idea can be free, generate income in an indirect way, and still represent a success story for the developer (or the company), which may generate more business.

Outlining a B2B Strategy I certainly don’t have the expertise and experience to embark on a comprehensive discussion about the differences between B2C and B2B. As far as mobile strategies are concerned, there’s only one important difference: B2B often gives you the chance to choose one specific platform and vendor and stick to that. From a software company perspective, B2B means that you’re helping another business set up a mobile infrastructure that will be used to serve a limited and largely controlled audience, such as the network of agents that operate in a given region. For the purpose of this book, the difference between B2C and B2B is the same as the difference between a public Internet site and an intranet site.

Serve Your (Limited) Audience Let’s review the main traits of a strategy aimed at serving the needs of just one business. The mobile interface is not open to the public; it’s consumed by special customers, such as employees, agents, and consultants. Although you don’t have to capture a large audience, you instead have a relatively small audience that you must serve in the best possible way. Forcing them to use one particular ­device or site is part of the deal.

B2B and the BlackBerry Case What made BlackBerry so successful and BlackBerry devices so widely used? Sure, it offers email, tasks, and calendaring; it may even support web browsing and a camera. You can do some instant messaging and run a few utilities from an appstore that is one-tenth the size of Apple’s. But ­compared to, say, an iPhone, a BlackBerry device looks like a child’s toy. So why was it so successful (at least before the iPhone arrived)?

Chapter 1  Pillars of a Mobile Strategy   19

The answer lies in the enterprise-class features that it offers. In particular, a BlackBerry device can connect to an in-house enterprise server—the BlackBerry Enterprise Server (BES)—and receive email updates, news, and task alerts in real time. How is that different from today’s Microsoft Exchange Server connectivity in Windows Phone? It’s not, really; both are basically the same—but BlackBerry was available somewhat earlier, and companies liked its features. As a BES administrator, you can ­apply policies and prevent a class of users from using the camera or instant messaging; you can force them to use only certain applications or to navigate only certain sites. Moreover, you can install your applications directly to your BlackBerry devices; you don’t need to distribute them publicly to an ­appstore first. In a nutshell, BlackBerry was a platform created to help members of an organization collaborate with ease and effectiveness.

Pick One Mobile Vendor In a B2B scenario, a customer calls the software company and discusses requirements. The advisor has to figure out just one solution that provides the requested services in a mobile way. Most of the time, there are no constraints on existing devices and hardly any constraints to address on the platforms. If you need a better mobile infrastructure to make employees collaborate, you probably have no reason to build an iPhone application. In addition to the costs of development, you also need to ­account for the costs of providing an iPhone to all your employees. I can think of a few companies who just did that—but I consider them the exception rather than the rule. So in a B2B scenario, you should select just one vendor and platform and stick to that. From the customers’ perspective, costs are clearly lower, and development time is traceable. Which vendor you settle on depends on a number of factors, including the existing base of devices, deployment needs, special security or middleware constraints, existing skills, and, of course, overall cost and personal preferences. I’ll return to this in a moment, but I think it’s important to call attention to that point, because in a B2B scenario, the mobile vendor is not simply—and not necessarily—the vendor of a mobile ­operating system and API. In some cases, the candidate vendor doesn’t even have its own mobile ­operating system. Instead, it offers its middleware with a bunch of platform-specific p ­ resentation ­layers for users to consume data and applications. According to Gartner’s Magic Quadrant for 2010, Sybase is an excellent player in a B2B scenario—and Sybase doesn’t have an operating system; ­instead, it provides a strong and powerful middleware for mobile clients.

Private Applications When a company’s goal is to build mobile solutions for its workforce, any applications that it develops should be private. A private mobile application is a mobile application that can be installed directly on one or more devices, with no intervening appstore. Consider, for example, an iPhone application written to serve the needs of a particular customer of yours—such as an application for sales agents. That application is likely built to reflect the use-cases and business processes of that customer. It may have integrated some strong authentication policy. You don’t want it to go to the ­marketplace, 20  Part I  Going Mobile

and you don’t want others to even look at it, let alone try it or buy it. You want it to work like ­Windows—you create an application, prepare an installer, run the installer on the machines you want, and that’s it—you’re done. Private mobile applications are possible, but the process is not identical across the various ­ latforms. In this regard, Android and BlackBerry are open: you can install just any application on just p any device. For BlackBerry, this freedom of installing applications can be controlled and restricted by BES administrators. In Android, the only controller is the owner of the device. Apple has a special enterprise program that, at the cost of $299/year, allows you to distribute ­applications freely within the members of your organization, whether through an intranet webpage, a network share, or email channels. Windows Mobile—the predecessor of Windows Phone—is as open as Android; Windows Phone still lacks an enterprise program. Currently, the recommended approach for simulating a private, company-wide marketplace is to make the application public and free and implement logic that unlocks the application only for users who have a specific Personal Identification Number (PIN).

Mobile Enterprise Application Platforms In a B2B scenario, you typically choose a mobile vendor by analyzing its mobile enterprise application platform (MEAP). A MEAP indicates the entire stack of mobile technologies, products, and services that a mobile vendor (e.g., Sybase) offers.

MEAP vs. Stand-Alone Applications When building a mobile solution, you could proceed by building a few stand-alone front-end ­applications that are based on an existing middleware or an ad-hoc back end and storage layer. But in doing so, you will likely end up using tools, services, and technologies from different vendors for the various phases of development. MEAP is beneficial because by choosing a particular vendor, a company can often build a single back end and front end and deploy them to a variety of devices. The mobile device functions as a terminal that simply mirrors the content generated by the back end. A MEAP-based solution ­relies on proprietary middleware that you can customize and extend by writing applets using a few ­programming languages. The middleware serves data to the mobile client and controls both the user interface and local in-device logic. With a MEAP in place, a company can expand its horizons with less effort—no need to invest in writing a new iPhone application; just deploy the same MEAP-specific application to the iPhone ­presentation layer. No changes are required to the underlying business logic, and the list of mobile front ends can be extended whenever the MEAP adds support for a new mobile platform. In other words, a MEAP is an all-round business partner that specializes in mobile solutions. In this context, the classic iPhone or Android mobile application is just the tip of the iceberg—the real meat and potatoes are what lies under the surface.

Chapter 1  Pillars of a Mobile Strategy   21

Gartner’s Rule of Three To explain the importance of MEAPs and, at the same time, give companies an easy way to check their affinity with a MEAP solution, Gartner developed the Rule of Three. According to Gartner, a company should consider a MEAP seriously when the implementation of its mobile strategy requires three or more mobile applications for three or more mobile operating systems to be integrated with three or more back ends. It goes without saying that building a mobile platform from scratch with these requirements is a huge effort that probably requires a monstrous budget. In this context, a MEAP can introduce significant savings and—more importantly—keep the company at the forefront of the technology, ready to release new products in a fraction of the time that non-MEAP-using competitors might require.

MEAP and Gartner’s Magic Quadrant How do you evaluate a MEAP? And more importantly, which vendors are actually MEAPs? Each year, Gartner applies its proprietary Magic Quadrant methodology to competing players in a given area—in this case, MEAP. The result is a diagram like the one shown in Figure 1-3.


Niche Players


Ability to execute


Completeness of vision Figure 1-3  Gartner’s Magic Quadrant.

The rank the research returns for each evaluated player determines the coordinates in the ­diagram and, subsequently, the quadrant into which that player falls. In the paper published in 2011, the Leaders quadrant contains companies such as Sybase, Antenna Software, Syclo, RhoMobile, and Pyxis Software.

22  Part I  Going Mobile

It is worth noting that, according to Gartner, the MEAP market is steadily heading for a $2 billion volume in sales. So where are the other big companies commonly associated with mobile solutions? To be a MEAP player, a vendor must have a comprehensive set of products and services to develop and test applications and offer security, (cloud) storage, notification, reporting, and synchronization. Microsoft, Apple, and RIM appear in Gartner’s Magic Quadrant but are not considered leaders in this segment.

Summary No company can afford to ignore the mobile revolution taking place. Not all companies should ­proceed at the same pace or immediacy, but going mobile is a growing need and will soon be a necessity. The expression “going mobile” refers to the process of defining a strategic plan that sets business objectives that can be reached by restructuring internal processes, adopting innovative technologies, and developing ad hoc new applications to reach users who are traveling or to let one’s workforce operate efficiently while away from the office. This chapter outlined the main aspects of a mobile strategy both in a B2C and a B2B scenario. The next chapter takes a closer look at the two main ways of providing a mobile experience to users, whether customers or employees: mobile websites and platform-specific native applications.

Chapter 1  Pillars of a Mobile Strategy   23

C hapter 4

Building Mobile Websites Intelligence is the ability to adapt to change. —Stephen Hawking

In this chapter: ■■

From Web to Mobile


Development Aspects of a Mobile Site


The Device-Detector Site




mobile site, much like a native mobile application, is most likely to be consumed by users on the move: people who are standing up, in a hurry, busy, or waiting in line. Under these conditions, users are probably willing to connect to a site using a tiny device because they really believe that they derive some benefit from the site. The site, therefore, must be direct, concise, and accurate. It is essential that a mobile site should load quickly and allow users to reach all main functionalities in just a few clicks or taps. The user interface should be extremely clear, but also clean and flawless to show the options available at any time, yet still making the act of choosing an option easy. After becoming familiar with the site, users often end up working with it semi-automatically, so even the position of a single button can have an impact on the quality of feedback that you receive. Note that the mobile Human-Computer Interaction (HCI) research field, although new, is very active, and a lot of studies exist about the dos and don’ts of interaction between mobile users and mobile devices and software. Luca Chittaro has a paper that effectively summarizes what mobile HCI means to developers and architects. You can read it here:

The previous chapter emphasized the importance of accurately selecting the use-cases to ­implement. The number of use-cases, however, should be kept small so that the site doesn’t end up as a shrink-wrapped version of the full site. A pragmatic (and then not necessarily exact) rule is that a mobile site rarely needs more than 20 percent of the features available in the full site. I’d even go further by saying that sometimes, not even the 20 percent of features you take from a parent ­website should not necessarily be reimplemented “as is.” You might want to restructure some of these ­use-cases and even add new ad hoc use-cases for related scenarios. A mobile site is a brand-new project that can inherit some code and services from an existing site—more often than not, it inherits large shares of the business logic. This chapter covers a number


of issues and open points that you will want to solve before embarking on building a mobile site. After addressing all these points, building the mobile site is reduced to the work of writing a relatively simple and small website.

From Web to Mobile You rarely build a mobile site without also having a full site in place. Most of the time, you build a mobile site to serve mobile users better. In some cases, you start building both full and mobile sites at the same time. Currently, it’s quite unlikely that you build a mobile site as a stand-alone project. Whatever the case may be, however, this section aims at isolating the issues that differentiate a ­mobile site from a full website. If you’re building a mobile site as a spin-off of an existing website, then the chances are good that you will be able to reuse large portions of the existing application’s back-end code. Those include the data access layer, the domain layer, and possibly a bunch of other distinct components (such as ­services and workflows) that you may already have in place, which will provide bits and pieces of ­business logic. If you can replicate some views without too much modification, you may even end up being able to reuse webpages and ASP.NET Model-View-Controller (MVC) controllers—more ­generally, parts of your presentation and application layers. As you move towards the presentation layer, though, the chances of reuse diminish. How would you deal with scripts, images, style sheets, and markup? For images and style sheets, there’s probably an easy answer—you just have to reduce their size. For scripts and markup, the answer is less obvious and likely is influenced by context.

Application Structure Before the community of web developers (re)discovered AJAX a few years ago, websites were always built as a navigable collection of distinct pages. Jumping from one page to the next required links and forms. The browser handled each request, which resulted in a full replacement of the current page. AJAX changed the course of things by using the services of a small browser-hosted component—the XmlHttpRequest (XHR) object—through which your script code can play the role of the browser and ­conduct server requests autonomously. The net effect is that webpages can contain ad hoc script code that use XHR to download data or partial pages. After being downloaded, the content is processed by some other script code and used to update the currently displayed page. AJAX can be used for some ­specific (perhaps even critical) features, or it can be used extensively throughout the site. When that ­happens, the site architecture is usually referred to as the Single-Page Interface (SPI) model.

The Single-Page Interface Model In brief, the SPI model refers to a web application that behaves more or less like a desktop ­application—it has a primary user interface (UI) layout that is adjusted and reconfigured via AJAX calls. The page downloads everything it needs from the source site via script-controlled actions. 64  Part II  Mobile Sites

The SPI model has been recently formulated as a manifesto. You can read about it here: As an early AJAX adopter myself, I’ve always been a fan of the SPI model, but I’ve also always seen it as a vector rather than a concrete pattern to implement. As a result, I have not fully implemented the SPI model in a production site yet, primarily due to lack of confidence, proper facilities, and tools. Moreover, I always found it difficult to sell a 100-percent JavaScript site to a customer—at least, that was true up until two or three years ago. Today, the situation is different. The SPI manifesto dates back to the summer of 2011. With that said, I’m not completely sure that a SPI model is appropriate for just any mobile site. An SPI model requires a lot of JavaScript, partly written by you and for the most part imported from external libraries. You likely need quite a few of these libraries to provide for generic UI manipulation, templates, and data binding. Some of these libraries are based on jQuery and jQuery Mobile. These two libraries alone total some 200 KB (uncompressed) of script and style sheets.

Important  In a production site, you typically apply minification and GZIP compression to script and other resources, thus reducing significantly the size of the download. Minification is the process of removing unnecessary characters from source code without breaking any functionality. Applied to script files, minification also adds a (thin) layer of o ­ bfuscation to your code, making it much harder for humans to read. GZIP is, instead, a popular ­compression format. Once properly minified and gzipped for a production site, the jQuery library is 31 KB and a bit less for jQuery Mobile. In addition to script, SPI requires helpers for data binding and UI refresh, which adds a few more tens of kilobytes. Popular libraries in this segment include JsRender, JsViews, Knockout, and Upshot. In summary, the size of the JavaScript assets that a client will need to download can consume a few hundred kilobytes, which can become a problem. Once downloaded, of course, the browsers will cache the scripts; they don’t download the code over and over again. But the browser needs to do a lot of work to render SPI pages—work that goes far beyond simply requesting and rendering ­markups. The more advanced the device browser is, the more the SPI model becomes affordable (from a resource standpoint) for mobile sites. Personally, I wouldn’t adopt the SPI model without first performing deep analysis of the context. The main challenges with an SPI implementation can be summarized as follows: ■■


In case of intermittent connectivity, it’s difficult to figure out whether the problem is with the application or the network. This may be frustrating. Not that this same problem doesn’t exist for other models (i.e., the full-page refresh model), but at least tiny, non-SPI pages download well, even with limited bandwidth. Moreover, with no connectivity at all, you immediately grasp the nature of the problem—when nothing shows up, the problem is not the application. Many sites require users to log on before they will serve content. If the users’ session expires, the full-page refresh model redirects them to the logon page at the first successive access. The Chapter 4  Building Mobile Websites    65

problem is both manifest and easily resolved. With an SPI site, although user authentication is also AJAX-based, it may take hours before you figure out the root cause of the misbehavior you’re observing. In SPI, user authentication requires due attention and effective client and server-side implementation to work smoothly. So let’s explore some other available options.

Note  ASP.NET MVC 4 ships with a new project template that promotes the use of the SPI model. The template uses Knockout and Upshot.

Full Page Refresh At the extreme opposite of SPI lies the classic Full Page Refresh (FPR) model. FPR is how the web worked for years: the browser makes a request for a new page, the web server returns the new page, and the browser replaces the current page with the new rendered content. This process occurs ­repeatedly for each user action. AJAX (on which SPI is heavily based) made the classic FPR web experience much less compelling, and it also made it more natural for users to expect that only fragments of the current page would be updated as the result of a given action. In a desktop scenario, the FPR model is cumbersome, so more and more large sites are progressively adding AJAX-based capabilities. However, the significant impact that FPR has had on desktop sites (which have large displays and numerous auxiliary resources for downloading, caching, and refreshing content), is less so on mobile sites because mobile pages are considerably smaller and lighter to begin with. Still, loading several small pages may still be less engaging than updating bits and pieces of the currently displayed page. Updating the current page may still be slow over a slow connection, but at least it doesn’t have a dramatic impact on the user experience.

Partial Page Refresh Some middle ground between SPI and FPR can be found in the partial rendering that both ASP.NET Web Forms and ASP.NET MVC support. In terms of traffic, partial page refresh (PPR) falls between the two extremes—it is not as efficient as SPI, but it’s not as poor a user experience as FPR. The idea is that the browser places a request as usual, but that request is captured at the script level—via ­embedded script—and silently transformed into an AJAX request. On the server side, the web server handles requests as if they were regular full page requests, but the response is packaged as an HTML fragment. The data being transferred is a mix of data and markup—just the delta between the markup of the current page and the requested new page. The benefit of the PPR model is that it offers many of the benefits of AJAX without the cost of ­having to learn new programming features. In ASP.NET Web Forms, PPR happens relatively ­automatically through the UpdatePanel control; in ASP.NET MVC, it occurs through the Ajax.BeginForm HTML helper. 66  Part II  Mobile Sites

In a nutshell, using PPR means that an FPR approach won’t require special skills on the ­ evelopment side. In contrast, an SPI model may represent a complete paradigm shift for many d ­developers. PPR represents some middle ground.

Context Is King Which of the previous options is preferable? There’s no obvious and clear answer. If you’re ­determined to find just one answer, then the best approach depends strictly on the context and the knowledge that you have about the devices that are going to access your site. If smartphone traffic is ­predominant, you definitely can opt for SPI. But if you’re interested in reaching the widest possible audience, then you probably should opt for FPR. The point, though, is that there’s probably no ideal solution that works in all cases. Mobile devices are so different that you really should consider partitioning your audience into a few distinct classes of devices and arrange a different solution for each. That could mean serving plain HTML pages to older browsers while implementing a nicer SPI solution for smartphones.

Note  In general, you always should consider AJAX seriously because it reduces the amount of network traffic. Extensive use of AJAX, however, actually may raise the number of Hypertext Transfer Protocol (HTTP) requests. In a mobile scenario, an HTTP request is more expensive than in a desktop scenario because connections are slower, limited in number (reduced parallelism in download), and also sometimes processed in a more convoluted way, especially if the connection doesn’t happen over a WiFi network.

Amount of JavaScript The amount of JavaScript that you might want to use for the pages of your mobile site is another huge point. Processing JavaScript is crucial to minimize web traffic; on the other hand, it also affects performance. Like it or not, mobile devices (even high-end smartphones) are not as powerful as laptops. Among other things, this means that a mobile device may not be able to tolerate effectively the same amount of JavaScript that you could employ in a full-fledged website. In this context, “not able to tolerate” just means consuming more battery power even if the perceived page performance is acceptable.

More Info  The consumption of battery power tends to increase with the number of HTTP requests. Subsequently, a JavaScript-intensive page is critical from the resource ­management perspective. Here’s a reference and some numbers: Other excellent resources for making sense of the amount of JavaScript and its performance are Steve Souders’s blog ( and

Chapter 4  Building Mobile Websites    67

The jQuery Family of Libraries Today, the jQuery library is a must for nearly any website. I’m personally dreaming of the day when jQuery will be native to browsers and be integrated into every browser’s JavaScript engine. Until that day comes (if ever), jQuery must be linked and downloaded if you plan to use it. Note that jQuery is required even if you plan to use only jQuery Mobile, which offers a variety of ready-made components for scaffolding a mobile site. Plug-ins for jQuery Mobile can put a “skin” on your mobile site so that it looks like a native application with animations, navigation effects, and snazzy presentation. All in all, once minified and gzipped, all this JavaScript is likely affordable for use with high-end mobile browsers, even though JavaScript-based effects may emulate some native effects closely but are never the same in terms of performance. With that said, you’ll need to be able to limit the quantity of JavaScript in your pages if you want to enlarge your mobile horizons to non-smartphone devices. So except for smartphones, consider dropping jQuery and derived libraries entirely. On these ­non– high-end devices, the chances of encountering quirks, bugs, unsupported features, and ­unexpected behavior is quite high; therefore, why take the risk? By simplifying your page ­structure, you still should be able to include some JavaScript-based dynamic behavior that relies only on ­Document ­Object Model (DOM) support and basic language tools. A good rule of thumb is that (with the notable exception of smartphones and tablets) any quantity of JavaScript beyond 10 KB can begin to degrade load time and performance.

Note  Whether you use jQuery or not, unobtrusive JavaScript always should be your guiding star. Unobtrusive JavaScript means having a place at the start of the code where you attach handlers to elements so that degradation in the case of unsupported features is easier to handle.

JavaScript Microframeworks For a desktop site, nobody really minds having a few hundreds of kilobytes in script code. Gmail, for example, fully loaded, usually exceeds the range of kilobytes for loaded JavaScript code. The idea of loading a full-fledged, monolithic JavaScript framework in a mobile site is often ­unaffordable, ­especially if you want to target more than just the top iPhone and top Android devices. Still, it’s useful to be able to use the services of existing code and ready-made frameworks. JavaScript microframeworks come to the rescue. Microframeworks are small, highly focused libraries whose overall size is often only a few ­kilobytes; sometimes even 1 KB or so. There’s no magic and no special tricks—microframeworks are so small not only because they are minified and gzipped, but also because they take on just one or two tasks. You probably will want to pick up a library for asynchronous (async) loading: one for optimized DOM traversing, one for touch gestures, and perhaps a few more. You can find an interesting list of such microframeworks at; their average size is around 1 KB. 68  Part II  Mobile Sites

One microframework for general-purpose JavaScript programming in the context of mobile sites is XUI (see XUI is not specific to a single task as are some of the libraries listed on ­; instead, it’s specifically designed for mobile scenarios, so you can consider it a ­competitor to other larger mobile frameworks such as jQuery Mobile and Sencha Touch. Unlike these larger frameworks, XUI doesn’t force you into a given programming paradigm or page structure. It focuses on a few tasks (e.g., DOM/CSS management) and totals only 5 KB gzipped. XUI is a good alternative to jQuery libraries for mobile sites and offers a powerful alternative to jQuery libraries for lower-end devices that support JavaScript, DOM, and Cascading Style Sheets (CSS). Chapter 5, “HTML5 and jQuery Mobile,” will cover the whole topic of jQuery Mobile. Sencha Touch is a JavaScript framework, originally created to add touch capabilities to mobile pages, but which is now a full-fledged framework for developing mobile web applications that look and feel native on most mobile platforms such as iOS and Android. You can find out more about SenchaTouch at

More Info  A good resource for microframeworks, and for comparing their pros and cons against larger script frameworks such as jQuery, is Addy Osmani’s work at

Application Device Profiles Device fragmentation is huge in the mobile space. If the differences between browsers in desktop site development scare you, then be aware that the mobile space is much worse. On rare occasions, you can get by with just one set of pages for a mobile site. Ideally, you need pages that can adjust intelligently to the characteristics of the requesting browsers. Sometimes you just end up having multiple versions of the same page—one for each device (or class of device) that you intend to support. Alternatively, sometimes you may have one common page template that you fill up with device-specific content. But at the end of the day, these are implementation details. The crucial point is that you need to split your expected mobile audience into a few classes. Then, for each page or view, you provide class-specific markup. This is the essence of multiserving, as ­briefly described in Chapter 3, “Mobile Architecture.” Chapter 6, “Developing Responsive Mobile Sites,” will illustrate multiserving with an example.

Note  In most developed markets today, it is possible to cover most devices with good ­semantic markup of some kind and then progressively enhance the presentation and ­interaction using CSS and JavaScript. In this regard, the concept of device classes applies to CSS as well: however, if you want to present different content to different classes of devices, then you need to use multiserving because the markup will change between classes.

Chapter 4  Building Mobile Websites    69

Practical Rules to Class Profiles In the mobile space, neither the team building a given site nor the team producing a general-­purpose library can afford optimizing pages on a per-device basis—the number of potential devices to take into account is just too large (in the order of several thousand). Hence, a common practice has ­become to classify all the devices you’re interested in into a few classes. How many classes do you need to have, and how do you define a class? A device class typically gathers all devices that match a given set of capabilities. You define the classes based on the business cases and scenarios. A basic (but still arbitrary) classification may consist in splitting the whole range of requesting devices into three categories: smartphones, tablets, and all other browsers. You provide a rich web experience to smartphones, serve the full site to tablets, and offer plain HTML to all others. How would you define a smartphone? Everyone would agree that an iPhone is a smartphone while, say, a Nokia 7110 is not. [The Nokia 7110, released in the fall of 1999, was the first device equipped with a Wireless Access Protocol (WAP) browser.] In contrast, the Nokia 6600 certainly was a ­smartphone when it came out in 2004, but nobody would consider it a high-end phone today. But there are no hard and fast rules. You should know that not only the device classes, but also the rules that determine which class a given device belongs to, are highly variable and strictly specific to a ­business scenario. At the same time, this lack of fixed rules and practices makes it possible for e ­ verybody to define classes in a way that best fits a given business. All you need is a reliable ­infrastructure that first identifies the device and then tells you about its real capabilities. I’ll return to that infrastructure in a moment. As a purely intellectual exercise, here are some requirements that identify a modern smartphone in 2012. Note that these are likely to change, even in the near future. ■■

Operating system (minimum version): all versions of iOS, Android 2.2, Windows Phone 7, RIM OS 6, Samsung Bada 2.0, Symbian Anna, and Nokia Meego


Input mode: touchscreen


Screen size: 320 × 480 pixels

Admittedly, this definition is rather arbitrary, and it may sound too restrictive for some while being way too relaxed for others. Above all, this definition will become progressively less pertinent as more powerful devices hit the market. A tablet has two main characteristics—it is a mobile device (not a desktop browser), and it has a larger screen than a smartphone. You can probably set the lower boundary to 640 pixels today. It is important to note that grouping all the remaining devices into a single class may be a tough decision. Whether you really want to serve plain static HTML to all of them or further split the ­remaining devices into two or more classes is up to you. How can you discover the capabilities of the browser for each device? How can you be sure that the requesting browser is really a mobile device? If it’s sufficient for your needs to just check the screen size and screen resolution, then you might decide to go with CSS media queries for ­high-end 70  Part II  Mobile Sites

browsers, and use script code that simulates that on older browsers. Although this a ­ pproach may work in some cases, it’s not a route that will take you far. Instead, relying on a commercial ­device ­description repository (DDR) is probably the best way to go. Chapter 6 discusses a few DDR ­frameworks, focusing in particular on WURFL.

Dealing with Older Browsers When I talk to executives planning the mobile strategy of their companies, I often get the ­impression that when they say “mobile,” they just mean the iPhone and iPad. While it can’t be denied that iPhones and other smartphones are actually responsible for most of the mobile traffic to sites, the mobile universe contains many other types of cell phones and devices as well. Unfortunately, not all of them have the same characteristics, but they are so numerous that you must find a common denominator approach. In the process that you use to identify the device profiles to support, you must define the bottom of the stack at some point. Devices that fall into this sort of catchall group typically are served plain HTML or, at least, the simplest markup that your mobile site can serve. What’s the best way to handle this? When you end up having a catchall device profile, it also means that there’s some rich library you’re relying on for higher-end devices. The jQuery Mobile library is an excellent example. Such mobile libraries sometimes offer to scale down the otherwise rich markup they produce on older browsers automatically. That’s apparently a fantastic deal for you: you write the mobile markup once, and it gets d ­ owngraded automatically for less powerful browsers. Unfortunately, my current experience has not been particularly positive on this point. Although most libraries do fulfill their promises of ­downgrading the markup, the quality of the HTML that they produce when that happens is often below your ­desired standards. You probably want to take care of the HTML being served to older devices yourself rather than blindly relying on the kind of hard-coded markup served by some libraries. The bottom line is that while jQuery Mobile (and other libraries) can truly downgrade HTML based on the requesting browsers, you’ll achieve a better final effect if you manually fix up the output. ­Currently, I’m inclined to use jQuery Mobile—but only to serve smartphones and tablets.

Note  Chapter 5 will cover jQuery Mobile in more detail, including more about its ­browser-graded support matrix. That feature is orthogonal to performing your own device capability detection, but overall, I prefer to skip the automatic downgrading, at least with the current version of most libraries.

Optimizing the Payload Minimizing the number of HTTP requests to websites is always a good thing, and it should be a ­central aspect of any strategy aimed at improving the performance of a site.

Chapter 4  Building Mobile Websites    71

If you have ever tried to use a mobile device to connect to a very basic site with a few plain HTML pages, a bit of CSS, and one or two images over a 3G data connection, you have experienced a delay, or latency. This latency is relevant if the device is not one of the latest smartphones with a powerful processor. In the mobile space, minimizing the total amount of data transferred and the number of requests is not simply a matter of optimization; it is a crucial development point. Over the years, a number of recommended practices have been worked out to help ­developers build fast websites. Yahoo! has been quite active in this field, publishing a very valuable ­document that you can read here: The rules in that ­document are written for a generic website, but for the most part, they can be applied equally well to both desktop and mobile sites. Here’s a summary of the key suggestions: ■■

Take care of the page structure and find the right place for scripts and style sheets.


Reduce the number of HTTP requests.


Reduce the size of resources.


Maximize the use of the browser cache.

Let’s briefly go through the optimization aspects that are most relevant to mobile sites next.

The Page Structure A mobile browser may load pages significantly slower than a laptop browser. This means that not just raw performance but also perceived performance is important. Little tricks, such as placing style sheets at the top of the page in the section help, because doing that means that the body of the page will be ready to render as it is downloaded. The overall download time doesn’t change, but at least users see some results a bit sooner. Similarly, placing scripts at the bottom of the page is helpful because it reduces the impact that s­ ynchronously downloading scripts may have on page rendering. When browsers encounter a

Note that this file is named and is resolved in _Viewstart.cshtml, using an enhanced version of the native UrlHelper object in ASP.NET MVC: @using Mobi.Framework.ViewEngines; @{ Layout = Url.Content("~/Views/Shared/_Layout.cshtml", mobile:true); }

Chapter 4  Building Mobile Websites    99

As mentioned, the layout file implements a single-column view and points to external resources using our custom Url.Content method as a resource switcher. Let’s find out more about the viewport tag. Most mobile browsers can be assumed to have a rendering area that’s much larger than the ­physical width of the device. This virtual rendering area is called the viewport. The real size of the internal viewport is browser-specific. However, for most smartphones, it is around 900 pixels. H ­ aving such a large viewport allows browsers to host nearly any webpage, leaving users free to pan and zoom to view content, as in the following illustration: Browser area


This behavior may perhaps be desirable (or at least not too disturbing) when you have a ­high-resolution smartphone; but what if your users host the site within a 240 × 320 device? It’s like looking through a keyhole. To gain control over mobile browsers’ viewports, you add an explicit ­viewport tag and instruct the browser about it as follows:

In this example, you tell the browser to define a viewport that is the same width as the actual device. Furthermore, you specify that the page isn’t initially zoomed and can’t be zoomed in by ­users. Setting the width property to the device width is fairly common, but you can indicate an explicit number of pixels. Figure 4-15 shows how the same page looks on an older device with and without the viewport tag.

Adjusting the Style A mobile site deserves its own CSS file where you define a bunch of new styles required by the ­specific user interface. In addition, the CSS file will probably need to override some of the styles shared with the desktop site (if any). For example, you might want to remove background images and replace them with solid colors. Background images are a great example to show how CSS media queries can hardly be the perfect fit when you need to provide multiple views for devices other than smartphones. With media queries, you only have the device width to distinguish devices. However, when it comes to devices less than 300 pixels wide, you can still find different capabilities. Some relatively powerful devices fall in this category that have touchscreen and good HTML capabilities. For these devices (e.g., Samsung Corby), 100  Part II  Mobile Sites

you can still use background images, but you cannot for any devices smaller than 300 pixels. This is to say that you can do a lot with CSS styles, but not everything. Beyond a threshold, you just need to upgrade to another solution as WURFL. (See Chapter 6 for more information.)

Figure 4-15  Effects of the viewport tag.

In a mobile style file, it is important to use the padding property appropriately to ensure that ­clickable elements (in touch-enabled devices) are large enough to accommodate a relatively ­inaccurate pointing device like the human finger.

Adjusting the HTML View The sample site, Device Detector, while not realistic in terms of functionality, is an excellent ­starting point for understanding the role of browser capabilities. Figure 4-16 compares the desktop and ­mobile versions of Device Detector.

Figure 4-16  Desktop and mobile site face to face.

Chapter 4  Building Mobile Websites    101

The mobile site requires an extra step to get to the real data: you must click the Details link. The Index view is therefore different in our ASP.NET MVC application. The view simply renders a static markup with a couple of links. It is interesting to see where the Details link points. It points to a Details action method on a new controller—the DeviceController—that is used only by the mobile subsystem: public class DeviceController : Controller { public ActionResult Details() { ViewBag.UserAgent = Request.UserAgent; ViewBag.IsMobile = Request.Browser.IsMobileDevice; ViewBag.SupportTables = Request.Browser.Tables; ViewBag.MobileDeviceInfo = String.Format("{0}, {1}", Request.Browser.MobileDeviceModel, Request.Browser.MobileDeviceManufacturer); ViewBag.PreferredImageMime = Request.Browser.PreferredImageMime; ViewBag.ScreenSize = String.Format("{0} x {1}", Request.Browser.ScreenPixelsWidth, Request.Browser.ScreenPixelsHeight); ViewBag.SupportAjax = Request.Browser.SupportsXmlHttp; ViewBag.DomVersion = Request.Browser.W3CDomVersion; // Point to the device.cshtml view return View(); } }

The method would return the view generated from the Details.cshtml template. However, because this method is invoked only from the mobile site, the actual view file will be However, the view engine being used here can pick up Details if it can’t find The Details method collects some data about the requesting browser and composes them into the view. As you can see in this example, the information about browser capabilities is what ASP.NET makes available natively. I actually took the screenshots of this chapter from a site where I installed the MDBF repository—now largely outdated, but far better than the default ASP.NET browser configuration. In particular, you can consume some of the capabilities being passed down to the view to fork your rendering code, as shown here: @if (ViewBag.SupportTables) { ...
} else {
  • ...
  • ...

102  Part II  Mobile Sites

Figure 4-17 shows a screenshot of the site captured from an iPod device.

Figure 4-17 The Device Detector site displayed on an iPod device.

Figure 4-18, instead, shows the same site on a low-level device, but it is still touch-based and has some decent HTML capabilities (JavaScript and CSS support).

Figure 4-18 The Device Detector site displayed on an Samsung Corby device.

Chapter 4  Building Mobile Websites    103

Figures 4-17 and 4-18 don’t show noticeable differences in the rendered markups. However, if you view it live, you see that the device of Figure 4-18—an older device—takes a while to render the page for at least a couple of reasons. First, it doesn’t have much processing power, so any operation (­JavaScript or just downloading) is slower. Second, it doesn’t have WiFi support; so any download can occur only via 3G. The rendering experience is somewhat painful because it first displays the ­skeleton of the HTML; next, it downloads the CSS and applies colors; and finally, it gets the picture and inserts that into the layout. Tweaking HTML for older browsers is an operation that you might want to ­optimize on a per-page basis—if it is worth the cost.

Summary This chapter tried to turn into practical advice and bits and pieces of code some of the most ­common practices employed today to build mobile websites. The number of mobile devices is huge, but, on the other hand, you don’t have to target all of them. Mobile development is about understanding what you and your customers want and need. This is a crucial point and results in an ideal selection of use-cases. Appropriate and well-described use-cases are essential for any application, but it is a bit more important for mobile applications and sites. For mobile sites, in particular, I estimate that it represents the largest share of the work. Selection of use-cases helps to keep the whole application up-close-and-personal, establishing a relationship between code and user that is much stricter than with any other type of application. Beyond this point, building a mobile site is a matter of optimization: minimizing requests, ­ inimizing content being downloaded, and minimizing the user’s activity. But it's also a matter of m ­optimizing the design to find a good compromise between UI widgets and touch capabilities. The user interface is critical: common widgets like drop-down lists and check boxes, while valid to express the behavior of a view, may require a different rendering and graphical structure. Finally, a mobile site may largely reuse code in the back end of the sister desktop site. Coding the back end is probably the simplest aspect of mobile site development. The next chapter covers in more detail two technologies that have been mentioned only briefly up to now: jQuery Mobile and HTML5.

104  Part II  Mobile Sites


Symbols 3G connections,  178 51Degrees, 96 @catch directive in Objective-C,  222 @finally directive in Objective-C,  222 - (minus sign) denoting instance methods in Objective-C,  217 @OutputCache directive,  56 + (plus sign) denoting static methods in Objective-C,  217 @property directive,  216 @synthesize directive in Objective-C,  218, 233 @throw directive in Objective-C,  222

A A4 and A5 processors for Apple devices,  247 accent color, background for tiles and icons in Windows Phone, 337 accordion widget, creating with jQuery Mobile,  117 actions, adding in iOS,  237, 239, 251 ActionScript,  274, 385 ActivatedEventArgs class,  337 Activated global event,  336 ActiveX components, Ajax capabilities via,  152 activities in Android,  281 completing user interface,  285 displaying alert messages during activity,  301 editing source code of root activity in PhoneGap project, 409 Game application (example),  295 life cycle of an activity,  283 Activity class,  282 getSystemService method,  310

onCreateOptionsMenu and onPrepareOptionsMenu methods,  291 actual_device_root attribute, elements in WURFL XML data file,  145 adapter objects in Android,  306 ad hoc distribution provisioning profile, creating,  262 ad hoc user interfaces,  47 Adobe AIR,  274 compilation of applications for mobile platforms, 385 Adobe Creative Suite 5.5,  215 Adobe PhoneGap framework. See PhoneGap framework agile schema for piecemeal release of applications,  15 AGPL v3 licenses,  144 Ahead-of-Time (AOT) compiler,  247 AIR. See Adobe AIR AJAX, 64 benefits and disadvantages of using,  67 browser caching of responses,  74 browsers' support of,  107 capabilities in WURFL,  152 checking for browser support of,  98 and cross-domain issues,  403 Full Page Refresh (FPR) model and,  66 group of capabilities in WURFL,  145 page links and transitions in jQuery Mobile,  117 Predictive Fetch pattern,  199 requirement for use to download data for local output or data cache,  57 use in jQuery Mobile to download and display pages, 111 Ajax.BeginForm HTML helper,  66 A-la-Carte-Menu pattern,  185 examples of,  186 AlertDialog class,  301 alert function, JavaScript,  411 alloc and init methods, NSObject class,  219


Android Android, 10 background services,  335 service detecting network changes,  203 building PhoneGap application for,  408 context menus based on application state,  196 date type on,  82 detecting changes in visual controls and saving automatically, 180 developing for,  267–322 Android jungle,  275–278 choosing development strategy,  270–275 defining user interface,  285–294 development tools and challenges,  268–270 examining sample application,  294–308 other programming topics,  308–318 programming languages and equipment,  39 programming with Android SDK,  278–321 testing the application,  318–320 encrypting or hiding sensitive data,  191 Facebook for Android, Logon-and-Forget pattern, 190 full website viewed on (example),  48 grocery list application with voice-based input, 183 Guess (sample) PhoneGap application running on, 402 horizontally scrolling toolbar from Astro,  199 HTC Desire device, detecting capabilities with WURFL, 158 keyboard layout in browser application,  184 ListView widget,  197 Menu and Search buttons,  195 MonoDroid framework wrapping Android SDK,  213, 251 open to any applications,  21 PhoneGap applications on,  388 receiver in action,  204 Settings screen for browser application,  180 SharedPreferences, 177 storing credentials,  191 system requirements for development,  xvii wide spectrum of devices, problems for PhoneGap apps,  401 animation creating animated message box for Windows Phone app,  359 transitions in iOS,  245 Anywhere from Sybase, syncing up mobile and remote data,  177 API levels in Android,  276

418  Index

APIs (application programming interfaces) abstract API of virtual machine pattern,  383 mobile platforms,  10 App_Browsers/Devices folder, MDBF file in,  96 Appcelerator, Titanium Mobile,  274 AppDelegate class (in MonoTouch),  249 app-delegate object Guess application (example),  231 HelloWorld program (example),  226 App Hub developer account,  376 app ID for iOS applications,  261 Apple appstore for i-tools,  12 enterprise program for mobile applications,  21 Apple development program, joining,  259 Apple iPhone,  3 application bar in Windows Phone,  344–346 application behavior. See behavior of mobile applications application components (Android),  281 ApplicationConfigurer class,  156 application device profiles,  69 practical rules for categorizing in classes,  70 applicationDidEnterBackground message,  227 application:didFinishLaunchingWithOptions message, 226 application icon, creating for Windows Phone app, 337 application layer,  52 content and functions of,  53 defining for mobile clients,  53 options for,  55 application resources in Android,  284 ApplicationSettings object,  366 application startup in Android,  281 Windows Phone app programmed in Starlight, 333 application state, JavaScript application in PhoneGap HTML5 solution,  396–398 applicationWillResignActive message,  227 App Store (Apple) and delivery models for mobile applications,  18 distribution of iOS applications,  263 submitting finished applications to,  210 appstores, 12 B2C strategy and,  16 benefit for users of native applications,  37 benefits of, lacking for mobile sites,  36 mobile sites and,  18

background services in mobile applications

App.xaml file,  333, 354 creating global application resource in,  347 defining static resource,  342 ARC (Automatic Reference Counting),  212 support by Objective-C,  224 ARM assembly code,  247 ARM processor,  319
elements in HTML5,  123