Mobile Tools for Java Platform

1
Mobile Tools forJava Platform

• The goal of the Mobile Tools for Java project is
  to extend existing Eclipse frameworks to support
  mobile device Java application development.
• MTJ will enable developers to develop, debug and
  deploy mobile Java applications to emulators and
  real devices.
• Scope of the doc
• Focus on 1st release ( potential future
  features)

2
Contents

• Eclipse High-Level Architecture
• Java Runtime Environments
• MTJ Ecosystem
• MTJ high-level layers
• MTJ Development by Milestone
• Device fragmentation
• Pre-processing
• Automated manual testing
• Build management

• Wizards
• Runtime Launch
• Debugging
• Code Editor
• Deployment
• Device Management
• Signing and Obfuscation
• Localization
• Application Flow
• GUI Editor
• Backup slides

3
Eclipse High-level Architecture
Ecosystem
Vertical Industry Initiatives
Horizontal Technologies
Desktop Domain
Internet Domain
Enterprise Domain
Embedded Domain
Mobile Domain
Technology Enablers
Web Tools
Modeling Tools
Data Management
Service Oriented Architecture
Embedded Mobile Tools
C/C Dev. Tools
Java Dev. Tools
Test and Performance
Business Intelligence Reporting
System Management
Frameworks
UI Frameworks
Graphical Frameworks
Modeling Frameworks
Tools Platform
Multi-languagesupport
Update
Project Model
Workspace
Rich Client Platform
SWT
Workbench
Runtime
4
Java Runtime Environments
Enterprise
Desktop
Low-enddevices
SmartCards
High-enddevices
Optionalpackages
Optionalpackages
Optionalpackages
Optionalpackages
Personalprofile
MIDP
Foundationprofile
J2EE
J2SE
JavaCard
CLDC
CDC
Card VM
KVM
Java Virtual Machine
Java Micro Edition (J2ME)
The MTJ projects focus in Mobile runtimes is in
the J2ME area.
5
MTJ Ecosystem
MTJ context
Eclipse
Different vendorproducts based on Eclipse MTJ
Download / Update sites Eclipse
MTJ
API
API
Sun / IBM (tooling runtime JRE 5.0 / J9 )
JavaDocs
A List of JVMS
Vendor X (for SDK download)
Tooling RuntimesJRE 1.4 .. 5.0, J9
Operating Systems Win32, Linux, MAC.
Vendor Y (for SDK download)
6
MTJ high-level layers

Mobile IDE Components
Device Description Provider
Device Platform Provider
Obfuscation Provider
Packaging Provider
Signing Provider
Device Platform Provider
GUI Builder Provider
Build Provider
Pre-processing Provider
Deployment Provider
Ant Provider
x
Mobile IDE Extensibility Framework Layer
Runtime Management
Deployment Management
Build Management
Device Management
GUI Builder Management
Security Management
Eclipse Tool Services
Multimedia Tools
Visual Editor
Web Tools Project
GEF
Data Tools
Graphical Modeling Framework
BIRT
Workflow Toolbox
Multi-language support
Testing Profiling Tools
Eclipse Modeling Framework
EMF
Eclipse Platform
OSGI
SWT
Workbench
JDT
Operating Systems Win32, Linux, MAC
7
MTJ Development by Milestone
Mobile SDK Emulator
Mobile RAD / IDE
GUI builders
Wizards
Provider Components
Game Editor
Create Application
Code Packaging
Build
Other
Project
Build
Audio converter
Obfuscation providers
Flow Editor
J2ME Nature
Create Class
Create Project
Deployment
Code Editor
Signing provider
Custom Components
LCDUI Editor
Create UI
Symbian templates
Deployment providers
Localization
J2ME project builders
eSWT Editor
Snippets
JAD Editor
Pre-processing
Xx Editor
Runtime launch
Desktop
Device
Help
Packaging
Debugging
Antenna provider
Desktop
Device
IDE Extensible Framework Layer
Runtime Management Framework
Deployment Framework
Build Framework
Device Management Framework
GUI Builder Framework
Security Management Framework
Eclipse Platform
8
Device fragmentation

• Different characteristics of devices must be
  taken into account
