1. Mobile Software Development Framework
2/21/2011
Y. Richard Yang

2. Admin. Class schedule Homework 2 due this Wednesday
Interleaving foundation with software framework?
Homework 2 due this Wednesday
Midterm: Wednesday after spring break

3. Big Picture Applications (Adaptation, and support for adaptations)
Application Development Framework
Foundational Primitives: Communications, Location, Service Discovery, UI/Media, Power Management, Security

4. Discussion
What are major considerations in designing a software environment for mobile wireless applications for mobile devices?

5. Mobile Programming Requirements
Handle heterogeneous devices/configurations
Be extremely efficiency on using resources (memory, battery, …)
Easy programming for event-driven programming …

6. Overview
Software framework for mobile applications is a quite large topic, we will see three representative examples
TinyOS
J2ME
Android

7. TinyOS

8. Hardware Assembled from off-the-shelf components
4Mhz, 8bit MCU (ATMEL)
512 bytes RAM, 8KB ROM
Devices
serial Port
temperature sensor & light sensor
900Mhz Radio (RF monolithics)
ft. range
LED outputs
1.5” x 1.5”

9. Schematic Diagram of a Mote

10. Sample Application: Environment Monitoring
Environment monitoring, e.g.,
measure temperature, lighting values/events
periodically transmit measurements/events to a base station
forward data for other nodes that are out of range of the base station …

11. Requirements on Software Dev. Framework
Flexible configuration of attached devices
Small foot print
devices have limited memory and power resources

12. TinyOS Application Dev. Framework
Basic principle: Generate customized OS + application for each given scenario
support one application at a time but flexible reprogramming
We say each generated scenario generates a tinyOS

13. Schematic Diagram

14. TinyOS: Software Components
A tinyOS consists of one or more components linked together
software components motivated by hardware component
Each component specifies that
it provides some interfaces
allows other components to control it
also uses some interfaces
control other components

15. A uses interfaces I1 and I2
An interface declares
a set of functions called commands that provider must implement
another set of functions called events that the interface user must implement
A uses interfaces I1 and I2 I1 I2
commands
events
commands
events
B provides I1
C provides I2
C provides I3

16. Interface: Examples Timer.nc ADC.nc
StdControl.nc interface StdControl {   command result_t init();   command result_t start();   command result_t stop(); }
Timer.nc
interface Timer {
command result_t start(
char type,
uint32_t interval);  
command result_t stop();  
event result_t fired(); }
ADC.nc
interface ADC {
async command result_t getdata();  
async command result_t getContinuousData();  
event result_t dataReady(uint 16_t data); }

17. TinyOS Component: Implementation
Component contains:
commands and event handlers
can invoke lower level commands, but cannot block
frame (storage)
statically allocated, fixed size to know memory requirement and avoid overhead of dynamic allocation
Component
Internal Tasks
Internal State
Commands
Events
event handler can signal higher level signals while command cannot

18. Linking Components Two types of components:
modules: individual components
configurations : assemble components together, connecting interfaces (objects) used by components to interfaces (objects) provided by others

19. Example Application
A simple TinyOS application which periodically reads in the light intensity value, computes a moving average, displays it on the LED
See SenseTaskM.nc SenseTask.nc

20. Running tinyOS Program
make mica
ncc -o main.exe -target=mica SenseTask.nc
avr-objcopy --output-target=srec main.exe main.srec
Use uisp to install

21. TinyOS Execution Model
Concurrency model: only two threads
long running tasks that can be interrupted by hardware event handlers
Tasks perform the primary computation work
commands and event handlers post tasks
call lower level commands
signal higher level events
schedule other tasks within a component
Each task is atomic with respect to other tasks
run to completion, but can be preempted by events
the task scheduler is a simple FIFO scheduler

22. A More Complete Sample Application
Sensor network monitoring
monitor temperature and light conditions
periodically transmit measurements to a base station
sensors can forward data for other sensors that are out of range of the base station
dynamically determine the correct routing topology for the network

23. Internal Component Graph
RFM
Radio byte
Radio Packet
UART
UART Packet
I2C
Temp
Light
Active Messages
Clocks
bit
byte
packet
Ad hoc Routing Application
application HW SW
Hardware abstraction components, like the RFM radio component, map physical hardware into our component model. They translate hardware interrupts into events, and export commands to manipulate the individual I/O pins of the hardware.
Synthetic hardware components simulate the behavior of advanced hardware. For example, the Radio Byte component shifts data into or out of the underlying RFM module, and signals when an entire byte has completed.
High level software components perform control, routing, and all data transformations.

