SD1230

Unit 9Mobile Applications

Course Objectives

• During this unit, we will cover the following course objectives:– Identify the characteristics of mobile applications.– Describe the differences and similarities of mobile

Web and mobile applications.– Describe the process used to build, test, and

distribute a mobile application.

Learning Outcomes

• Completing this unit should help enable you to:– Describe the role of an emulator.– Identify the characteristics of mobile applications.– Describe the tools available for each of the three

major mobile development platforms.– Create a simple mobile app.– Given a website or application, identify

characteristics that affect its usability on a mobile device.

Mobile Web App vs. Native App

Mobile Web app• Better cross-device and

cross-platform support• More difficult to monetize• You have control• Consumers expect it to “just

work”

Native app• Device fragmentation• Need to build or port for

each platform• Product short-term revenue

for developers and operators

• Operators or platform makers have control

When to Make a Native Application

• You want to charge for it• Games• Historically required for location-aware apps, but

now many popular browsers are location-aware• Using the camera• Using accelerometers• Accessing the file system• Offline users

When to Make a Mobile Web Application

Whenever a native app is not required

PhoneGap• Native app that exposes many device features

to a Web app• Can be distributed and sold in device

marketplaces

Adapting to Multiple Devices

Detect Adapt Deliver

Strategies for Multiserving

1. You can do nothing and wait for the mobile industry to become fully homogenized.

2. You can try to use a progressive enhancement technique to provide fallback experiences to a number of devices.

3. You can target only a handful of devices that support the standards you wish to support, knowing full well that this means making your mobile experience less accessible to your intended market.

4. You can adapt the experience based on the class of the requesting device, making many assumptions about its capabilities.

5. Provide an experience specific to each requesting device.

Serving Multiple Contexts is Redundant and Expensive

Multiserving from a Central Data Source

Strategy #1: Do Nothing

• Mobile Web Initiative (MWI)• One Web – the browser is the multiserver

– It assumes that your content for multiple contexts will be the same, when it usually isn’t.

– It assumes that cost per kilobyte to the user is minimal or nonexistent. In other words, it assumes that the user is willing to pay for content not designed for his or her context.

– It assumes that a persistent and high-speed data network will always be available.

– It assumes that mobile browsers are smart and will support the same standards consistently, which isn’t the case, at least today.

– It assumes that a technology-based principle should come before the needs of the user.

One-Web Approach with Media Queries

• Add a line of code that points to a CSS file• Requires Web browser that supports CSS3

<link media="screen and (device-width: 320px)" rel="stylesheet“ href="320styles.css" type="text/css" />

Strategy #2: Progressive Enhancement

Implementing Progressive Enhancement

• XHTML<link media="screen" rel="stylesheet"

href="desktop.css" type="text/css" /><link media="handheld" rel="stylesheet"

href="mobile.css" type="text/css" />• Within CSS

@media handheld {* { font-family: sans-serif }}

Implementing Progressive Enhancement

• Class C and D<link media="handheld" rel="stylesheet" href="class-

c.css" type="text/css" />• Class B

<link media="screen" rel="stylesheet" href="class-b.css" type="text/css" />

• Class A<link media="only screen and (max-device-width:

480px)" rel="stylesheet“ href="class-a.css" type="text/css" />

Strategy #3: Device Targeting

• Use the HTTP headers information to detect the device and browser– User-Agent string

• Requires a device database on the server• Mobile Browser Detection scripts

Strategy #4: Full Adaptation

• Most expensive option to develop or maintain• Detect device browser• Dynamically render device-optimized content• Typically required for “on-deck” applications• Can be used for “off-deck” Web applications

Reasons to Use Full Adaptation• You want to deliver the best possible experience to a number of Class

B or lower devices, where other strategies don’t cut it.• You want to support users outside of the United States, where higher-

end devices constitute the majority.• You want to do anything highly transactional, like billing or payments

for content or services, for Class B or lower devices.• You want to do SMS campaigns that terminate with a mobile website.• You have a media-rich experience, such as images, video, or audio, and

need it to render properly on several devices.• You want to support several nonphone mobile devices, like GPS units,

e-book readers, portable gaming consoles, and so on.• You want to support a number of different devices and contexts, either

now or in the future.

Device Databases

• Wireless Universal Resource File (WURFL)– Open-source database of device profiles– WALL and WNG

• Adaptation libraries based on WURFL

• dotMobi’s Device Atlas– Test suite– Web interface to the database– Standards-based API

• Volantis– Content adaptation vendor

Yahoo Blueprint

Netbiscuits Web Service

Mobile-Aware Web Service

.mobi Domain

• ICANN-approved top-level domain for mobile devices

• Alternative to device detection, subdomains, or directors

Device Plan

• Deciding what to support:– View server logs to see which devices are

accessing your site.– Use demographics to determine which devices are

used by your site’s target audience.– Target the most profitable devices first.

• Create a test plan.

Devices by Market Segment

Device PlanNumber Score System

Support through progressive enhancement

Device PlanActual Dollar Amounts

Device Testing

• Test on physical devices– Often cost-prohibitive– Sometimes required

Accelerometer

Device Testing

• Other ways to get access to a physical device– Operator store– Mobile Monday device libraries

Estimating Testing Effort

• Device testing takes 2 to 4 times development effort

Sprint-like Testing

• Test the primary devices, then release• Test secondary devices after release

Test Plan

• Functional tests– Based on feature list

• Context tests– How does the user experience render on the device?– Does it load quickly and correctly?– Can you use the physical features of the device as intended?– Does it terminate correctly?– What happens when the device loses connection?– Does the application work when hopping from cell tower to

cell tower?

Test Portal

Desktop Testing

• Frames• Opera Small Screen view• WebKit browser• Simulators and emulators

dotMobi emulator

Summary

• In this unit, we covered the following topics:– Mobile Web app vs. native app– Native app creation– Multiple device support– Device plans– Testing