• Physical device characteristics, e.g. display
  resolution,-size and buttons, processing power
  and memory
• Quirks in the OS, API and Java virtual machine
  implementations
• Variation comes also from APIs supported by each
  device
• Flavours of Symbian (S60, S80, S90) and other
  mobile OS versions
• J2ME profiles and configurations CLDC 1.0/1.1 and
  MIDP 1.0/2.0
• Optional APIs for Bluetooth, 3D, Multimedia, Web
  Services, etc.
• Proprietary APIs from device manufacturers and
  operators
• In addition, there are other operator and market
  requirements
• Localisation, branding, billing, etc.
• New devices and APIs are introduced frequently

Huge amount of configurations
Operator requirements
Differing assets
Varying devices
X

X
9
Device fragmentation, Mobile value chain
This diagram represents the major players in the
wireless industry. Application- and Content
providers have partnered with Network operators
to design and develop Java solutions for
consumers. Content aggregators license content
from its creators and format it to be used with
specific devices and networks. Content
distributors create the revenue by providing the
distribution channels. Network operators
(carriers) and Infrastructure providers control
the wireless network and own the customer
information. Device manufactures drive the
technical innovation through the new
hardware. The application developers and content
aggregators needs most tools against the device
fragmentation.
Application Developers
Content aggregators and Distributor
End-user / consumer
Network operators
Retail
Infrastructure providers
Device manufactures
10
Device fragmentation, pre-processing

• Definition Pre-processing changes the source
  code before it is compiled. It allows conditional
  compilation and inclusion of one source file into
  another and is helpful when trying to maintain a
  single source for several devices, each having
  its own bugs, add-on APIs, etc. and it enables
  device optimization.
• The Eclipse JDT could add support for
  pre-processing, alternative could be e.g. J2ME
  Polish, which can be integrated to Eclipse
  (licensing must be checked) or re-implementing
  the similar functionality.
• One key feature is the device description
  database, that helps to create tasks or actions
  against similar devices. The device description
  database enables that developers can identify and
  group devices with an keyword, that can be used
  e.g. in pre-processing.

1
1..n
1
11
Automated manual testing

• Tdb.

12
Build management

• The build environment is heavily relying on
  Eclipse, but there are plans to support also Ant.
  One planned extension to Ant is the Antenna
  project, which provides a set of Ant tasks
  suitable for developing wireless Java
  applications targeted at the J2ME and Mobile
  Information Device Profile (MIDP).
• The build management enables that the build
  process can be configured to suit for the active
  project needs. E.g. what build providers are used
  as default and how the building process works.
• The target device management provides data about
  selectable devices and J2ME platforms (SDK
  Emulators) and enables that the Runtime Platform
  Definition. The selected default target Device
  Platform is then activated to the projects use.

13
Wizards

• Base wizards
• Create Project
• Create Application
• Code Packaging
• Create Class
• The base wizards implement the corresponding
  Use-Case requirements.
• One optional scenario may be that Symbian has
  created an template mechanism (that is in use
  currently in C side in Eclipse), that the MTJ
  could convert to be used in the Java side.

14
Runtime Launch
15
Debugging
16
Code Editor

• The MTJ code editor is based on the Eclipse JDT
  base functionalities.

17
Deployment and Runtime management

• The MTJ provides an Deployment and DevicePlatform
  frameworks that supports the existing SDK
  Emulators and phones runtimes
• The framework publishes a Device Platform
  -interface, that capsulate (hides) the actual
  runtime environments and protocols.
• The framework separates the different vendors
  products to own plug-ins

Eclipse
Vendor X SDK Emulator Plug-in
SDK / Emulator (Vendor X)
MTJ Plug-in
Vendor Y SDK Emulator Plug-in
SDK / Emulator (Vendor Y)
Device Platform
Vendor Z SDK Emulator Plug-in
SDK / Emulator (Vendor Z)
Extension point
Vendor X Real Device Plug-in
Real Device (Vendor X)
Vendor Y Real Device Plug-in
Real Device (Vendor Y)
18
Device Management

• The device management in this scope focuses to
  enable detecting, visually showing, identifying
  and visually managing the available mobile
  devices.
• There should be ability to group devices with
  similar configuration based on some criteria.
  This grouping could be used e.g. in the packaging
  / building / localization / deployment / branding
  processes.