24. Message Send Transition
Total propagation delay up the 5 layer radio communication stack is about 80 instructions
Timing diagram of event propagation

25. Evaluation: Storage Scheduler only occupies 178 bytes
Component Name
Code Size (bytes)
Data Size (bytes)
Routing
AM_dispatch
AM_temperature
AM_light AM
RADIO_packet
RADIO_byte
RFM
Light
Temp
UART
UART_packet
I2C 88 40 78
146
356
334
810
310 84 64
196
314
198 32 8 1
Processor_init
TinyOS scheduler
C runtime
172
178 82 30 16
Total
3450
226
Scheduler only occupies 178 bytes
Complete application only requires 3 KB of instruction memory and 226 bytes of data (less than 50% of the 512 bytes available)
Only processor_init, TinyOS scheduler, and C runtime are required

26. Evaluation: Timing Operations Cost (cycles) Time (µs)
Normalized to byte copy
Byte copy 8 2 1
Post an Event
Call a Command
Post a task to scheduler
Context switch overhead 10 46 51
2.5
11.5
12.75
1.25 6
Interrupt (hardware cost) 9
2.25
Interrupt (software cost) 71
17.75

27. Summary: TinyOS Efficiency and heter. configurations: Event driven
ADC.nc
interface ADC {
async command result_t getdata();  
async command result_t getContinuousData();  
event result_t dataReady(uint 16_t data); }
Efficiency and heter. configurations:
an app (configuration) at a time, linking only necessary components
two threads
one for event
one for task
Event driven
components provide commands and require callback hooks
Static linking
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;

28. Discussion
Can we use tinyOS for writing mobile applications for mobile phones, or in other words, what are missing?

29. Mobile Phone Apps. GUI support
Single application may not be realistic, but need tight application resource management
To handle frequent resource (memory) release/acquisition

30. Java2 Micro Edition (J2ME)

31. Java Platforms Java2 is divided into three platforms
J2EE (Java2 Enterprise Edition)
business applications
J2SE (Java2 Standard Edition)
general applications
J2ME (Java2 Micro Edition)
small devices such as mobile phone, PDA, car navigation

32. J2ME
Based on Java
Uses “versioning” to avoid using lowest common denominator
Uses java virtual machines to mask device heterogeneity

33. J2ME Versioning
To accommodate heterogeneous mobile devices, define configurations and profiles
A configuration provides fundamental services for a broad category of devices (e.g., lang, io, util)
A profile supports higher-level services common to a more specific class of devices or market (e.g., life cycle, GUI)
An optional package adds specialized services that are useful on devices of many kinds, but not necessary on all of them

34. J2ME
Upto 2M mem
32 bit proc
K mem
16-32 bit proc

35. Two Available J2ME Configurations
Connected Limited Device Configuration (CLDC)
160 KB to 512 KB of total memory available
16-bit or 32-bit processor
low power consumption and often operating with battery power
connectivity with limited bandwidth
examples: cell phones, certain PDAs
Connected Device Configuration (CDC)
2 MB or more memory for Java platform
32-bit processor
high bandwidth network connection, most often using TCP/IP
examples: set-top boxes, certain PDAs

36. CLDC Available Packages
java.lang
java.util
java.io
javax.microedition.io

37. CLDC Classes java.lang java.util java.io Boolean Byte
Character
Class
Integer
Long
Math
Object
Runnable
Runtime
Short
String
StringBuffer
System
Thread
Throwable
ByteArrayOutputStream
ByteArrayInputStream
DataOuput
DataInput
DataInputStream
DataOutputStream
InputStream
InputStreamReader
OutputStream
OutputStreamWriter
PrintStream
Reader
Writer
Calendar
Date
Enumeration
Hashtable
Random
Stack
TimeZone
Vector
java.lang
java.util
java.io

38. Available J2ME Profiles
Mobile Information Device Profile (MIDP)
GUI, multimedia and game functionality, end-to-end security, and greater networked connectivity
mobile phones and entry level PDAs
Foundation Profile
set of Java APIs that support resource-constrained devices without a standards-based GUI system
Personal Profile
Full set of AWT APIs, including support for applets and Xlets
CDC + Foundation Profile + Personal Profile for high-end PDA …

