HIT3328 - Chapter01 - Platforms and Devices

HIT3328 / HIT8328 Software Development for Mobile

Devices Dr. Rajesh Vasa, 2012

1

Lecture 01

Platforms and

Devices

Image Source: Google

R. Vasa, 2012 2

Lecture Overview

•Eco Systems and Development Journey

•Smartphone - Hardware Overview

•Hardware Constraints (Dev. perspective)

•Mobile Operating Systems

•Convention Over Configuration

R. Vasa, 2012 3

Mobile Ecosystem

Ad

Networks

Platform

Content Providers

(Music/Video/Books)

Handset

OEMs

Telephone

Networks

App.

Distribution

Cloud

Infrastructu

re

Billing

R. Vasa, 2012 4

Mobile Ecosystem - Android

** Google, Double Click

Google, Amazon

Samsung, HTC, Motorola, Sony ...

Platform

Cloud

Infrastructure

Ad

Networks

Content Providers

(Music/Video/Books)

Handset

(OEMs)

Telephone

Networks

App.

Distribution

Billing

Google Checkout

Android

Google, Amazon

R. Vasa, 2012 5

Mobile Ecosystem - Apple

iTunes iAd

Ad

Networks

Platform

Content Providers

(Music/Video/Books)

iPhone/iPa

d/iPod

Telephone

Networks

App.

Distribution

Cloud

Infrastructure

Billing

App Store

iTunes + App. Store

Dropbox, Google

iOS

R. Vasa, 2012 6

Lecture Overview - Where are we?






R. Vasa, 2012 7

App. Development Journey

•Application Planning

•Platform / Library Selection

•Develop and Test

•Prepare for Market and Deploy

•Monetization

•Analytics, Support and Update

Management

Planning Platform Prep Develop & Test Deploy Monetize Support > > > > >

R. Vasa, 2012 8


•Planning

•User identification

•Concept / Prototype design

•Market research (focus groups)

•Requirements documentation

•[Business case / Budget]


R. Vasa, 2012 9


•Platform Preparation

•Identifying appropriate platform

•Selection of libraries and tools (increase

productivity)

•Development methodology

•Gap identification and learning plan

•Working with development community


R. Vasa, 2012 10


•Develop and Test

•IDE, SDK, Source code control tools

•UI construction / automation tools

•Emulators, Simulators, Debuggers

•Profiling and Testing tools

•Porting, internationalization

•Cloud infrastructure and services


R. Vasa, 2012 11


•Deployment

•Packaging and Signing

•Certification and Approval process

•Beta testing (Sandbox-ed networks)

•Localization

•Packaging and Managing versions

•Technical support frameworks


R. Vasa, 2012 12


•Monetization

•Distribution methods and channels

•Tools to aid promotion

•Ad. networks

•Billing and Settlement (in-app selling)

•Application usage profiling


R. Vasa, 2012 13


•Support and Tracking

•Analytics (tracking usage)

•User ratings, support

•Managing application upgrades /

updates

•Privacy management


R. Vasa, 2012 14







R. Vasa, 2012 15

Typical Hardware Capabilities

•Mobile telephony

•Sensors & Actuators

•Location detector

•CPU / GPU (optimised to run on battery)

•Touch screen (&& || small keyboards)

•Networking (WiFi, Bluetooth, 3G, 4G...)

•High resolution battery efficient display

•Memory (onboard + SD Card)

R. Vasa, 2012 16

Sensors and Actuators

•Magnetometer

•Accelerometer/Gyro

•Temperature (and humidity) sensors

•Proximity / Light sensors

•Vibrator and Haptic feedback

•Camera (Front and Back) + Flash

•Vibrate motor

R. Vasa, 2012 17

Location Detection

•Location detection is possible at fine or coarse

level using:

•GPS (fine -- to few meters)

•Cell grid triangulation (to 100 meters)

•IP network location (Suburb / City)

R. Vasa, 2012 18

Touch Screen

•Resistive (cheaper) touch screen

•Detects a change in current when touched --

any object can touch it

•Need some pressure applied

•Capacitive (expensive) touch screen

•Respond to conductive surface (like a human

finger) -- capacitance change

•Ideal for gesture / multi-touch UI

R. Vasa, 2012 19

CPU / GPU

•Current generation in wide use

•CPU + GPU on single die

•~ 50% of the graphics power of a PS3

•Next generation (Tegra series chips)

•Dual/Quad core CPUs

•GPU (8-core or 16-core)

•Entire phone feature set on single chip

•Dual/Quad core are more power efficient

R. Vasa, 2012 20

Networking

•Full TCP/IP support

•WiFi (theory~54Mbps, practice~30Mbps)

•GPRS (48 Kbps) a.k.a. 2.5G

•3G (HSDPA ~ 7Mbps, HSUPA ~ 5Mbps)

•Bluetooth (~3Mbps, Next-Gen ~ 24Mbps)

•Note: If network is operating at 1Mbps, then

you can download a 1 Mega Byte file in 10

seconds. (Mbps is megabit per sec)

R. Vasa, 2012 21

Battery Technology

•Popular technology - Lithium-Ion

