5. More on app development

515
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
515
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

5. More on app development

  1. 1. 5. More on app development Mobile Java (MIDP in particular) • Most importantly an add-on to proprietary phone • Some other mobile development systems OS based systems – MIDP Java – Huge device space that is already deployed – Maemo – No need to modify the already existing prorietary – Android platform but simple wrapping is enough! – iPhone • Disclaimer: Full Java software stacks exist; – Windows Mobile – RIM & Blackberry – OpenMoko – JavaFX Mobile (earlier SavaJe) • Commonly used implementation techniques – (Google Android --- at least kind of!) • Summary Building Mobile Java Infrastructure Building Mobile Java Infrastructure Simplified facilities Standard-featured Java VM Reduced memory footprint Reduced memory footprint KVM Mobile Standard-featured HotSpot VM VM Hosting operating system Hosting operating system - Access to hardware - Access to hardware Building Mobile Java Infrastructure Building Mobile Java Infrastructure Connected Limited Device Configuration Connected Device Application development facilities - No floating point support (v.1.0) Configuration - Simplified security scheme Personal profile - Standard facilities - No user-defined class loaders MIDP IMP - No finalize, thread groups, reflection, or JNI Personal basis profile - Also other simplifications Foundation profile CLDC CDC CLDC CDC KVM Mobile Standard-featured KVM Mobile Standard-featured HotSpot VM VM HotSpot VM VM Hosting operating system Hosting operating system - Access to hardware - Access to hardware
  2. 2. Midlet (MIDP) Development Process Development workstation Target device constructor (KVM runtime) MyApp.java download Paused destroyApp javac startApp pauseApp Destroyed runtime verifier MyApp.class Active destroyApp preverifier interpreter MyApp.class Sample Midlet Midlet Implementation • Extend class midlet • Implement methods – Constructor – startApp – destroyapp – pauseapp • Usually some way of interaction for the user required as well – E.g. CommandListener interface Behavior Code... start command pick display give import javax.microedition.midlet.*; user Statement Info import javax.microedition.lcdui.*; App Action Statement public class PersonalityTest extends MIDlet implements CommandListener { private Command positive, negative, exitCommand; /** Yes, No, Exit */ private TextBox tb; private int nth, count = 0; /** Counter for statement and answer pair. */ private String Questions[] = /** Questions */ { "The weapon of the brave is in his heart.", "A man is a lion for his own cause.", "Courage leads to the stars, fear toward death.", "Faced with crisis, the man of character falls back upon himself.", "It is not the oath that makes us believe the man, but the man the oath.", "Whoever is careless with the truth in small matters cannot "+ "be trusted with the important matters.", "No great thing is created suddenly." }; private int Qlen = Questions.length;
  3. 3. Code… Code… public PersonalityTest() { protected void destroyApp(boolean u) {} exitCommand = new Command("EXIT", Command.EXIT, 1); protected void pauseApp() {} negative = new Command("NO", Command.CANCEL, 2); positive = new Command("YES", Command.OK, 2); private void pickStatement() { } if (nth == Qlen) { giveInfo(); } protected void startApp() { else { pickStatement(); displayStatement(Questions[nth]); } nth = nth + 1; public void commandAction(Command c, Displayable d) { } if (c == exitCommand) { } destroyApp(false); private void displayStatement(String statement) { notifyDestroyed(); tb = new TextBox("Statement Selection", statement, 256, 0); } else { if (c == positive) { count++; } tb.addCommand(positive); else {count--;} tb.addCommand(negative); } tb.setCommandListener(this); pickStatement(); } Display.getDisplay(this).setCurrent(tb); } Code… JAD/Midlet suite manifest private void giveInfo() { if (count > 1) { tb = new TextBox("PersonalityTest", "You seem to be an overly positive MIDlet-1: PersonalityTest, PersonalityTest.png, PersonalityTest person.", 50, 0); } else if (count < -1) { MIDlet-Name: PersonalityTest tb = new TextBox("Personalitytest", "You appear as a gravely negative MIDlet-Vendor: Unknown person.", 50, 0); } else { MIDlet-Version: 1.0 tb = new TextBox("Personalitytest", "You seem to have difficulties in being MicroEdition-Configuration: CLDC-1.0 in line with yourself.", 80, 0); } MicroEdition-Profile: MIDP-2.0 tb.addCommand(exitCommand); tb.setCommandListener(this); Display.getDisplay(this).setCurrent(tb); } } // class PersonalityTest MIDlet execution environment MIDlet execution environment • Classes and native code that implement CLDC and MIDP getResorceAsStream() MIDlet 1 MIDlet 2 – Only shared name space for all MIDlet suites in early non-class access versions including JAR manifest – Later systems introduce more advanced facilities • Classes within MIDlet suite’s JAR file JAR File • All non-class files in the MIDlet’s suite’s JAR file RMS – Icons, images, JAR manifest getResorceAsStream() non-class access – Accessible with java.lang.Class.getResourceAsStream including JAR manifest • Contents of Application Descriptor File (Appl. descriptor file) RMS1 – Accessible with java.lang.Class.getResourceAsStream • Separate name space for RMS record stores RMS2
  4. 4. MIDP 1.0 libraries and interfaces UI class hierarchy (MIDP 1.0) D is p la y C anvas A le rt S trin g Item • UI – Different device specific wrapping for widgets L is t Im a g e Ite m • Canvas: Low-level interface; control for programmer 0 ..1 • Screen: Device specific widgets; control for the widgets and library; D is p la ya b le S creen navigation, scrolling etc. built in T e x tB o x T e x tF ie ld – Different screen capabilities (e.g. screen, color, ...) – Different input mechanisms (keyboard, touch screen, ...) • Networking interface F o rm D a te F ie ld – Originally http focused, no link to final implementation-level protocol; later improved considerably • Persistence 0 ..1 G au g e – RMS, record management system Ite m • Reflects a simple, record-oriented database • Records interfaced with byte arrays C h o ic e G ro u p Other screen-related issues Networking Interface • Originally http focused (MIDP 1.0) with multiple carriers (e.g. TCP/IP, • Game API (MIDP 2.0) WAP, i-Mode) – Sprites, layering, etc. • Numerous networking extensions and improvements – Enables native implementation – HTTPS, SSL – Serial port • GUI enhancements – Sockets – Builds on MIDP 1.0 LCDUI – Server Sockets – Custom items, layout control, graphical enhancements... – Datagrams – Backward compatibility – Network push feature • Network initiated MIDlet launch • Further enhancements provided in later JSRs for e.g. • OTA (over the air) applications – Multimedia – Installation – 3D • Verify integrity, certificates, requested permissions – Invocation • Permissions – Originally extension, later required Persistence Other services • Based on Record Management System – Records contained by record stores • Timers • RMS sharing obeys MIDlet suite class myTask extends TimerTask { principle public void run() { ... } – Same name can be used for different } RMS record stores in different MIDlet RecordId = 1 myTimer = new Timer(); suites myTask = new myTask(); – Later relaxed RecordId = 7 myTimer.schedule(myTask, 100, 1000); • Programmer (or device manufacturer) RecordId = 3 • Access to resource files (getResourceAsStream) handles mutual exclusion – listRecordStores, openRecordStore, RecordStore getName, getSize, addRecord, • System properties (java.lang.System.GetProperty) deleteRecord,... – microedition.platform (name of the device) – DataInputStream, DataOutputstream, – microedition.encoding (character encoding) ByteArrayInputStream, – microedition.configuration (used configuration and its version) ByteArrayOutputStream – microedition.profiles (used profile and its version) – microedition.locale (language and country)
  5. 5. Further interfaces Further interfaces • JSR-177: Security and Trust Services for J2MET • JSR-120: Wireless Messaging API – Necessary step for a device to become trusted, i.e., to provide – Short Message Service (SMS) security mechanisms to support a wide variety of application-based – Unstructured Supplementary Service Data (USSD) services, such as access to corporate network,mobile commerce, – Cell Broadcast Service (CBS) and digital rights management • JSR-135: Mobile Media API – Model and a set of APIs that enable applications running on a – Straightforward access and control of basic audio and multimedia J2ME device to communicate with a smartcard resources and files • JSR-179: Location API for J2MET • JSR-172: J2MET Web Services Specification – Optional package that enables developers to write mobile, location- – Infrastructure for basic XML processing capabilities based applications for J2ME devices – Reuse of web service concepts when designing J2ME clients for • JSR-180: Session Initiation Protocol (SIP) for J2MET enterprise services – Session Initiation Protocol (SIP) is used to establish and manage – Provides APIs and conventions for programming J2ME clients of multimedia IP sessions enterprise services – General SIP API for J2ME devices based on the SIP protocol – Programming model for J2ME client communication with web defined by IETF and 3GPP, and targeting resource constrained services, consistent with that for other Java clients such as J2SE. platforms. Further interfaces Some fundamental specifications • JSR-184: Mobile 3D Graphics for J2MET • JSR-68: J2MET Platform Specification – Defines the"ground rules" for the J2ME platform architecture and – Lightweight, interactive 3D graphics API, which sits J2MEstandardization activities. alongside J2ME and MIDP as an optional package. – Formalizes the fundamental concepts behind J2ME, such as the – API targeted at devices that typically have very little notions of a configuration and profile processing power and memory, and no hardware support for – Defines how new J2ME APIs can be formed, e.g., by subsetting 3D graphics or floating point math existingAPIs from Java 2 Platform, Standard Edition • JSR-185: JavaT Technology for Wireless Industry • JSR-190: Event Tracking API for J2MET – Defines how various technologies associated with MIDP work – Optional package that standardizes the tracking of together to form a complete handset solution for the wireless application events in a mobile device services industry – Submission of these event records to an event-tracking – Which optional packages fit with which profiles? How an end-to-end solution for interoperable Java applications will work? How the server via a standard protocol migration of applications can occur and to which profiles as the • JSR-195: Information Module Profile devices become more capable? – Like MIDP but no screen or keyboard 5. More on app development Maemo • Nokia Internet Tablet • Based on Debian Linux • Some other mobile development systems distribution and package – MIDP Java management – Maemo • Development – Android environment based on Scratchbox virtualization – iPhone system – Windows Mobile • Pretty much everything – OpenMoko can be programmatically accessed • Commonly used implementation techniques • C, C++, Python, • Summary JavaScript
  6. 6. Maemo application: The Concept Maemo application: The code (http://maemo.org/development/training/maemo_technology_overview_content/ ) int main(int argc, char** argv) { ApplicationState aState = {}; osso_context_t* ctx = NULL; gtk_init(&argc, &argv); // Initialization begins aState.program = HILDON_PROGRAM(hildon_program_get_instance()); aState.window = HILDON_WINDOW(hildon_window_new()); hildon_program_add_window(aState.program, HILDON_WINDOW(aState.window)); ctx = osso_initialize(..... /* parameters omitted */ ); … // Event handler definitions g_signal_connect(G_OBJECT(aState.window), "key_press_event", G_CALLBACK(cbKeyPressed), &aState); … gtk_main(); // Event processing osso_deinitialize(ctx); // Shutdown return EXIT_SUCCESS; } 5. More on app development Android • Originally Google, later Open Handset Alliance • Some other mobile development systems • Open source – No licence or distribution payments – MIDP Java • Beta SDK 11/ 2007, 1.0 SDK 09/2008 – Maemo – SDK includes emulator, debugging tools, on-device debugging – Android • T-Mobile G1 – iPhone – 10/2008 (USA ja UK) – Windows Mobile – Europe early 2009 – OpenMoko • Several manufacturers aim at launcing Android phones during • Commonly used implementation techniques 2009 – Motorola, Lenovo, Sony Ericsson, Samsung • Summary Android – Technology Android – Application development • Built on top of Linux • All applications are equal – Can be replaced by 3rd party apps – Drivers, processes and memory management, security, – Same APIs are available for all programs (calls, SMS, WLAN, GPS, networking,power management camera, sensors, …) – Libraries such as SQLite, WebKit, OpenGL – Inter-application communication • Dalvik VM – Application can request making a call and the system seeks the corresponding service – Abstract view to the hardware – Development done using Java, not a Java VM • Any app can offer services and use services offered by others – Runs Dalvik executables which are obtained based on Java bytecodes • Background execution allowed • Possible to bypass VM and use C/C++ – (Unlike in Standard Java MIDP 2.0) – Programs cannot control their own life cycles – Requires information on targer device – VM can interfere with the execution of the VM by suspending and – Not officially supported resuming them; apps must be designed to be compatible with this
  7. 7. 5. More on app development iPhone (http://developer.apple.com/iphone/gettingstarted/docs/iphoneosoverview.action) • Mac OS X based system; origins trace to Mach kernel old • Some other mobile development systems Unix implementations – MIDP Java • Objective C for programming – Maemo – Low level interfaces commonly based on C; more advanced – Android interfaces (e.g. Multimedia) mixture of C and Objective C – iPhone – Windows Mobile • Explicit redesign to support – OpenMoko phone UI – Touch events • Commonly used implementation techniques – Not application centric • Summary Technology layers Objective C Code (http://developer.apple.com/iphone/gettingstarted/docs/creatingiphoneapps.action) • Core OS and Core Services layers: fundamental interfaces for iPhone OS – File access, low-level data types, Bonjour services, network sockets, SQLite, access to POSIX threads and UNIX sockets, etc. int main(int argc, char *argv[]) { • Media layer: – 2D and 3D drawing, audio, video, OpenGL ES, Quartz, and Core Audio, Core Animation NSAutoreleasePool * pool = • Cocoa Touch layer: [[NSAutoreleasePool alloc] init]; – Fundamental infrastructure used by applications, object-oriented support for collections, file management, network operations, access to the user’s contact and photo information and to the accelerometers and other hardware features of the device. int retVal = UIApplicationMain(argc, argv, nil, nil); – UIKit framework provides the visual infrastructure for your application, including classes for windows, views, controls, and the controllers that [pool release]; manage those objects • The starting point for any new project is the Cocoa Touch layer, and return retVal; the UIKit framework in particular. } 5. More on app development Windows Mobile • .NET Compact Framework • Some other mobile development systems – Based on .NET environment – MIDP Java – Common Language Runtime (CLR) – Maemo – MicroSoft Intermediate Language (MSIL) – Android • Just-In-Time compilation from MSIL to binary – iPhone when used – Windows Mobile – OpenMoko • Tools somewhat similar than in general with • Commonly used implementation techniques .NET development • Summary – Small differences in programming perspective (UI, performance, resources, etc…)
  8. 8. 5. More on app development OpenMoko (www.openmoko.org) • An open source project dedicated to delivering mobile phones software stack • Some other mobile development systems – Linux, etc. What could be expected based on Maemo and – MIDP Java Android – Maemo – Android • Currently selling the Neo FreeRunnerphone to advanced – iPhone users and will start selling it to the general public as soon as the software is more developed – Windows Mobile – OpenMoko • In general, seems comparable to Maemo, except that • Commonly used implementation techniques geared towards implementation of a phone, not Internet • Summary tablet 5. More on app development Improving portability with VM • Possibility to implement the same system on top of different infrastructure • Some other mobile development systems – Same environment can be used in both development and – MIDP Java execution environment – Maemo • Some tedious and error-prone tasks can be allocated to – Android the virtual machine instead of the programmer – iPhone – Memory management in particular – Support for recovering from errors – Windows Mobile • Simplifies the implementation of security features – OpenMoko – There already is a central element that is responsible for • Commonly used implementation techniques executing applications • Summary Unifying stimuli with event-based Benefits programming service caller event source • Commonly used technique in UI programming service provider • Serialization of operations triggered to the execution; events can be handled one by one event observers event • Simplified model of execution – No need to define the order of execution in user programs; it is enough to generate an event • Simplified introduction of new event generators • Simplified introduction of new event observers • Long-lasting operations form a problem – Commonly initiate a new event that continues processing after a Traditional service call Event-based operations while • Introduces additional complexity in the form of a state machine
  9. 9. Separating device specific parts Model-View-Controller, MVC using MVC pattern Observer update() * update() Reusable in View Controller Model similar devices attach(Observer) detach(Observer) notify() attach() getData() getdata() service() View Reusable across different user interfaces, devices, Model initialize(Model) Controller makeController() input media, etc. activate() display() initialize(Model,View) update() handleEvent() update() The model should gather all common aspects. In practise, many systems force commonalities to views and controllers. attach() service() MVC Execution Interfacing Controller Model View • Access to device specific resources vs. access to a sandbox service – Security considerations unavoidable handle- notify Event update display • Access to device specific widgets vs. getData access to a generic canvas on top of which can be rendered – All apps similar in a device vs. update getData App similar in all devices • Managed code for applications vs. using native applications 5. More on app development Conclusions • Numerous approaches to programming • Some other mobile development systems mobile devices exist – MIDP Java – Maemo • Commonalities – Android – Virtual machines to unify the development – iPhone approach in several different configurations – Windows Mobile – Event-based programming for user input – OpenMoko – Separating UI specifics using MVC • Commonly used implementation techniques • Summary – Auxiliaries packaged in installation packages

×