1. HIT3328 / HIT8328 Software Development for Mobile
Devices
Dr. Rajesh Vasa, 2012
1
Lecture 01
Platforms and
Devices
Image Source: Google

2. R. Vasa, 20122
Lecture Overview
•Eco Systems and Development Journey
•Smartphone - Hardware Overview
•Hardware Constraints (Dev. perspective)
•Mobile Operating Systems
•Convention Over Configuration

3. R. Vasa, 20123
Mobile Ecosystem
Ad
Networks
Platform
Content Providers
(Music/Video/Books)
Handset
OEMs
Telephone
Networks
App.
Distribution
Cloud
Infrastructu
re
Billing

4. R. Vasa, 20124
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

5. R. Vasa, 20125
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

6. R. Vasa, 20126
Lecture Overview - Where are we?
•Eco Systems and Development Journey
•Smartphone - Hardware Overview
•Hardware Constraints (Dev. perspective)
•Mobile Operating Systems
•Convention Over Configuration

7. R. Vasa, 20127
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> > > > >

8. R. Vasa, 20128
App. Development Journey
•Planning
•User identification
•Concept / Prototype design
•Market research (focus groups)
•Requirements documentation
•[Business case / Budget]
Planning Platform Prep Develop & Test Deploy Monetize Support> > > > >

9. R. Vasa, 20129
App. Development Journey
•Platform Preparation
•Identifying appropriate platform
•Selection of libraries and tools (increase
productivity)
•Development methodology
•Gap identification and learning plan
•Working with development community
Planning Platform Prep Develop & Test Deploy Monetize Support> > > > >

10. R. Vasa, 201210
App. Development Journey
•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
Planning Platform Prep Develop & Test Deploy Monetize Support> > > > >

11. R. Vasa, 201211
App. Development Journey
•Deployment
•Packaging and Signing
•Certification and Approval process
•Beta testing (Sandbox-ed networks)
•Localization
•Packaging and Managing versions
•Technical support frameworks
Planning Platform Prep Develop & Test Deploy Monetize Support> > > > >

12. R. Vasa, 201212
App. Development Journey
•Monetization
•Distribution methods and channels
•Tools to aid promotion
•Ad. networks
•Billing and Settlement (in-app selling)
•Application usage profiling
Planning Platform Prep Develop & Test Deploy Monetize Support> > > > >

13. R. Vasa, 201213
App. Development Journey
•Support and Tracking
•Analytics (tracking usage)
•User ratings, support
•Managing application upgrades /
updates
•Privacy management
Planning Platform Prep Develop & Test Deploy Monetize Support> > > > >

14. R. Vasa, 201214
Lecture Overview - Where are we?
•Eco Systems and Development Journey
•Smartphone - Hardware Overview
•Hardware Constraints (Dev. perspective)
•Mobile Operating Systems
•Convention Over Configuration

15. R. Vasa, 201215
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)

16. R. Vasa, 201216
Sensors and Actuators
•Magnetometer
•Accelerometer/Gyro
•Temperature (and humidity) sensors
•Proximity / Light sensors
•Vibrator and Haptic feedback
•Camera (Front and Back) + Flash
•Vibrate motor

17. R. Vasa, 201217
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)

18. R. Vasa, 201218
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

19. R. Vasa, 201219
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

20. R. Vasa, 201220
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)

21. R. Vasa, 201221
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)

22. R. Vasa, 201222
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

23. R. Vasa, 201223
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

24. R. Vasa, 201224
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

25. R. Vasa, 201225
Lecture Overview - Where are we?
•Eco Systems and Development Journey
•Smartphone - Hardware Overview
•Hardware Constraints (Dev. perspective)
•Mobile Operating Systems
•Convention Over Configuration

26. R. Vasa, 201226
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

27. R. Vasa, 201227
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

28. R. Vasa, 201228
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

29. R. Vasa, 201229
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)

30. R. Vasa, 201230
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.

31. R. Vasa, 201231
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?

32. R. Vasa, 201232
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?

33. R. Vasa, 201233
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?

34. R. Vasa, 201234
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?

35. R. Vasa, 201235
Lecture Overview - Where are we?
•Eco Systems and Development Journey
•Smartphone - Hardware Overview
•Hardware Constraints (Dev. perspective)
•Mobile Operating Systems
•Convention Over Configuration

36. R. Vasa, 201236
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

37. R. Vasa, 201237
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

38. R. Vasa, 201238
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.

39. R. Vasa, 201239
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

40. R. Vasa, 201240
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

41. R. Vasa, 201241
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

42. R. Vasa, 201242
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?

43. R. Vasa, 201243
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

44. R. Vasa, 201244
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.?

45. R. Vasa, 201245
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

46. R. Vasa, 201246
Lecture Overview - Where are we?
•Eco Systems and Development Journey
•Smartphone - Hardware Overview
•Hardware Constraints (Dev. perspective)
•Mobile Operating Systems
•Convention Over Configuration

47. R. Vasa, 201247
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

48. R. Vasa, 201248
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?

49. R. Vasa, 201249
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

50. R. Vasa, 201250
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

51. R. Vasa, 201251
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

52. R. Vasa, 201252
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!

53. R. Vasa, 201253
Android Project Structure
(convention)
•Source code (src)
•Generated code (gen)
•Resources (res)
•Images (drawable)
•Layout of app (layout)
•Constants/Strings (values)

54. R. Vasa, 201254
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?

55. R. Vasa, 201255
Lecture Review - Key points
•Understand the hardware and sensors
•Constraints are real -- must work within them
•Mobile Operating Systems
•Be paranoid about storing state
•Convention Over Configuration
•Follow the pattern -- increase productivity