Your SlideShare is downloading. ×
HIT3328 - Chapter01 - Platforms and Devices
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

HIT3328 - Chapter01 - Platforms and Devices

83
views

Published on

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
83
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. HIT3328 / HIT8328 Software Development for MobileDevicesDr. Rajesh Vasa, 20121Lecture 01Platforms andDevicesImage Source: Google
  • 2. R. Vasa, 20122Lecture Overview•Eco Systems and Development Journey•Smartphone - Hardware Overview•Hardware Constraints (Dev. perspective)•Mobile Operating Systems•Convention Over Configuration
  • 3. R. Vasa, 20123Mobile EcosystemAdNetworksPlatformContent Providers(Music/Video/Books)HandsetOEMsTelephoneNetworksApp.DistributionCloudInfrastructureBilling
  • 4. R. Vasa, 20124Mobile Ecosystem - Android**Google, Double ClickGoogle, AmazonSamsung, HTC, Motorola, Sony ...PlatformCloudInfrastructureAdNetworksContent Providers(Music/Video/Books)Handset(OEMs)TelephoneNetworksApp.DistributionBillingGoogle CheckoutAndroidGoogle, Amazon
  • 5. R. Vasa, 20125Mobile Ecosystem - AppleiTunesiAdAdNetworksPlatformContent Providers(Music/Video/Books)iPhone/iPad/iPodTelephoneNetworksApp.DistributionCloudInfrastructureBillingApp StoreiTunes + App. StoreDropbox, GoogleiOS
  • 6. R. Vasa, 20126Lecture 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, 20127App. Development Journey•Application Planning•Platform / Library Selection•Develop and Test•Prepare for Market and Deploy•Monetization•Analytics, Support and UpdateManagementPlanning Platform Prep Develop & Test Deploy Monetize Support> > > > >
  • 8. R. Vasa, 20128App. 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, 20129App. Development Journey•Platform Preparation•Identifying appropriate platform•Selection of libraries and tools (increaseproductivity)•Development methodology•Gap identification and learning plan•Working with development communityPlanning Platform Prep Develop & Test Deploy Monetize Support> > > > >
  • 10. R. Vasa, 201210App. 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 servicesPlanning Platform Prep Develop & Test Deploy Monetize Support> > > > >
  • 11. R. Vasa, 201211App. Development Journey•Deployment•Packaging and Signing•Certification and Approval process•Beta testing (Sandbox-ed networks)•Localization•Packaging and Managing versions•Technical support frameworksPlanning Platform Prep Develop & Test Deploy Monetize Support> > > > >
  • 12. R. Vasa, 201212App. Development Journey•Monetization•Distribution methods and channels•Tools to aid promotion•Ad. networks•Billing and Settlement (in-app selling)•Application usage profilingPlanning Platform Prep Develop & Test Deploy Monetize Support> > > > >
  • 13. R. Vasa, 201213App. Development Journey•Support and Tracking•Analytics (tracking usage)•User ratings, support•Managing application upgrades /updates•Privacy managementPlanning Platform Prep Develop & Test Deploy Monetize Support> > > > >
  • 14. R. Vasa, 201214Lecture 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, 201215Typical 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, 201216Sensors 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, 201217Location Detection•Location detection is possible at fine or coarselevel using:•GPS (fine -- to few meters)•Cell grid triangulation (to 100 meters)•IP network location (Suburb / City)
  • 18. R. Vasa, 201218Touch 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 humanfinger) -- capacitance change•Ideal for gesture / multi-touch UI
  • 19. R. Vasa, 201219CPU / 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, 201220Networking•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, thenyou can download a 1 Mega Byte file in 10seconds. (Mbps is megabit per sec)
  • 21. R. Vasa, 201221Battery 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 (butdisplay is the largest consumer of power)
  • 22. R. Vasa, 201222Where 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% ofthe battery power.•Note: The above is based on an average user
  • 23. R. Vasa, 201223Memory•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, 201224Display 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 (goldilockswidth for human hands)•Height often between 2 - 4.5 inches
  • 25. R. Vasa, 201225Lecture 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, 201226Next Generation Displays•Most widely used are medium density andhigh-density (320x480 @ 160 dpi and 480 x800 @ 240 dpi )•iPhone4 is ~ 320 dpi (more pixels per inch)Image Source: Gizmodo
  • 27. R. Vasa, 201227What 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 erraticspeeds•Be aware that the phone may/will/can ring•Display size, DPI & processor speed arevariable
  • 28. R. Vasa, 201228More 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 notidentical across devices (even iPhone has 3generations in wide-spread use)•Can work with a range of memory, cpu, andGPU capabilities
  • 29. R. Vasa, 201229Biggest 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 managethis•When the phone call ends,•The O/S will try to bring your app. back intothe foreground (but not guaranteed)
  • 30. R. Vasa, 201230Time for distraction...• Guess how much effort went into the design andconstruction of the core font (Droid Font) for theAndroid platform?• This was followed by even more work on the newRoboto Font.
  • 31. R. Vasa, 201231Short Problem 1•Scenario:•You are developing a “Stopwatch + Count Downtimer” App.•Use case: The user has set the count downtimer for 2 minutes -- pressed “start”. After 45seconds, phone rings•What is the behaviour of your app. when thephone rings?
  • 32. R. Vasa, 201232Short Problem 2•Scenario: You developed an app that “needs”to download ~ 30MB of data daily (Commonfor newspaper apps)•How long will it take on,•Home broadband/WiFi (3 Mbps), 3G (1.5Mbps), GPRS (48 Kbps)•Design choices will you make in terms of,•How data is downloaded? Protocols supported?Dealing with dropped connections?
  • 33. R. Vasa, 201233Short Problem 3•Scenario: You are planning to develop an app.that will show the weather forecast for aparticular location. You want to use the GPS toobtain the location.•However, obtaining an initial GPS lock takestime (30 seconds -- 2 minutes)•Do you think it is reasonable to ask the userto wait a couple of minutes to get the location?If not, what will you do different?
  • 34. R. Vasa, 201234Short Problem 4•Scenario: Weather App.•Phone (at home) has not been used for around30 minutes.•User wants to check the weather.•The app. opens a network connection --downloads the weather information.•The app takes about 60 - 90 seconds todownload weather data. Why is it taking solong? Is this a reasonable delay?
  • 35. R. Vasa, 201235Lecture 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, 201236Mobile 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, 201237Mobile Operating Systems•Very different to how PC operating systemsare designed•The life cycle of an application is very tightlycontrolled 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, butaggressively de-allocates it•If a view/image is not in theforeground/running -- then it will be destroyed
  • 38. R. Vasa, 201238Mobile Op. Systems are e-VIL?•If you request a network connection -- buthave 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 fewmin.) then the memory allocated to app. is de-allocated.•O/S (thankfully) provide a short warning andyou have options to save data.
  • 39. R. Vasa, 201239Android App Life CycleKey feature ofa Mobile O/SRemember: ~ 256MB onlyavailable in RAMImage Source:http://developer.android.com39
  • 40. R. Vasa, 201240iOS Application Life Cycle (is similar)•Memory management is different in iOScompared to Android•iOS will still,•Terminate apps. if memory needed (test foryourself -- load few large games on an iPhone)•Send an app. into background if Phone rings•Flush caches (used by images mainly) atregular intervals to free resources
  • 41. R. Vasa, 201241States 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 RAMused is generally purged
  • 42. R. Vasa, 201242Short Problem 5•Consider this hypothetical situation,•Each time you minimise the IDE on your laptopcomputer, the O/S will suspend the applicationfor 15 minutes -- then terminates theapplication.•If you were developing the IDE -- and want tooffer a reasonable user experience on this OS -- what can you do?
  • 43. R. Vasa, 201243Mobile File Systems•Designed to work with Flash memory•Flash memory is designed for max. 10k writes•File system is optimised to ensure that thesame 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, 201244Short Problem 6•You have created a new “app” for the Androidplatform --•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 aweather app.?
  • 45. R. Vasa, 201245When 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, 201246Lecture 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, 201247Convention Over Configuration•Software design paradigm•Aims to reduce decisions developers make•Why is this needed?•When we build software, there is a lot ofroutine and repetitive decision making•By following a certain development style, wereduce the decisions we need to make•What do we lose? -- Some flexibility, anddevelopers have to accept the convention
  • 48. R. Vasa, 201248Example ....•Software systems often make use of a largenumber 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 tomodules?)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, 201249Decision making process..•In order to make a decision,•Options must be identified (takes effort)•Options must be ranked (opinions and ideas ofdifferent 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, 201250Coding 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, 201251Coding 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 typesof images•e.g. Icons will be named with ic_ prefix.•We improve productivity -- in terms of reduceddecision making
  • 52. R. Vasa, 201252Why does this matter?•Android prefers and dictates “convention”•However,•You can ignore the convention and fallback toconfiguration•Benefits of convention,•Productivity improvement•Improve team coordination•Reduces unnecessary stress•iOS development has its own conventions!
  • 53. R. Vasa, 201253Android Project Structure(convention)•Source code (src)•Generated code (gen)•Resources (res)•Images (drawable)•Layout of app (layout)•Constants/Strings (values)
  • 54. R. Vasa, 201254Demo -- 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, 201255Lecture 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