New Directions in Programming Languages

Programming for Mobile Devices

Language Evolution

• Programming languages evolved starting with machine language, through assembler, then to high level languages with the help of compilers.

• High level languages evolved to have richer features and greater support for abstraction.

• Basic paradigm was still: source code is compiled to produce executable for a particular machine architecture.

Compiled Languages

• Traditional way of creating programs– Write code for a particular execution environment

(device plus options, e.g., graphics cards etc)– Compile code– Link the object code to create executable– Execute the code on the device for which it was written

• Produce different versions of the code for different device environments.

• PROBLEM: explosion of different device types and architectures.

Compiled Language Problem

• Very expensive and time consuming to produce many different versions of the program code

• Very difficult to maintain so many different versions.

• Different execution environments end up with different versions – confuses the heck out of users!!

• Execution environments keep evolving at a fast pace, so porting, maintaining and upgrading is a continual, expensive activity.

New Programming Environments

• Laptops – mouse works different, display needs vary

• PDA’s – mouse? What mouse?, limited display, keyboard?

• Cell phones!!

• Differences in memory, input, display/output

Desktop vs Mobile

• Compute power and memory– High versus low

• Display– Large versus small– Full color versus mostly monochrome

• Secondary storage– Plenty versus virtually non-existent

• Power– Unlimited (connected) versus (battery) in hours

Desktop vs Mobile

• Connectivity• Connected/Well-connected drops to “often”• Plenty bandwidth versus tiny• Relatively stable bandwidth versus wildly

fluctuating

• User Interface– Standard versus varying

• Standards– Almost there versus many

Mobile Device Memory

• Typically, combination of SRAM and Flash RAM is used– Frequently changing data is kept in SRAM.

• Dell Axim X5– 32 MB SDRAM– 32 MB StrataFlash ROM

• Palm Tungsten– 8MB Flash– 16MB SDRAM

Input

• Very dependent on user environment– Keypads, buttons and touch pads require larger

devices– Touch screens allow smaller devices but can be

fragile• Interesting touch screen and keypad combinations

have been developed • Simulate keypad on touch screen

– Speech input allows small devices but ambient noise is an issue

Input

• Buttons, softkeys, on-screen keys• Directional Keypads• Roller Wheels• Rocker Controls• Most devices have two or four directional

arrow buttons.• Some use discreet buttons while others use

floating pads

Wheels and Dials

• Scroll through menu options and push to activate a selection

• Some can be used in a single handed operation!• Many different variants are available• JogDial from Sony - A dial used on mobile end-

user devices to scroll through menus and select functions with one hand.

• Also known as Thumb Dial

Rocker Controls

• Directional controls usually placed at the upper left-hand side of a device.

• Can be pushed up and down, and most can be clicked in

• Used for scrolling, selection and action• In some rocker controls, the farther in a

direction the control is pushed, the faster the scrolling goes.

Data Input

• One of the biggest challenges in UI design for mobile devices is input.

• Keypad

• Stylus Input

• Keyboards

Phone Style Keypads

• Tripple tap and T9• Tripple tap

– is the default for all phones when text is required.

– No copyright or patent on this method!!!

• T9– Predictive text input technology

– Uses numeric keypad to enter text, one keypress per character

– Many users find it confusing!

Phone Style Keypad

1 2abc

3def

6mno

5jkl

4ghi

9wxyz

8tuv

7pqrs

* 0 #

Example

Triple-Tap Key Pressed Display T9 Key Pressed Display 6 m 6 o 3 md 3 of 3 me 3 off Pause me 8 meet 3 med 4 meeti 3 mee 6 meetin 8 meet 4 meeting 4 meetg 4 meeth 4 meeti 6 meetim 6 meetin 4 meeting

PDA Stylus Input

• Electronic Ink– useful for drawings and text notes

• Handwriting recognition– Grafiti – Single stroke based

• Palm

– CIC’s Jot – both single and multi-stroke; multiple forms of each character

• WinCE

• On-Screen keyboards– Tap each character on keyboard displayed on screen

Keyboards: Fastap vs QWERTY

• Full keyboard on a phone handset!

• Hills and valley model– Alphabets are hills– Numerals are valleys

• Press a valley and you end-up pressing four surrounding hills – fat fingers effect– But this is being handled now!

Narrow or Wide Fastap

Speech Recognition

• Most natural input for mobile devices• No additional space required• Most expensive in compute power requirements

– Limited vocabulary works for many applications.

– Continuous speech recognition is still not a standard part of mobile devices.

• Most vulnerable in extreme environments• “Recognize Speech” vs “Wreak a nice beach”

Output: Display

• A key technology for mobile devices.

• Most users want high-quality color displays, but – they consume a significant amount of power,

and – cost is high.

Power Consumption Problem

Audio, Communications, etc.

• Producing sound requires power!• 802.11 is power hungry.

– There is sleep mode– Bluetooth is better but not ubiquitous

• Location– GPS is becoming more and more common– Triangulation – but telcos will not share the

data with the consumer!

How to Program All Those Devices?

• “Write once, run everywhere” has a lot of appeal!– Write code once– Each device which can run the code has a

“Managed Run-Time Environment” to execute the code

