Download New Directions in Programming Languages

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 enduser 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
2
3
abc
def
4
5
6
ghi
jkl
mno
7
8
9
pqrs
tuv
wxyz
*
0
#
Example
Triple-Tap Key Pressed
6
3
3
Pause
3
3
8
4
4
4
6
6
4
Display
m
md
me
me
med
mee
meet
meetg
meeth
meeti
meetim
meetin
meeting
T9 Key Pressed
6
3
3
8
4
6
4
Display
o
of
off
meet
meeti
meetin
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 byteencoded 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
Source
code
compiler
“compiler”
object
code
Intermediate
byte
code
Machine
+ OS
MRTE
Machine
+ OS
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
Java Applications
MIDP 1.0
OEM Classes
Native
Applications
CLDC 1.0
Native System Software / Host OS
Device Hardware
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 Javaenabled
• 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
J#
C#
VB.NET
C++
Java
Microsoft Intermediate Language
Byte Code
(MSIL)
Code Type
Safety
Garbage
Collector
Security
Garbage
Collector
Security
Common Language Runtime
(CLR)
Java Runtime Environment
(JRE)
Run-Time Services
Run-Time Services
Windows
MacOS Windows
Unix
Linux
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