• The device model holds each device and

1..n
1
1
19
Signing and Obfuscation

• Signing
• MIDP 2.0 (JSR-118) includes enhanced mobile code
  and application security through a well-defined
  security manager and provisioning process. During
  the provisioning the MIDP applications are signed
  with an certificate, which ensures their security
  and makes them trustworthy.
• Trusted MIDlet suites can be granted access to
  API's without explicit user authorization, and
  have wider access to device API's.
• Obfuscation
• By using an Obfuscator tool, the source code can
  be made more difficult to reverse-engineer and
  also there can be some code optimization benefits
  achieved at the same time.
• Obfuscation can be done e.g. through an ANT task
  that activates an Obfuscator tool and it performs
  the obfuscation against the parameterized source
  code location.

20
Localization

• Localization (I18N/L18N) is a major issue in the
  wireless space, where a single app deployed to a
  single carrier may need to support many languages
  and character sets. 
• Key requirements
• The Localization architecture should be capable
  of supporting all languages.
• It should remove the need for application
  developers to decide which encoding the
  application will support.
• The Localization architecture should be aware the
  UI differences in devices so that the developers
  wont have to (e.g. the width and length of a
  device screen).
• The localization should enable that the service
  providers can extend the language supports during
  the deployment phase.
• Allow local users to select their preferred
  languages as provided by the application. There
  should be visible UI simulation that enable to
  verify the UI immediately when the users switch
  the locale.
• The localization should support at leas two
  approaches
• By creating a resource file (.properties) and
  adding there the selected source files
  localizable keys.
• By enabling such optimization to bind the
  localization directly to the application.

21
Application Flow

• The Application Flow creates kind a action
  diagram, where the visible and invisible actions
  are drawn on a graphical editor. The AF-editor
  enables that developer can design e.g. mobile
  application UI flow.

22
GUI Editor

• The Eclipse Visual Editor provides an extensible
  GUI framework, that can be used in the mobile IDE
  UI area.
• Why VE The VEs framework provides a lot of
  extension points to different kind of GUI editors
• Benefits The GUI editors would have common base
  framework and the there is a need to implement
  only the delta of the different mobile GUI
  editors
• Now existing The base GUI framework.
• What is needed The mobile screen engines with UI
  widgets to LCDUI area. VE doesnt provide any
  multimedia services yet.

23
Backup slides

• More detail presentation about the top technical
  items

24
Backup slides Device Fragmentation
25
Device Platform
1..n

• Target environments are seen as Device Platforms
  by the MTJ environment. Device Platform contains
  one or more Device instances.
• MTJ plug-in doesnt know if the Devices are
  device emulators or real devices because the
  plug-in extension point API hides all
  implementation details

26
Device Platform, Device Platform Services
Device Platform Services
getDevicePlatforms() DevicePlatform getDevices
(String devicePlatformName) Device ...

• Device Platform Services make it possible to
  query available Device Platforms.
• Based on Device Platform name its possible to
  get Devices or the Platform.

27
Device fragmentation
Device
Device Management
Project

• Project can select smaller set of APIs that the
  targeted devices are supporting. By selecting
  smallest possible set of needed APIs, the number
  of suitable devices is bigger.
• Although the Project has the default device, the
  Projects definitions can match to several devices.

28
Device fragmentation, Device Services
Device Services
getDevices(DeviceConfiguration dc, DeviceProfile
dp, ServiceAPI apis)
Device ...

• Device Services make it possible to query
  Devices that are possible targets to the
  Projects application. Project uses its own
  definitions as parameters in the service call.

29
Backup slides - Wizards

• Wizards internal architecture

30
Wizards architecture

• template management

31
Backup slides - Runtime Launch

• Runtime Launch internal architecture

32
Runtime Launch architecture

• The Runtime Launch architecture uses the Device
  Platform to enable selection of available
  Devices.

33
Runtime Platform
Device
Runtime Platform Definition
1..n
JVM Impl.
1
1
1..n
1

• Device instance defines the Runtime Platform
  Definitions that its capable to run on.
• Runtime Platform consists of Device
  Configuration, Device Profile, Service APIs and
  JVM Implementation.
