Architecting Mobile Solutions for the Enterprise
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 http://www.microsoft.com/learning/booksurvey. Microsoft and the trademarks listed at http://www.microsoft.com/about/legal/en/us/IntellectualProperty/ 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
Pillars of a Mobile Strategy
Mobile Sites vs. Native Applications
Building Mobile Websites
HTML5 and jQuery Mobile
Developing Responsive Mobile Sites
Patterns of Mobile Application Development
Developing for iOS
Developing for Android
Developing for Windows Phone
Developing with PhoneGap
Contents Introduction xiii
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
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:
Aspects of Native Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 What’s Good About Native Applications
What’s Bad About Native Applications
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Chapter 3 Mobile Architecture
Focusing on Mobile Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Stereotypes to Refresh
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
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
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
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
The Sample Application
Integrating with PhoneGap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 Supported Platforms
Building a PhoneGap Project
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
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.
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.
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 http://www.xamarin.com. 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
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: http://www.microsoftpressstore.com/title/9780735663022 Follow the instructions to download the Amse.zip 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 Amse.zip 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 Amse.zip file.
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 E-tennis.net. 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.
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: http://www.microsoftpressstore.com/title/ 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]
microsoft.com. 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: http://www.microsoft.com/learning/booksurvey 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: http://twitter.com/MicrosoftPress.
Par t I
Going Mobile chapter 1
Pillars of a Mobile Strategy . . . . . . . . . . . . . . . . . . . . . 3
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: ■■
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 interface (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 (http://www.scientiamobile.com) 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
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 http://www.itu.int/ITU-D/ict/statistics). 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 (http://www.emarketer.com), 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
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.
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 (http://www.evernote.com). These mobile applications work entirely on the devices they target; all they need is storage space. According to http://blog.evernote.com/2011/01/04/evernote-2010-a-year-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 (http://www.searcheeze.com), 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. Repubblica.it, Italy’s largest news site and second-best-selling newspaper, also uses this latter model. In addition, Repubblica.it 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 http://www.postinoapp.com. 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.
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: http://goo.gl/lSG3s.
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
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.
Chapter 4 Building Mobile Websites 67
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 http://goo.gl/jnE9t.
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.
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: http://developer.yahoo.com/performance/rules.html. 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