Mobile Application Development Framework

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