• Device Configuration defines used configuration
  (i.e. CDC or CLDC) and its version.
• Device Profile defines used profile (i.e. MIDP)
  and its version.
• Service APIs are either APIs that are defined in
  Device Profile or API of optional Services that
  the Devices OS is supporting.
• Runtime Platform Definition is always based on
  defined Mobile SDK JVM Implementation.

34
Runtime Platform (cont.)
JVM Impl
Library Jar
Library Jar
1
1

• Service API object contains the standardize
  service name and its version, i.e. WMA 1.1,
  MMAPI 1.1 or Location API 1.0 .
• Service API has also reference to JAR Library
  that implements the API.
• Also Mobile SDK JVM Impl object contains the
  JVM name and its version and reference to JAR
  Library that implements the JVM specification
  that is defined by the Runtime Platforms Device
  Configuration Specification.

35
Runtime Platform, Device Services
Device Services
getRuntimePlatforms(String devicePlatformName,
String deviceName) RuntimePlatformDefinitio
n ...

• Device Services make it possible to query
  Runtime Platforms of a Device.

36
Backup slides - Debugging

• Debugging internal architecture

37
Debugging architecture

38
Backup slides - Device Management

• Device Management internal architecture

39
Device Management architecture
Device Platform
Mobile Project
1..n
1..n
1
1

• Each Mobile project may select the targeted
  devices, that the project is supporting. Mobile
  Project contains one or more Device Platforms,
  thus there is only one default mobile SDK active.
• The Device Platform and Device instances
  definition is stored inside the EMF based Device
  model and the with extendable persistence
  component the definition is shared with in
  several projects.
• The Runtime Platform Definition data is also
  stored and shared among projects and the
  Fragmentation Definition can enhance the task to
  find compatible device groups.
• Also the pre-processing can use this to provide
  and define the device grouping inside the JDT.

40
Device Management
Device Description Provider
Device Platform Provider
Device Management
ltlt extension point gtgt
ltlt extension point gtgt
ltlt extension point gtgt
Device Management Implementation
Device Platform
Device Description Implementation
ltlt extendsgt gt
ltlt extendsgt gt
ltlt extendsgt gt
Device Platform
Device Description Implementation
Device Platform

• Target environments are seen as Device Platforms
  by the MTJ environment. Device Platform contains
  one or more Device instances.
• MTJ plug-in doesnt know if the Devices are
  device emulators or real devices because the
  plug-in extension point API hides all
  implementation details
• Device instance defines the Runtime Platform
  that its capable to run on.
• The Device Management uses Device Platform and
  Device Description information.
• The deeper interaction and dependency is
  described in the following two slides

41
Device Management control flow
42
Device Platform, Device Platform Services
Device Platform Services
getDevicePlatforms() DevicePlatform getDevices
(String devicePlatformName) Device ...

• Device Platform Services make it possible to
  query available Device Platforms.
• Based on Device Platform name its possible to
  get Devices or the Platform.

43
Device Platform
44
Device
45
Runtime Platform
46
Project
47
Code Editor

• Code Editor internal architecture

48
Code Editor architecture

• tbd

49
Project

• LEGEND

Device
Project
APIs

• Projects defined Device Configuration
• Projects defined Device Profile
• Service APIs that are selected to the Project
• Devices Device Configuration
• Devices Device Profile
• Service APIs that are supported by the Device

DP
Library Jar
Library Jar
DC
1..n
1
1
1
Mobile SDK Emulator

• Mobile Project development is targeted to
  devices that have certain Device Configuration
  and Device Profile. Therefore MTJs Project has
  also Device Configuration and Device Profile
  defined.
• Its possible to select a set of Service APIs to
  the Project. Based on the selected set of APIs
  corresponding Jar libraries are added to the
  project.
• Project always has default device that matches
  to the Projects definitions. That default device
  also gives the needed Jar libraries to the
  Project.

50
Backup slides - Deployment

• Deployment Framework internal architecture

51
Deployment framework architecture
SDK / Emulator (Vendor X)
MTJ IDE environment
U EI
X
SDK / Emulator context (Nokia, Win32 OS)
Z
Deployment Framework
Interface
S40
Interface
OTA
Extension point
S60