39. Mobile Phone Framework

40. MIDP Hardware Memory (added to CLDC memory) Display
128 KB non-volatile for MIDP components
8 KB non-volatile for application persistent data
32 KB volatile for KVM
Display
screen 96x54
display depth 1-bit
pixel shape (aspect ratio) 1:1

41. MIDP Hardware Input (one or more) Networking
one-handed keyboard (ITU-T phone keypad)
two-handed keyboard (QWERTY keyboard)
or touch screen
Networking
two-way
wireless
possibly intermittent
limited bandwidth

42. MIDP Packages addition in version 2.0 version 1.0
javax.microedition.lcdui.game
javax.microedition.media
javax.microedition.media.control
javax.microedition.pki
java.io
java.lang
java.util
javax.microedition.io
javax.microedition.lcdui
javax.microedition.rms
javax.microedition.midlet
version 1.0
addition in version 2.0

43. MIDP Technology Stack KVM
Mobile Information Device Profile
KVM
CLDC = KVM + J2ME Core APIs in this example
DSP chip (e.g., ARM)
J2ME core APIs
Your
MIDlet
Yellow Pages, train schedules and ticketing, games…
UI, HTTP networking...
Threads, no Floats…
32-bit RISC, 256K ROM, 256K Flash, 64K RAM

44. MIDP: Visual Display Management
An MIDP application is called a MIDlet
similar to the J2SE applet
GUI based
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>)

45. 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

46. 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

47. MIDP Life Cycle
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
pauseApp
startApp
Active
destroyApp
destroyApp
Destroyed

48. HelloWorldMIDlet.java import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class HelloWorldMIDlet extends MIDlet
implements CommandListener {
private Command exitCommand;
private Display display;
private TextBox t;
public HelloWorldMIDlet() {
display = Display.getDisplay(this);
exitCommand = new Command("Exit", Command.EXIT, 2);
t = new TextBox(“CS434", "Hello World!", 256, 0);
t.addCommand(exitCommand);
t.setCommandListener(this); }
public void startApp() { display.setCurrent(t); }
public void pauseApp() { }
public void destroyApp(boolean unconditional) { }
public void commandAction(Command c, Displayable s) {
if (c == exitCommand) {
destroyApp(false);
notifyDestroyed();

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

50. Summary : J2ME
Scale down a popular programming environment to ease learning
Use virtual machines to mask device heterogeneity
Use configuration/profiling to handle device heterogeneity and avoid using lowest common denominator
MIDLet and Displayable to support user-interface driven applications
MIDLet has life cycle
Displayable has commands and provides command listener
Introduce persistent record store

51. Windows .NET Compact Framework
Similar to J2ME
Scales down a popular programming environment to ease learning
the .NET CF is a subset of the full .NET framework with some additions
designed for resource constrained devices
1,400 classes for .NET CF vs. 8,000 for full
27 UI controls for .NET CF vs. 52 for full
1.5 MB for .NET CF vs. 30 MB for full
Uses versioning to avoid using lowest common denominator
pocket PC
pocket PC phone version
smart phone version
Uses virtual machines to mask device heterogeneity
programming languages compile to MSIL
MSIL is JIT compiled on the device
MSIL code is smaller than native executables
MSIL allows your code to be processor independent

52. Andriod

53. Android Features Linux kernel as foundation
Java based framework (J2SE not J2ME)
Dalvik Virtual machine
Nice features
Touch screen, accelerometer, compass, microphone, camera, GPS,
GSM, EDGE, and 3G networks, WiFi, Bluetooth, Near field communications
Media, SQLite, WebKit, SSL
Location-based service, map (Google API)

54. Which parts may Android adopt from J2ME?
Recall: J2ME
Scale down a popular programming environment to ease learning
Use virtual machines to mask device heterogeneity
Use configuration/profile to handle device heterogeneity to avoid using lowest common denominator
MIDLet and Displayable to support user-interface driven applications
MIDLet manages app life cycle
Displayable has commands and provides command listener
Introduce persistent record store
Which parts may Android adopt from J2ME?

55. Activity A single, focused thing that the user can do.
Interaction with users: creating a window to place UI views
full-screen windows, floating windows, embedded inside of another activity

56. Android Activity Life cycle

57. View
A view component is a building block for user interface components.
Widget Toolbox
TextView, EditText, Button, Form, TimePicker…
ListView
Layout
Positions of controls
LinearLayout, Relativelayout