Download - 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 …
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