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 …

Recap: TinyOS

Software componentsprovide commands andrequire callback hooks

A configuration linkscomponents and uses only necessary components

Two threads one for event 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

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

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

5

Andriod Features

Linux kernel as foundation

Java based framework (J2SE not J2ME)

Dalvik Virtual machine

6

Andriod

7

Activity (Visual User Interaction)

8

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

9

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)

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>)

11

12

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

MIDP: GUI

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

13

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

14

15

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

Pause

Active

Destroyed

startApp

destroyApp

pauseApp

destroyApp

Example

See HelloMIDlet.java

16

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

17

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);

18

Android Activity Life cycle

19

Android Service Life Cycle

void onCreate()

void onStart(Intent intent)

void onDestroy()

20

Android: Visual Display

Similar to J2SE

Interesting feature: using xml resources for GUI management

21

Example

22

http://developer.android.com/guide/tutorials/views/hello-

tablelayout.html

see tablelayout.xml

Example: Calculator

23

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

24

Persistent Data Storage

Preference store and retrieve key-value pairs of primitive

data types, e.g., font, greeting See preference.java

File

SQL

25

Inter-Activity Data Exchange

26

MIDP

Uses Record Store static String[] listRecordStores()

27

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

28

Android: Content Provider

29

See ContentProvider for query example

Inter-Activity Service/Event Discovery

30

Intent

<Component name> [optional] Action

Data, e.g., mpeg Category, e.g., browserable

31

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.

32

Intent Resolution

Explicit intents: component identified

Implicit intents System matches an intent object to the intent

filters of others

33

Intent filter

34

action

category

data

Android: Broadcast Receiver

Sending a broadcast: Context.sendBroadcast(Intent intent, String receiverPermission)

Context.sendOrderedBroadcast()

Receiving broadcast: Intent registerReceiver (BroadcastReceiver receiver, IntentFilter filter)

35

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

36

Intent

<Component name> [optional] Action

Data, e.g., mpeg Category, e.g., browserable

37

Intent Resolution

Explicit intents: component identified

Implicit intents 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