1 / 53

Mobile Software Development Framework

Mobile Software Development Framework. 4/14/2009 Richard Yang. Admin. Homework 4. Recap. What are the major considerations in developing a software environment and application framework for mobile wireless applications? Handle heterogeneous devices/configurations

iona
Télécharger la présentation

Mobile Software Development Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Mobile Software Development Framework 4/14/2009 Richard Yang

  2. Admin. • Homework 4

  3. 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 • …

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

  5. TinyOS http://www.tinyos.net/tinyos-1.x/doc/tutorial/

  6. 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) • 10-100 ft. range • LED outputs 1.5” x 1.5”

  7. Schematic Diagram of a Mote

  8. 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 • …

  9. Requirements on Software Dev. Framework • Small foot print • devices have limited memory and power resources • Support one application at a time but flexible reprogramming • Flexible configuration of attached devices

  10. TinyOS Application Dev. Framework • Basic principle: Generate customized OS + application for each given scenario • We say each generated scenario generates a tinyOS

  11. Schematic Diagram

  12. TinyOS: Software Components • A tinyOS consists of one or more componentslinked 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

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

  14. Interface: Examples StdControl.ncinterface StdControl {  command result_t init();  command result_t start();  command result_t stop();} Timer.nc interface Timer { command result_t start( chartype, 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); }

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

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

  17. Example Application • A simpleTinyOS application which periodically reads in the light intensity value, computes a moving average, displays it on the LED See SenseTaskM.ncSenseTask.nc

  18. TinyOS Execution Model • Concurrency model: only two threads • long running tasksthat 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

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

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

  21. Ad hoc Routing Application application Active Messages packet UART Packet Temp Radio Packet SW byte HW UART Radio byte I2C Light bit Clocks RFM Internal Component Graph

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

  23. Evaluation: Storage • 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

  24. Evaluation: Timing

  25. Discussion • What would we need to extend to tinyOS if we were to use it for writing mobile applications for mobile phones and PDAs?

  26. Java2 Micro Edition (J2ME)

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

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

  29. 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 http://developers.sun.com/techtopics/mobility/getstart/articles/survey/

  30. J2ME 128-512K mem 16-32 bit proc Upto 2M mem 32 bit proc

  31. 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 • many Java features deleted, e.g., floating point, finalize • 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

  32. Available J2ME Profiles • Mobile Information Device Profile (MIDP) • delivers an enhanced user interface, multimedia and game functionality, end-to-end security, and greater networked connectivity to 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 • Together with CDC and Foundation Profile, Personal Profile provides a complete application environment for the high-end PDA market. Personal Profile contains the full set of AWT APIs, including support for applets and Xlets • Personal Basis Profile • provides a J2ME application environment for network-connected devices supporting a basic level of graphical presentation

  33. Mobile Phone Framework

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

  35. CLDC Available Packages • java.lang • java.util • java.io • javax.microedition.io

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

  37. Networking Connection • Based on a framework called the Generic Connection Framework (GCF) • GCF consists of • an interface hierarchy that is extensible • a connection factory, and • uses Standard Uniform Resource Locators (URLs) to indicate the connection types to create • scheme://user:password@host:port/url-path;parameters • e.g.socket://www.j2medeveloper.com:80file:///myResourceFile.resdatagram://www.j2medeveloper.com:7001sms://+12034326400 http://developers.sun.com/techtopics/mobility/midp/articles/genericframework/

  38. MIDP Hardware • Memory (added to CLDC memory) • 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

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

  40. MIDP Packages • 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 addition in version 2.0 version 1.0

  41. MIDP Application Model • An MIDP application is called a MIDlet • similar to the J2SE applet • GUI based • MIDlet suites – for applications that share resources or data

  42. Pause Active Destroyed MIDP: Application 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

  43. 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(); } } }

  44. Developing J2ME Applications • Identify the devices • Identify the profiles supported by devices • using the MID profile, the application will target cell phones and pagers • Develop application • install jdk, a package supporting the wireless target (e.g., Sun Wireless Toolkit for CLDC) • debug using a simulator • for deployment, preverify by pre-generating “stack map”

  45. Deploying: Two-Phase Class File Verification Process Stack map attribute increases the size of a classfile by appro. 5% but substantially reduces device mem and CPU usage

  46. Deploying • Generate deployment files: two files • Java Application Description file (.jad) • Java archive file (.jar) • Upload .jad and .jar to the device or a server where the device can download the application

  47. Advertise App on Web Page User Selects App JAM Downloads App Web Page (Name, Version, Size, …) Java Application Manager Descriptor File Network Transfer Jar File Over-The-Air Application Loading Process

  48. Summary: J2ME • Scale down a popular programming environment to ease learning • Use virtual machines to mask (some) device heterogeneity • Use versioning to avoid using lowest common denominator

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

  50. Andriod

More Related