1 / 40

Mobile Application Development Framework

Mobile Application Development Framework. 4/16/2009 Richard Yang. Recap. What are the major considerations in developing a software environment and application framework for mobile wireless applications? Handle heterogeneous devices/configurations Efficient (memory, battery, …)

luigi
Download Presentation

Mobile Application Development Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Mobile Application Development Framework 4/16/2009 Richard Yang

  2. Recap • What are the major considerations in developing a software environment and application framework for mobile wireless applications? • Handle heterogeneous devices/configurations • Efficient (memory, battery, …) • Easy programming for event-driven programming • …

  3. Recap: TinyOS ADC.nc interface ADC { async command result_t getdata(); async command result_t getContinuousData(); event result_t dataReady(uint 16_t data); } • Software componentsprovide commands andrequire callback hooks • A configuration linkscomponents and uses only necessary components • Two threads • one for event • one for task configuration SenseTask { // this module does not provide any interfaces } implementation { components Main, SenseTaskM, LedsC, TimerC, DemoSensorC as Sensor; Main.StdControl -> TimerC; Main.StdControl -> Sensor; Main.StdControl -> SenseTaskM; SenseTaskM.Timer -> TimerC.Timer[unique("Timer")]; SenseTaskM.ADC -> Sensor; SenseTaskM.Leds -> LedsC; }

  4. Recap: J2ME/.NetCF • Scale down a popular programming environment to ease learning • Use virtual machines to mask device heterogeneity • Use versioning to handle configuration heterogeneity and avoid using lowest common denominator • Provide classes to support user-interface driven applications

  5. Application Framework (Android): Key Concepts • Activity • Visible screen for user interaction • Service • Background services • Content provider • Shared data • Service/Event discovery • Broadcast receivers: Receive and react to broadcast events • Intent and Intent Filter

  6. Andriod Features • Linux kernel as foundation • Java based framework (J2SE not J2ME) • Dalvik Virtual machine

  7. Andriod

  8. Activity (Visual User Interaction)

  9. Discussion: Key Issues in Designing Activity Support in Mobile Env. • Constrained display screen • Solution: specially simple display components • Need “smart” layout management • Event handling of UI • Lifecycle support • May need frequent resource (memory) release/acquisition • Fast switch between activities/screens • Frozen app. Management • Persistent state management

  10. MIDP: GUI • Implementations control the look and layout of screen components Title High-level Components Ticker tape (Optional; device manufacturer can place it at the top or bottom of the screen)

  11. MIDP: Visual Display Management • Display • the manager of the display and input devices • Each MIDP has one instance of Display • Display.getDisplay(this) to get the manager • At any instance of time at most one Displayable object can be shown on the display device and interact with user • display.setCurrent(<Displayable object>)

  12. MIDP: GUI • Lists • Text Boxes • Alerts • Forms • Form Items • Labels • Image Items • String Items • Text Fields • Date Fields • Gauges • Choice Groups • Similar to J2SE GUI but reduced

  13. MIDP: Visual Display • Displayable • Canvas • GameCanvas • Screen • Alert, List, TextBox, Form • Form can contain multiple form items for organization • Labels, Image Items, String Items, Text Fields, Date Fields, Gauges, Choice Groups

  14. MIDP: User Interaction • Displayable objects can declare commands and declare a command listener: • addCommand(Command cmd) • addCommandListener() • Command(<label>, <type>, <priority>) • Type: BACK, CANCEL, EXIT, HELP, ITEM, OK, SCREEN, and STOP

  15. Pause Active Destroyed MIDP: Lifecycle • MIDlets move from state to state in the lifecycle, as indicated • start – acquire resources and start executing • pause – release resources and become quiescent (wait) • destroy – release all resources, destroy threads, and end all activity pauseApp startApp destroyApp destroyApp

  16. Example • See HelloMIDlet.java

  17. Check on MIDP • Constrained display screen • Display components • Layout management • Event handling of UI • Lifecycle support • May need frequent resource (memory) release/acquisition • Fast switch between activities/screens • Frozen app. Management • Persistent state management

  18. MIDP: Persistent State • Record store defined in javax.microedition.rms • Record store identified by name: • recordStore = RecordStore.openRecordStore("scores", true); • recordId = addRecord(byte[] data, int offset, int numBytes); • getRecord(int recordId);

  19. Android Activity Life cycle

  20. Android Service Life Cycle • void onCreate() • void onStart(Intent intent) • void onDestroy()

  21. Android: Visual Display • Similar to J2SE • Interesting feature: using xml resources for GUI management

  22. Example see tablelayout.xml http://developer.android.com/guide/tutorials/views/hello-tablelayout.html

  23. Example: Calculator

  24. Check on Android • Constrained display screen • Display components • Layout management • Event handling of UI • Lifecycle support • May need frequent resource (memory) release/acquisition • Fast switch between activities/screens • Frozen app. Management • Persistent state management

  25. Persistent Data Storage • Preference • store and retrieve key-value pairs of primitive data types, e.g., font, greeting • See preference.java • File • SQL

  26. Inter-Activity Data Exchange

  27. MIDP • Uses Record Store • static String[] listRecordStores()

  28. Android: Content Provider • Each provider can expose its data as a simple table on a database model • Each content provider exposes a public URI that uniquely identifies its data set: • android.provider.Contacts.Phones.CONTENT_URI android.provider.Contacts.Photos.CONTENT_URI android.provider.CallLog.Calls.CONTENT_URI android.provider.Calendar.CONTENT_URI

  29. Android: Content Provider • See ContentProvider for query example

  30. Inter-Activity Service/Event Discovery

  31. Intent • <Component name> [optional] • Action • Data, e.g., mpeg • Category, e.g., browserable

  32. Intent • An Intent object is passed to Context.startActivity() or Activity.startActivityForResult() to launch an activity or get an existing activity to do something new. • An Intent object is passed to Context.startService() to initiate a service or deliver new instructions to an ongoing service. Similarly, an intent can be passed to Context.bindService() to establish a connection between the calling component and a target service. It can optionally initiate the service if it's not already running. • Intent objects passed to any of the broadcast methods (such as Context.sendBroadcast(), Context.sendOrderedBroadcast(), or Context.sendStickyBroadcast()) are delivered to all interested broadcast receivers. Many kinds of broadcasts originate in system code.

  33. Intent Resolution • Explicit intents: component identified • Implicit intents • System matches an intent object to the intent filters of others

  34. Intent filter action category data

  35. Android: Broadcast Receiver • Sending a broadcast: • Context.sendBroadcast(Intent intent, String receiverPermission) • Context.sendOrderedBroadcast() • Receiving broadcast: • Intent registerReceiver (BroadcastReceiver receiver, IntentFilter filter)

  36. Recap: Application Framework (Android) Key Concepts • Activity • Visible screen for user interaction • Service • Background service • Content provider • Shared data • Service/event discovery • Intent and Intent Filter: publish/subscription • Broadcast receivers: receive and react to broadcast events

  37. Intent • <Component name> [optional] • Action • Data, e.g., mpeg • Category, e.g., browserable

  38. Intent Resolution • Explicit intents: component identified • Implicit intents • System matches an intent object to the intent filters of others

  39. Example: Home Intent filter action category data

  40. Big Picture Applications Application Development Framework Foundational Primitives: Communications, Location, Service Discovery,UI/Media, Power Management, Security

More Related