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

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

Recap: TinyOS r Software components provide commands and require callback hooks r A configuration links components and uses only necessary components r Two threads m one for event m one for task 3 ADC.nc interface ADC { async command result_t getdata(); async command result_t getContinuousData(); event result_t dataReady(uint 16_t data); } 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 r Scale down a popular programming environment to ease learning r Use virtual machines to mask device heterogeneity r Use versioning to handle configuration heterogeneity and avoid using lowest common denominator r Provide classes to support user- interface driven applications

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

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

Andriod 7

Activity (Visual User Interaction) 8

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

10 MIDP: GUI r 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)

MIDP: Visual Display Management  Display m the manager of the display and input devices m 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( ) 11

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

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

MIDP: User Interaction  Displayable objects can declare commands and declare a command listener: m addCommand(Command cmd) m addCommandListener() r Command(,, ) m Type: BACK, CANCEL, EXIT, HELP, ITEM, OK, SCREEN, and STOP 14

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

Example r See HelloMIDlet.java 16

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

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

r Android Activity Life cycle 19

Android Service Life Cycle r void onCreate() r void onStart(In tent intent) r void onDestroy( ) 20

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

Example 22 de/tutorials/views/hello- tablelayout.html see tablelayout.xml

Example: Calculator 23

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

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

Inter-Activity Data Exchange 26

MIDP r Uses Record Store m static String[] listRecordStores() 27

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

Android: Content Provider 29 r See ContentProvider for query example

Inter-Activity Service/Event Discovery 30

Intent r [optional] r Action r Data, e.g., mpeg r Category, e.g., browserable 31

Intent r An Intent object is passed to Context.startActivity() or Activity.startActivityForResult() to launch an activity or get an existing activity to do something new.Context.startActivity() Activity.startActivityForResult() r 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.Context.startService()Context.bindService() r 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. Context.sendBroadcast()Context.sendOrderedBroadcast() Context.sendStickyBroadcast() 32

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

Intent filter 34 action category data

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

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

Intent r [optional] r Action r Data, e.g., mpeg r Category, e.g., browserable 37

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

Intent filter 39 action category data Example: Home

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