User Interface Software & Technology

Download Report

Transcript User Interface Software & Technology

UI Environments
J2ME
.NET Compact Framework
nods to:
Shwetak Patel, Heather Mahaney, Gillian Hayes
Agenda
UI Environments
J2ME
.NET Compact Framework
HW 3
Intro to J2ME
J2ME – Java 2 Micro Edition
Introduced by Sun in 1999 for mobile
devices
Scaled down version of J2SE
Smaller footprint
No heavyweight classes
(swing, awt, etc)
Highly optimized runtime environment
J2ME Architecture
OEM Specific API
KVM - Kilobyte Virtual Machine
40 – 80 KB in size
For devices with 160 KB of memory and 16 or
32-bit RISC/CISC microprocessors
J2ME Architecture (cont.)
OEM Specific API
CLDC - Connected Limited Device Configuration
Provides core lower level functionality
Bare minimum IO and utilities
Currently consists of java.io, java.lang, java.util,
java.microedition.io
J2ME Architecture (cont.)
OEM Specific API
MIDP – Mobile Information Device Profile
MIDP provides the core application
functionality for mobile devices
Network connectivity, data storage, and user
interfaces
J2ME Architecture (cont.)
OEM Specific API
OEM Specific API
Access to proprietary features and
functionality
Audio system, camera, lighting system, etc
J2ME Programming
Environment
Sun provides IDE for the “generic”
java-enable mobile phone
Most mobile phone companies like
Motorola or Nokia have their own
IDEs
J2ME Applications
A J2ME app is called a Midlet
Midlet life cycle
J2ME UI
MIDP provides some limited UI elements
Form
Alert
Choice and ChoiceGroup
List
StringItem
TextBox
TextField
DateField
Guage
Ticker
J2ME UI vs J2SE UI
MIDP UI elements ARE NOT subsets
of AWT/Swing
Interaction with the user is based around
a succession of screens
MIDP only has a single command
listener
J2ME Canvas
J2ME does allows lower level access to
the Canvas
Can create custom graphics and user
interfaces by extending Canvas
Lightweight Window Toolkit
Motorola introduced the LWT to
address the limitation of MIDP
Works on all Java-enable mobile phone
Similar to J2SE Swing
Layout management with absolute or relative
widget placement
Notion of containers
Component Listeners
LWT Hierarchy
Sample J2ME Applications
.NET Compact Framework
.NET Compact Framework
Design Goals
Target mobile and embedded devices
Portable subset of .NET Framework
No new ‘compact’ namespaces
Visual Basic .NET & C# compiler support in v1
Leverage Visual Studio .NET
Run managed .EXEs and .DLLs directly
Debug with Visual Studio .NET
Peacefully co-exist with host OS
Run on native threads, P/Invoke to call native code
Other Differences
Class libraries are a subset (about 25%)
Different size and scalability
characteristics
Compact Additions
IrDA support
SQL Server CE managed classes (not available
on CF for SmartPhones)
Device-specific controls
Framework Size
Framework size
1.35MB (ROM) on Windows CE .NET Device
Each application runs its own instance of the
Framework; there is no pooling at this time.
Running RAM needs
1 MB+ (depends on app)
Typical application sizes
5 - 100 KB
Apps often smaller due to use of platform features in
the framework
.NET Compact Framework
System.Web

Services
Description
 Discovery
 Protocols

Cache
Configuration

System.Windows.Forms
UI
Design
HTML Controls
 Web Controls

System.Drawing
Security
Session State
Drawing 2D
Imaging
Printing
Text
System.XML
System.Data
ADO.NET
Design
Component
Model
SQL Client
SQL ServerCE
XML Document
Xslt/XPath
Serialization
Reader/Writers
System
Collections
Security
Text
Globalization
IO
Net
Reflection
Resources
Configuration
Service Process
Diagnostics
Threading

Runtime
Interop Services
 Remoting
 Serialization

Base: Networking
Sockets
Synchronous and asynchronous
Multiple protocols
Streams
Built on top
of sockets
Synchronous
and asynchronous
HTTP request
and response
Use stream model
Requires no user
knowledge of HTTP
Applications
.NET Compact Framework
Web Services
HTTP Request/Response, Network Stream
Sockets
Common Language Runtime
Base: Threading
Applications start with an initial thread
Applications can start new threads
Using threads
Responsive UI
Program function segregation
Thread synchronization primitives
App domains exist until all threads exit
Base: Native Code InterOp
Managed  native (P/Invoke)
Calls into existing native code
.NET Compact Framework does marshalling of arguments
Native  managed
P/Invoke and block
MessageWindow Class
Native code can indicate events and transfer data to
managed code via message pumps
Microsoft.WindowsCE.Forms.MessageWindow
Windows Forms Support
Great for Rapid Prototyping on Pocket PC
Layout
Manual positioning
Drawing
Polygons, lines, arcs, ellipses, rectangles
JPEG, BMP images
Text and images
TrueType bitmap fonts on Mobile
Most desktop controls
Designer support
HW 3: Starting your IDF
Starting an Interface Division
Framework
You’re now going to start generalizing
the work you did for HW 2
HW 3: Two major parts
Part I: Support for Initiating Division
You must create a library for applications that:
– Provides an interface and functionality for initiating
communication with an interface generator
– Provides at least two general purpose interactors that
applications can instantiate to allow end users to choose
how to divide the interface
– Manages communication to and from the interface
generator
HW 3: Two major parts
Part II: Interface Generator
You must generalize the mechanism you created
for HW 2 to support a wider variety of interface
divisions. Your interface generator should:
– Accept a semantic description of the components,
including their attributes and desired layout, to include in
the interface
• This semantic description should be kept in a file separate
from your application code
– Support at least 3 types of layouts, and at least 7 types
of components.
– Provide mechanisms for returning information from the
interface generator when requested by either the
generated interface or the original application
HW 3: Using the Framework
Update your email application to use
your framework
Create a simple application that
demonstrates your 3 layouts and 7
components
Foreshadowing
HW 4: Adding support for behaviors
HW 5: Allowing users to choose desired
interface division and associated
behaviors
HW 6: Create a new application using
your framework
Next Time
Midterm!