What is a MRTE?

• An engine that takes in intermediate language instructions, translates them into machine instructions, and executes them.

• Two most common MRTEs– JVM – Java Virtual Machine– .NET CLR – Common Language Runtime

What Does It Do?

• MRTEs take machine independent byte code and execute it.– Virtual machine – interpretively executes byte-

encoded programs– Garbage collector – automatic management of

address space– Just-In-Time (JIT) compiler – translate the byte

code into native machine instructions

Key Features

• Dynamically load and execute code

• Automatic memory management

• MRTE handles multi-threading

Source code

compilerMachine

+ OSobject code

Source code

“compiler”

Inter- mediate

byte code

Machine + OS

MRTE

Good For Handhelds

• Given the diversity in Cell Phone / PDA software environments, the ability to generate byte code and have it execute on the device is needed.

• MRTEs memory management is important so that critical apps will not be affected

• Memory efficiency is important

Java MRTE for Handhelds

• Sun introduced Java in 1995• Java MRTE is called the JRE (Java runtime

environment) and consists of the JVM (Java virtual machine).

• Sun introduced a small-Java solution and virtual machine, Java 2 Platform, Micro Editition (J2ME), for memory constrained devices in 1999

• It has since become popular with wireless handset manufacturers

J2ME

• Inherent protection from memory overruns

• Memory efficiency of byte code

• Consortium-based standardization process

Java in Wireless Devices

• Client devices are currently using J2ME released in 2000– CLDC – Connected Limited Device Configuration

• Addresses the needs of horizontal market

– MIDP – Mobile Information Device Profile• Addresses the needs of vertical markets, such as cell phones

• CLDC, combined with MIDP, is the complete J2ME runtime environment for resource-constrained mobile devices such as phones and entry level PDAs.

J2ME Architecture

Device Hardware

Native System Software / Host OS

NativeApplications

CLDC 1.0

Java Applications

MIDP 1.0 OEM Classes

CLDC 1.0

• Provides the platform intended to serve as the lowest common denominator for all resource constrained connected devices– Support for the Java language and virtual machine

features– Core libraries (java.io, java.util etc)– Networking– Security

• Many limitations, e.g., no support for floating point; limited exception handling, no support for user-defined class loaders

CLDC Implementations

• Two virtual machines implement CLDC – KVM and HotSpot

• K Virtual Machine (KVM) - designed for inexpensive mobile devices - named to reflect that its size is measured in the tens of kilobytes– Suitable for devices with 16/32-bit RISC/CISC

microprocessors/controllers, and – With as little as 160 KB of total memory available for

the Java technology stack. 128 KB of this is for the storage of the actual virtual machine and libraries, and the remainder is for Java applications.

CLDC - Hotspot

• Targeted at newer generation devices with larger available memory.

• Suitable for devices with 32-bit RISC/CISC microprocessors/controllers, and with 512KB to 1MB of total memory available for the Java applications.

MIDP 1.0

• Addresses the needs of a specific vertical market, e.g, mobile phones, PDAs – Application models– User interface support– Persistent storage– Timers

CLDC and MIDP Issues

• Goal of supporting small footprint has been achieved.

• Problems in application portability and security– Due to lowest common denominator approach,

proprietary OEM classes have been developed by vendors, e.g., for audio, additional UI components

Status of J2ME

• Predicted that more than 50% of applications running on wireless client devices will be written in J2ME

• In 2001, 15 million client devices were Java-enabled

• In 2007, more than 690 million client devices expected

• Currently supported by Casio, Fujitsu, Hitachi, Kyocera, LG, Mitsubishi, Motorola, NEC, Nokia, Samsung, Sanyo, Sharp, Sony Ericsson, Toshiba

Other MRTE’s

• Microsoft’s .NET intended to serve the same purpose as Java – but more coherence and less fragmentation across device types for MS-based platforms

• .NET does better but it only runs on MS OS!

• Applications are developed using MS Visual Studio tools

“Compact Framework” .NET

• CF .NET is targeted at small foot print devices

• Released in the 2002 releases of MS Windows CE

CF .NET vs J2ME

• CF .NET supports multiple languages – C++, C#, Visual Basic and Java Script

– Programs are compiled into a common intermediate language representation (byte code) that executes in Common Language Runtime Environment (CLR)

• CF .NET model is more flexible – Avoids the need for proprietary extensions

• Requires more resources on devices

CLR vs JRE

Run-Time Services

Windows

Common Language Runtime(CLR)

Code TypeSafety

GarbageCollector Security

Microsoft Intermediate Language

(MSIL)

J# C++C# VB.NET

Run-Time Services

Java

Java Runtime Environment(JRE)

GarbageCollector Security

Byte Code

MacOS LinuxWindows Unix

C Sharp

• C# is an object-oriented language for building applications for the Microsoft .NET platform,– which provides tools and services for both

computing and communications.

• Includes built-in support to turn any component into an XML Web service that can be invoked over the Internet - from any application running on any platform.

The Future of MRTE’s?

• 1st generation of wireless data applications (2D games, email, MMS, PIM) are limited.

• For more data intensive and diverse applications, a consistent software interface layer is needed– Insulate developer from underlying device

hardware and software