•Generally around 1500 mAh battery pack

•Current generation batteries will power,

•light use (typical): ~ 2 days

•heavy use (esp. internet): 6 to 10 hours

•game play/video: 2 to 3 hours

•Battery drain depends on sensor use (but

display is the largest consumer of power)

R. Vasa, 2012 22

Where does battery go?

•How is battery used (without GPS)?

•Display (50%)

•Cell grid usage including stand by (25%)

•WiFi (20%)

•Phone Idle (5%)

•If GPS is enabled -- it will use about 20-25% of

the battery power.

•Note: The above is based on an average user

R. Vasa, 2012 23

Memory

•Persistent Solid State Storage

•Flash memory (8/16/32Gb, @ ~10MB/sec )

•SD Card (@ ~ 4 - 6 MB/sec)

•2 Gb special memory for (O/S + drivers)

•Volatile

•RAM (256 Mb - 512 Mb)

•GPU shares RAM

•Memory read/write speed is a constraint

R. Vasa, 2012 24

Display Technology

•Bright / full colour - AMOLED, OLED, LCD

•Different resolutions are used

•eXtra High density (640 x 960 @ 320 dpi)

•High density (480 x 800 @ 240 dpi)

•Medium density (320 x 480 @ 160 dpi)

•Low density (240 x 400 @ 120 dpi)

•Physical width often ~ 2 inches (goldilocks

width for human hands)

•Height often between 2 - 4.5 inches

R. Vasa, 2012 25







R. Vasa, 2012 26

Next Generation Displays

•Most widely used are medium density and

high-density (320x480 @ 160 dpi and 480 x

800 @ 240 dpi )

•iPhone4 is ~ 320 dpi (more pixels per inch)

Image Source: Gizmodo

R. Vasa, 2012 27

What are the constraints?

•As a developer you need to,

•Know typical usage (minutes or hours)

•Understand sensors (efficiency / accuracy /

reliability / batt. drain)

•Know network is unreliable and offers erratic

speeds

•Be aware that the phone may/will/can ring

•Display size, DPI & processor speed are

variable

R. Vasa, 2012 28

More constraints....

•You must develop apps that,

•Use only a few MB of memory

•Are a couple of MB in size

•Store data as efficiently as possible

•Can work with sensors where precision is not

identical across devices (even iPhone has 3

generations in wide-spread use)

•Can work with a range of memory, cpu, and

GPU capabilities

R. Vasa, 2012 29

Biggest Constraint of ALL

•The Phone can (will) RING

•When the phone rings,

•Your app. is put in the background by O/S

•If you want to save state -- you have to manage

this

•When the phone call ends,

•The O/S will try to bring your app. back into

the foreground (but not guaranteed)

R. Vasa, 2012 30

Time for distraction...

• Guess how much effort went into the design and

construction of the core font (Droid Font) for the

Android platform?

• This was followed by even more work on the new

Roboto Font.

R. Vasa, 2012 31

Short Problem 1

•Scenario:

•You are developing a “Stopwatch + Count Down

timer” App.

•Use case: The user has set the count down

timer for 2 minutes -- pressed “start”. After 45

seconds, phone rings

•What is the behaviour of your app. when the

phone rings?

R. Vasa, 2012 32

Short Problem 2

•Scenario: You developed an app that “needs”

to download ~ 30MB of data daily (Common

for newspaper apps)

•How long will it take on,

•Home broadband/WiFi (3 Mbps), 3G (1.5

Mbps), GPRS (48 Kbps)

•Design choices will you make in terms of,

•How data is downloaded? Protocols supported?

Dealing with dropped connections?

R. Vasa, 2012 33

Short Problem 3

•Scenario: You are planning to develop an app.

that will show the weather forecast for a

particular location. You want to use the GPS to

obtain the location.

•However, obtaining an initial GPS lock takes

time (30 seconds -- 2 minutes)

•Do you think it is reasonable to ask the user

to wait a couple of minutes to get the location?

If not, what will you do different?

R. Vasa, 2012 34

Short Problem 4

•Scenario: Weather App.

•Phone (at home) has not been used for around

30 minutes.

•User wants to check the weather.

•The app. opens a network connection --

downloads the weather information.

•The app takes about 60 - 90 seconds to

download weather data. Why is it taking so

long? Is this a reasonable delay?

R. Vasa, 2012 35







R. Vasa, 2012 36

Mobile Operating System

•Operating System == Resource Manager

•Tight resource constraints on mobile

•Low powered (Batt. 1200 - 1500 mAh)

•Limited RAM (256 - 512 MB)

•Relatively small disk (8GB - 16GB)

•Small (yet power draining) display

•Network access - expensive yet needed!

•If phone rings -- call gets highest priority

R. Vasa, 2012 37

Mobile Operating Systems

•Very different to how PC operating systems

are designed

•The life cycle of an application is very tightly

controlled by O/S

•If an app. is a resource hog -- it will get killed

(or suspended) by the O/S

•O/S trickle allocates memory to apps, but

aggressively de-allocates it

•If a view/image is not in the

foreground/running -- then it will be destroyed