• The MTJ provides an Deployment framework that
  supports the existing SDK Emulators and phones
  runtimes.
• The framework publishes an deployment interface,
  that capsulate (hides) the actual runtime
  environments and protocols.
• The framework separates the different deployment
  low-level services to own components (like UEI,
  OTA, etc.) with supporting existing proprietary
  emulator and phone access (marked as X and Z).
• It also provides a new development branch to the
  OBEX based deployment, which can be used e.g.
  towards to MAC OS environment. Thus this requires
  that the needed protocols / protocol wrappers are
  available.

52
Mobile Vendor specific view
Eclipse
Vendor X SDK Emulator Plug-in
SDK / Emulator (Vendor X)
MTJ Plug-in
Vendor Y SDK Emulator Plug-in
SDK / Emulator (Vendor Y)
Device Platform
Vendor Z SDK Emulator Plug-in
SDK / Emulator (Vendor Z)
Extension point
Vendor X Real Device Plug-in
Real Device (Vendor X)
Vendor Y Real Device Plug-in
Real Device (Vendor Y)

• The MTJ provides an Deployment framework that
  supports the existing SDK Emulators and phones
  runtimes
• The framework publishes a Device Platform
  -interface, that capsulate (hides) the actual
  runtime environments and protocols.
• The framework separates the different vendors
  products to own plug-ins

53
Mobile vendor specific view details

• Different mobile vendors can use their existing
  emulators and add the deployment (emulator)
  specific plug-in to the MTJ environment. The
  emulator specific plug-in may be even in binary
  format, if it needs to protect some internal
  implementation or specification.
• The emulator specific plug-in uses the MTJ
  generic API and also contributes to the MTJs
  deployment frameworks extension point.
• The deployment framework could provide an
  template from such plug-in that helps to other
  vendors to tie up their specific solutions.
• The deployment framework supports also that the
  emulator is discovered by manual entering the
  location. There could be a dynamic plug-in, that
  ties the discovered emulator to the deployment
  framework.
• The deployment framework can provide also other
  extension points, that enables others to extend
  e.g. the emulator specific properties, UIs etc.
• The deployment framework provides a plug-in
  template for existing emulators, which can
  dynamically be attached to wrap the specific
  emulator.

54
Deployment framework plug-ins

• Device Platform plug-ins have several different
  implementations
• Device Platform plug-ins are responsible of the
  communication protocols between MTJ environment
  and Emulators / Real Devices
• The plug-ins also store all config data. F. ex.
  Emulator plug-in stores the Emulator SDK root
  directory itself
• UEI Unified Emulator Interface
• XEI Extended Emulator Interface (Nokia
  proprietary)
• X Proprietary Emulator Interface

MTJ plug-in wrapper
Mobile vendors devices
SDK / Emulator (Vendor X)
Vendor X SDK Emulator Plug-in
U EI
SDK / Emulator (Vendor Y)
Vendor Y SDK Emulator Plug-in
X EI
SDK / Emulator (Vendor Z)
Vendor Z SDK Emulator Plug-in
X
Vendor X Real Device Plug-in
O B E X
Real Device (Vendor X)
Vendor Y Real Device Plug-in
HTTP/FTP service
Real Device (Vendor Y)
Vendor Z Real Device Plug-in
Real Device (Vendor Z)
55
Deployment framework design

• Integrating to the existing SDK Emulators
• Deployment framework
• Enables adding a new SDK Emulator by manually
  entering the location or by local hard drive
  browsing (typical case for existing emulators).
• Hides the used targeted runtime environments
  behind a few deployment interfaces
• Simplifies the deployment process against the
  device / emulator variation
• Generalizes the deployment management by
  encapsulating the SDK Emulator dependencies to a
  separate plug-ins, thus enabling it to publish
  its own specific functionality.
• Integrating to new SDK Emulators, which do have a
  specific plug-in
• Deployment framework
• If the SDK Emulator has own deployment plug-in
  and the plug-in does follow the Deployment
  framework extension rules, its automatically
  instantiated
• Deployment framework instantiates Deployment
  component and calls its methods via deployment
  interface
• Deployment component plug-in
• Implements the Deployment frameworks interface
• Contributes to the Deployment frameworks
  extension point