R. Vasa, 2012 38

Mobile Op. Systems are e-VIL?

•If you request a network connection -- but

have not used it for a while,

•O/S will power down network hardware

•O/S may close the connection / port

•If the devices goes to sleep (default is few

min.) then the memory allocated to app. is de-

allocated.

•O/S (thankfully) provide a short warning and

you have options to save data.

R. Vasa, 2012 39

Android App Life Cycle

Key feature of

a Mobile O/S

Remember: ~ 256MB only

available in RAM

Image Source:

http://developer.android.co

m

39

http://developer.android.com

http://developer.android.com

R. Vasa, 2012 40

iOS Application Life Cycle (is similar)

•Memory management is different in iOS

compared to Android

•iOS will still,

•Terminate apps. if memory needed (test for

yourself -- load few large games on an iPhone)

•Send an app. into background if Phone rings

•Flush caches (used by images mainly) at

regular intervals to free resources

R. Vasa, 2012 41

States of an App.

•An app. can be in one of the following states:

•Not Running (not launched)

•Running (foreground or background)

•Active

•In-Active (waiting for I/O)

•Suspended (background)

•Process state information is saved, but RAM

used is generally purged

R. Vasa, 2012 42

Short Problem 5

•Consider this hypothetical situation,

•Each time you minimise the IDE on your laptop

computer, the O/S will suspend the application

for 15 minutes -- then terminates the

application.

•If you were developing the IDE -- and want to

offer a reasonable user experience on this OS -

- what can you do?

R. Vasa, 2012 43

Mobile File Systems

•Designed to work with Flash memory

•Flash memory is designed for max. 10k writes

•File system is optimised to ensure that the

same block does not receive too many writes

(known as wear levelling)

•Write operation -> (erase first), then write data

•Read operations are faster than write

•Read speed ~ 6 MB/sec, Write ~ 3 MB/sec

•I/O speed optimisation critical in games

R. Vasa, 2012 44

Short Problem 6

•You have created a new “app” for the Android

platform --

•App Size is 25MB (20M is media)

•What is the minimum load time for this app?

•Do you think this is a reasonable size for a

weather app.?

R. Vasa, 2012 45

When building mobile apps...

•Assume phone will ring

•Save state regularly (in fact, be paranoid)

•Assume resources are allocated reluctantly

•Assume erratic network connectivity

•Assume slow read/write speed to Flash card

•Use RAM carefully, minimise sensor use

•Inform user if any operation takes over 3 sec.

•Keep core use case as short as possible

R. Vasa, 2012 46







R. Vasa, 2012 47

Convention Over Configuration

•Software design paradigm

•Aims to reduce decisions developers make

•Why is this needed?

•When we build software, there is a lot of

routine and repetitive decision making

•By following a certain development style, we

reduce the decisions we need to make

•What do we lose? -- Some flexibility, and

developers have to accept the convention

R. Vasa, 2012 48

Example ....

•Software systems often make use of a large

number of images (icons, background etc.)

•Developers now have to make a decision:

1. Store the images in a central directory?

2. Distribute them into different directories (closer to

modules?)

3. Store them in a database system?

4. Naming of images, meta-data?

•What is the best option? Will it work? Risk?

R. Vasa, 2012 49

Decision making process..

•In order to make a decision,

•Options must be identified (takes effort)

•Options must be ranked (opinions and ideas of

different developers will come into play)

•An option must be selected

•Team must accept the selected option

•May results in ... “decision paralysis”

•Worse, sub-optimal decision making +

increase in stress

R. Vasa, 2012 50

Coding by configuration...

•Consider the “image storage example”

•Assume developers have made a choice

•Developers have to explicitly write code to,

•Load these image resources

•Manage the location that they are stored in

•Find a consistent way to refer to these images

•Agree on a naming style etc...

•Work is done -- but has minimal value add

R. Vasa, 2012 51

Coding by convention..

•All images are stored in the “images” directory

•Framework will automatically,

•Generate references to these images

•Provide code to load these images

•Enforce naming rules to identify different types

of images

•e.g. Icons will be named with ic_ prefix.

•We improve productivity -- in terms of reduced

decision making

R. Vasa, 2012 52

Why does this matter?

•Android prefers and dictates “convention”

•However,

•You can ignore the convention and fallback to

configuration

•Benefits of convention,

•Productivity improvement

•Improve team coordination

•Reduces unnecessary stress

•iOS development has its own conventions!

R. Vasa, 2012 53

Android Project Structure

(convention) •Source code (src)

•Generated code (gen)

•Resources (res)

•Images (drawable)

•Layout of app (layout)

•Constants/Strings (values)

R. Vasa, 2012 54

Demo -- Hello World

•Create a ‘Hello World’ app.

•Quick overview of the IDE & Emulator

•Create + Run app. (in emulator)

•Change the font size (run again)

•Display “Hello, HIT3328 / HIT8328”

•Why do we have generated code?

R. Vasa, 2012 55

Lecture Review - Key points

•Understand the hardware and sensors

•Constraints are real -- must work within them


•Be paranoid about storing state


•Follow the pattern -- increase productivity