• May also extend some SDK Emulator specific
  services to the Deployment framework

56
Deployment framework Model
Device Platform
Runtime Platform Definition
Device
1..n
Real Device
Emulator Device
1

• Target environments are seen as Device Platforms
  by the MTJ environment. Device Platform contains
  one or more Device instances.
• MTJ plug-in doesnt know if the Devices are
  device emulators or real devices because the
  plug-in extension point API hides all
  implementation details.
• Device instance defines the Runtime Platform
  that its capable to run on.

57
Deployment framework Model (cont.)
Deployment
i/f
CDC Deployment
MEGlet Deployment
Resource Deployment
MIDlet Deployment

• Deployment interface is generic representation
  of a entity that is send from MTJ environment to
  Device Platform instances.
• Realization of a deployment can be MIDlet, CDC,
  MEGlet or Resource deployment (or something
  else). So the realization is created from source
  application definitions and f. ex. MIDlet project
  deployment consists of Application JAR and JAD
  files.
• Target Device Platform knows, whats inside the
  received deployment and how to handle it.

58
Signing and Obfuscation

• Signing and Obfuscating internal architecture

59
Signing architecture

• There is a SecurityManager, that manages the keys
  and certificates in the IDE environment globally.
• Each project can configure the signing options
  and parameters against the actual needs.
• The Signing Provider implements the actual
  signing and it can be used through e.g. the Ant
  scripts.

60
Obfuscating architecture

• It is a well known fact that Java Class
  (bytecode) files can be easily reverse-engineered
  because Java compiler leaves a lot of such
  information into bytecode that helps the
  reverse-engineering task. Code obfuscation is
  one protection tool for Java code to prevent
  reverse engineering. Code obfuscation makes
  programs more difficult to understand, so that it
  is more resistant to reverse engineering.
• Obfuscation techniques fall into three groups
• Layout Obfuscations
• Layout Obfuscations modify the layout structure
  of the program by two basic methods renaming
  identifiers and removing debugging information.
  Almost all Java obfuscators contain this
  technique.
• Control Obfuscations
• Control Obfuscations change the control flow of
  the program.
• Data Obfuscations
• Data Obfuscations break the data structures used
  in the program and encrypt literal.
• The MTJ enables to use existing Obfuscator
  -products through an wrapper plug-in (Obfuscation
  Provider), that can be further tailored.

61
Backup slides - GUI

• Mobile Visual Editor architecture

62
Visual IDE environment in general
The RAD IDE environment is having some clear
elements, like the core IDE graphical and code
editor, property sheet and outline viewer for IDE
environment objects. Also the graphical editor
uses the screen engine for creating the actual
graphical UI presentation (like WYSIWYG). Also
the mobile emulators / SDKs are providing the
ability to launch the applications.
Eclipse Platform
IDE
Screen Engine
Graphical Editor
Code / Resource Editor
UI,WYSIWYG
Property Sheet
Outline Viewer
Launcher / Emulator
Source code, resource files, etc.
Trace, profile, debug
63
VE Internal Component Architecture
The Eclipse Visual Editor framework provides a
flexible GUI framework, which can be quite easily
extended to e.g. mobile domain. The current
desktop version supports JFC and SWT GUI editors
with full set of UI widgets. The actual screen
rendering is done in separate rendering
engine. Internally VE uses EMF in CDE and models
the Java source in JEM.
Eclipse Platform
Eclipse Visual Editor Framework
JFC Editor
SWT Editor
Java core
Java Element Model(JEM)
Common Diagram Model (CDE)
Java Code Generation Adapter
EMF
GEF
64
Mobile Visual Editor GUI Components
Eclipse MTJ IDE
MTJ Screen Engine
Custom Mobile proxy components
Mobile eSWT proxy components
Mobile CLDC proxy components
MTJ CDLC UI components
MTJ eSWT UI components
MTJ eSWT UI components
Custom UI Look Feel
Eclipse VE
MTJ Mobile Extension
GEF EditorPart
UI VE Model
Custom Screen Rendering Engine
Screen Rendering Context
BeanInfo Adapter
Eclipse Platform
65
Backup slides Milestone Plan
66
MTJ Milestone Plan

• tbd