Transcript Mobile_Tools_for_Java_platform_arch_v086

Mobile Tools for
Java 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)
1
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
17.02.2006











Wizards
Runtime Launch
Debugging
Code Editor
Deployment
Device Management
Signing and Obfuscation
Localization
Application Flow
GUI Editor
Backup slides
2
Eclipse High-level Architecture
Ecosystem
Vertical Industry Initiatives
Enterprise
Domain
Internet
Domain
Desktop
Domain
Embedded
Domain
Mobile
Domain
Data
Management
Modeling
Tools
Embedded &
Mobile Tools
Web Tools
Service
Oriented
Architecture
Java Dev.
Tools
C/C++ Dev.
Tools
Test and
Performance
Business
Intelligence &
Reporting
System
Management
Horizontal
Technologies
Technology
Enablers
Frameworks
Modeling Frameworks
Graphical Frameworks
UI Frameworks
Workspace
Project Model
Update
Runtime
Workbench
SWT
17.02.2006
Multi-language
support
Tools
Platform
Rich Client Platform
3
Java Runtime Environments
Legend
Enterprise
Desktop
High-end
devices
Low-end
devices
Smart
Cards
Optional
packages
Optional
packages
J2EE
J2SE
J&C and MTJ
runtime
scope
Optional
packages
Personal
profile
Not used Java
runtime
Optional
packages
Foundation
profile
MIDP
CDC
CLDC
Java
Card
KVM
Card VM
Java Virtual Machine
Java JRE
runtime
dependencies
Java Micro Edition (J2ME)
The MTJ projects focus in Mobile runtimes is in the J2ME area.
17.02.2006
4
MTJ Ecosystem
Download /
Update sites
Eclipse
Eclipse
U
E
I
API
JavaDocs
MTJ
API
Sun / IBM
API
JavaDocs
(tooling runtime
Vendor Y SDK
JRE 5.0 / J9 )
X
A List of
JVMS
U
E
I
Vendor X
(for SDK download)
Vendor X SDK
Different
vendor
products
based
on Eclipse
MTJ
JavaDocs
API
Tooling Runtimes
JRE 1.4 .. 5.0, J9
Operating Systems: Win32,
Linux, MAC.
Vendor Y
(for SDK download)
API
Real Device
JavaDocs
MTJ context
17.02.2006
Generic SDK
5
MTJ high-level layers
Mobile IDE Components
Device
Platform
Provider
Device
Description
Provider
Obfuscation
Provider
Packaging
Provider
Signing
Provider
Device
Platform
Provider
GUI Builder
Provider
Preprocessing
Provider
Build
Provider
Deployment
Provider
Ant Provider
x
Mobile IDE Extensibility Framework Layer
Runtime
Management
Build
Management
Deployment
Management
Device
Management
GUI Builder
Management
Security
Management
Eclipse Tool Services
Visual
Editor
Web Tools
Project
GEF
Data Tools
Multimedia
Tools
Multilanguage
support
Graphical
Modeling
Framework
BIRT
Testing &
Profiling
Tools
Workflow
Toolbox
Eclipse Modeling Framework
EMF
OSGI
SWT
Workbench
JDT
Eclipse Platform
Operating Systems: Win32, Linux, MAC
17.02.2006
6
MTJ Development by Milestone
Create
Application
Code
Packaging
Build
Create
Class
Create
Project
Deployment
Symbian
templates
Project
Provider Components
Build
Obfuscation
providers
Audio
converter
Flow Editor
Code Editor
Signing
provider
Custom
Components
LCDUI
Editor
J2ME
project
builders
Deployment
providers
Localization
eSWT
Editor
Preprocessing
JAD Editor
Legend
1st Iteration
nd
2
Snippets
Iteration
Xx
Editor
1st Release
Device
Packaging
Debugging
Desktop
Game Editor
Other
J2ME
Nature
Create UI
Runtime launch
Desktop
GUI builders
Mobile RAD / IDE
Wizards
Mobile SDK
Emulator
Help
Future design
Antenna
provider
Device
IDE Extensible Framework Layer
Device
Management
Framework
Build Framework
Deployment
Framework
Runtime
Management
Framework
GUI Builder
Framework
Security
Management
Framework
Eclipse Platform
17.02.2006
7
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
Varying
devices
17.02.2006
Differing
assets
Operator
requirements
Huge amount of
configurations
8
Device fragmentation, Mobile value chain
Application
Developers
Content
aggregators and
Distributor
End-user /
consumer
Network operators
Infrastructure
providers
Legend
Information exchange
Retail
Device
manufactures
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 it’s
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.
Cash flow exchange
17.02.2006
9
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,
Can be seen as one definition
that can be used e.g. in pre-processing.
1
Device
i/f
Device Platform
1..n
Emulator
Real
Device
Device
1
17.02.2006
Runtime Platform
Definition
Fragmentation
Definition
10
Automated & manual testing

Tdb.
17.02.2006
11
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.
17.02.2006
12
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.
17.02.2006
13
Runtime Launch
17.02.2006
14
Debugging
17.02.2006
15
Code Editor

The MTJ code editor is based on the Eclipse
JDT base functionalities.
JDT
The JDT (Java Development Tools) subsystem consists of integrated tools for developing, testing,
and debugging Java (J2SE) applications. The JDT project is managed as part of the Eclipse
Platform top level project.
The JDT Core component defines the non-UI infrastructure for compiling and analyzing Java code.
The JDT UI component provides the user interface elements (wizards, views, editors) and
infrastructure for editing, refactoring, browsing, and searching Java code. The JDT Debug
component handles everything related to running and debugging Java programs.
<<subsystem>>
JDT
Core
17.02.2006
Debug
UI
16
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
Vendor X
Eclipse
SDK Emulator
SDK / Emulator (Vendor X)
Plug-in
Vendor Y
Device
Platform
MTJ
SDK Emulator
Vendor Z
SDK Emulator
Plug-in
Extension
point
SDK / Emulator (Vendor Y)
Plug-in
SDK / Emulator (Vendor Z)
Plug-in
Vendor X
Real Device
Real Device (Vendor X)
Plug-in
Vendor Y
Real Device
Real Device (Vendor Y)
Plug-in
17.02.2006
17
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
i/f
Device Platform
1..n
Can be seen as one definition
Device
1
Emulator
Real
Device
Device
1
17.02.2006
Runtime Platform
Definition
Fragmentation
Definition
18
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.
17.02.2006
19
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 won’t 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.
17.02.2006
20
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.
17.02.2006
21
GUI Editor





The Eclipse Visual Editor provides an extensible GUI framework, that can
be used in the mobile IDE UI area.
Why VE: The VE’s 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 doesn’t provide any multimedia services yet.
17.02.2006
22
Backup slides
More detail presentation about
the top technical items
23
Backup slides –
Device Fragmentation
24
Device Platform
i/f
Device Platform
1..n
Device
Emulator
Real
Device
Device
• Target environments are seen as Device Platforms by the MTJ environment. Device
Platform contains one or more Device instances.
• MTJ plug-in doesn’t know if the Devices are device emulators or real devices because the
plug-in extension point API hides all implementation details
17.02.2006
25
Device Platform, Device Platform Services
i/f
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 it’s possible to get Devices or the Platform.
17.02.2006
26
Device fragmentation
APIs
Project
APIs
DP
DP
DC
DC
Device
Device
Management
• 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.
17.02.2006
27
Device fragmentation, Device Services
i/f
Device Services
getDevices(DeviceConfiguration dc, DeviceProfile dp,
ServiceAPI[] apis) : Device[]
...
• Device Services make it possible to query Devices that are possible targets to the Project’s
application. Project uses it’s own definitions as parameters in the service call.
17.02.2006
28
Backup slides Wizards
Wizards internal architecture
29
Wizards architecture

[template management]…
17.02.2006
30
Backup slides Runtime Launch
Runtime Launch internal
architecture
31
Runtime Launch architecture

The Runtime Launch architecture uses the
Device Platform to enable selection of
available Devices.
17.02.2006
32
Runtime Platform
Device
1..n
Runtime Platform Definition
1
1
DC
Device Configuration
DP
Device Profile
1..n
API
Service API
1
JVM Impl.
• Device instance defines the Runtime Platform Definitions that it’s 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 it’s version.
• Device Profile defines used profile (i.e. MIDP) and it’s version.
• Service APIs are either APIs that are defined in Device Profile or API of optional Services that the
Device’s OS is supporting.
• Runtime Platform Definition is always based on defined Mobile SDK JVM Implementation.
17.02.2006
33
Runtime Platform (cont.)
API
Service API
1
Library Jar
JVM Impl
1
Library Jar
• Service API –object contains the standardize service name and it’s 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 it’s version and reference to
JAR Library that implements the JVM specification that is defined by the Runtime Platform’s
Device Configuration Specification.
17.02.2006
34
Runtime Platform, Device Services
i/f
Device Services
getRuntimePlatforms(String devicePlatformName,
String deviceName) : RuntimePlatformDefinition[]
...
• Device Services make it possible to query Runtime Platforms of a Device.
17.02.2006
35
Backup slides Debugging
Debugging internal architecture
36
Debugging architecture

…
17.02.2006
37
Backup slides Device Management
Device Management internal
architecture
38
Device Management architecture
Mobile
Project
1..n
i/f
Device Platform
1..n
Extended device definition
Device
1
Emulator
Real
Device
Device
1




Runtime Platform
Definition
Fragmentation
Definition
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.
17.02.2006
39
Device Management
<< extension point >>
Device Description
Provider
<< extends> >
Device Description
Implementation
Device Description
Implementation
<< extension point >>
<< extension point >>
Device
Management
<< extends> >
Device Management
Implementation
Device Platform
Provider
<< extends> >
Device Platform
Device Platform
Device Platform
• Target environments are seen as Device Platforms by the MTJ environment. Device
Platform contains one or more Device instances.
• MTJ plug-in doesn’t 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 it’s 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
17.02.2006
40
Device Management control flow
Device Management
Implementation
Out
MTJ Core Plugin
Device Platform
Device Description
Impl.
1: getImplementations(“Device Management”)
return: DeviceManagement [ ]
2: getDevices(devicePlatformName)
3: getImplementations(“Device Platform”)
return: DevicePlatformProvider [ ]
4: getDevices()
return: Device [ ]
5: getImplementations(“Device Description”)
return: DeviceDescriptionProvider [ ]
6: getDeviceDescription( String vendor, String model)
return: DeviceDescription
return: Device [ ]
17.02.2006
41
Device Platform, Device Platform Services
i/f
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 it’s possible to get Devices or the Platform.
17.02.2006
42
Device Platform
DevicePlatform
getName() : String
getDevices() : Device[]
getConfiguration() : PlatformConfiguration
setConfiguration(PlatformConfiguration config)
deploy(Deployment application, DeviceDeployment[] devices)
run(String application, String deviceName)
debug(String application, String deviceName, DebugConfiguration debugConfig)
isDebugEnabled() : boolean
isAccessable() : boolean
getTypeInfo() : DevicePlatformType
openPreferencesDialog()
isPreferencesDialogAvailable() : boolean
openUtilitesDialog()
isUtilitesDialogAvailable() : boolean
getRuntimePlatformDefinitions() : RuntimePlatformDefinition[]
1
DevicePlatformType
type
1
Configuration
1..*
Runtime Platform Definition
name
1..*
1..*
0..*
Device
name : String
description : String
17.02.2006
ConfigurationError
errorType
description
ConfigurationItem
name
+item label
description
1 value
validValues : String[]
43
Device
Screen
width
height
isColor
bitDepth
isTouch
Device
+screen
name : String
description : String
1
1..*
1..*
DeviceCommunicationProtocol
+runtimes
1
1..*
Configuration
Runtime Platform Definition
name
1..*
0..*
ConfigurationError
errorTy pe
description
17.02.2006
ConfigurationItem
name
+item label
description
1 v alue
v alidValues : String[]
44
Runtime Platform
Device
1..*
name : String
description : String
+runtimes
ImplementationRef
1..*
Runtime Platform Definition
0..*
supports
EmulatorDevice
fileRef : String
sourceRef : String
javadocRef : String
name
1..*
RealDevice
model
1
+apis
DeviceProfile
JVM Ref
name
profile name
profile version
fileRef : String
sourceRef : String
javadocRef : String
1..*
Java API
name
version
defines
1..*
isExpanding
DeviceProfileAPI
OptionalServiceAPI
1
1
1
JavaVirtualMachine
Specification
defines
1
1..*
Device OS Application UI
DeviceConfiguration
Specification
0..1
name
configuration name
configuration version
(from mtj)
1..*
+specification
1
Device OS Application
0..*
implements
+javaRuntime
1..*
0..*
1
JavaVirtualMachine Implementation
(from mtj)
1..*
17.02.2006
1
isUsing
DeviceComfiguration Implementation
(from mtj)
Device OS
name
version
1
0..*
45
Project
Java API
name
version
1..*
ImplementationRef
+apis
fileRef : String
sourceRef : String
javadocRef : String
DeviceConfiguration Specification
name
configuration name
configuration version
1
1..*
DeviceProfile
Runtime Platform Definition
name
Project
1 name
profile name
profile version
1
+runtimes
1..*
0..*
1..*
Device
1..*
name : String
description : String
1
JVM Ref
fileRef : String
sourceRef : String
javadocRef : String
+javaRuntime
1
JavaVirtualMachine Implementation
17.02.2006
46
Code Editor
Code Editor internal architecture
47
Code Editor architecture

tbd
17.02.2006
48
Project
LEGEND:
APIs
APIs
Project
DC
DP
DC
1..n
1
Library Jar
Library Jar
DP
Device
DP
•Project’s defined Device
Profile
APIs
•Service APIs that are
selected to the Project
DC
DC
DP
1
•Project’s defined Device
Configuration
1
APIs
•Device’s Device
Configuration
•Device’s Device Profile
•Service APIs that are
supported by the Device
Mobile SDK Emulator
• Mobile Project development is targeted to devices that have certain Device Configuration and Device
Profile. Therefore MTJ’s Project has also Device Configuration and Device Profile defined.
• It’s 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.
17.02.2006
49
Backup slides Deployment
Deployment Framework internal
architecture
50
Deployment framework architecture
MTJ IDE environment
U
E
I
U
E
I
SDK / Emulator (Vendor X)
LEGEND:
• MTJ Editor context
X
Deployment
Framework
Interface
Extension
point
• Deployment context
X
Z
O
T
A
O
B
E
X
U
E
I
SDK / Emulator context
(Nokia, Win32 OS)
X
Real
Device
Interface
S40
S60
• Existing SDK /
Emulators
• Existing emulator
integrations
• Deployment Interface
• Eclipse Plug-in
Extension point
• New, open deployment
plug-in, OBEX based
• Mobile Devices
• Existing native
deployment
• 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.
17.02.2006
51
Mobile Vendor specific view
Vendor X
Eclipse
SDK Emulator
SDK / Emulator (Vendor X)
Plug-in
Vendor Y
Device
Platform
MTJ
SDK Emulator
Plug-in
Vendor Z
SDK Emulator
Plug-in
Extension
point
SDK / Emulator (Vendor Y)
SDK / Emulator (Vendor Z)
Plug-in
Vendor X
Real Device
Real Device (Vendor X)
Plug-in
Vendor Y
Real Device
Real Device (Vendor Y)
Plug-in
• 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
17.02.2006
52
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 MTJ’s 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, UI’s etc.
The deployment framework provides a plug-in template for existing
emulators, which can dynamically be attached to wrap the specific
emulator.
17.02.2006
53
Deployment framework plug-ins
MTJ plug-in wrapper
Vendor X SDK Emulator
Plug-in
Vendor Y SDK Emulator
Plug-in
Mobile vendors devices
U
E
I
U
E
I
SDK / Emulator (Vendor X)
X
E
I
X
E
I
SDK / Emulator (Vendor Y)
X
X
SDK / Emulator (Vendor Z)
Vendor Z SDK Emulator
Plug-in
O
B
E
X
Vendor X Real Device
Plug-in
Real Device (Vendor X)
• 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
Vendor Y Real Device Plug-in
HTTP/FTP
service
O
T
A
Real Device (Vendor Y)
• UEI = Unified Emulator Interface
• XEI = Extended Emulator Interface (Nokia
proprietary)
• X = Proprietary Emulator Interface
Vendor Z Real Device Plug-in
Real Device (Vendor Z)
FTP
HTTP/FTP
service
17.02.2006
FTP
O
T
A
54
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 it’s 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, it’s 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
17.02.2006
55
Deployment framework Model
i/f
Device Platform
1..n
Device
1
Emulator
Real
Device
Device
Runtime Platform
Definition
• Target environments are seen as Device Platforms by the MTJ environment. Device Platform
contains one or more Device instances.
• MTJ plug-in doesn’t 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 it’s capable to run on.
17.02.2006
56
Deployment framework Model (cont.)
i/f
Deployment
MIDlet
CDC
MEGlet
Resource
Deployment
Deployment
Deployment
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, what’s inside the received deployment and how to handle it.
17.02.2006
57
Signing and
Obfuscation
Signing and Obfuscating internal
architecture
58
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.
17.02.2006
59
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


Control Obfuscations


Control Obfuscations change the control flow of the program.
Data 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.
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.
17.02.2006
60
Backup slides - GUI
Mobile Visual Editor architecture
61
Visual IDE environment in general
IDE
Screen Engine
Graphical
Editor
Code /
Resource
Editor
Property
Sheet
Outline
Viewer
UI,
WYSIWYG
Launcher / Emulator
Source code, resource files, etc.
Trace,
profile,
debug
Source files
Eclipse Platform
17.02.2006
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.
62
VE Internal Component Architecture
Eclipse Visual Editor Framework
JFC
Editor
SWT
Editor
Java
core
Target VM
Java
Element
Model
(JEM)
Common
Diagram
Model
(CDE)
GEF
Local or
Remote
Java VM
BeanInfo
VM
Java Code
Generation
Adapter
EMF
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.
Java source files
Eclipse Platform
17.02.2006
63
Mobile Visual Editor GUI Components
Eclipse MTJ IDE
eSWT Screen
Rendering Engine
Custom UI
Look & Feel
Custom UI
components
Custom UI
Look & Feel
Custom UI
Components
MTJ eSWT UI
components
MTJ eSWT UI
components
17.02.2006
Custom UI
Look & Feel
Eclipse Platform
Screen Rendering API
Eclipse VE
CLDC Screen
Rendering Engine
Screen Rendering API
BeanProxy
Adapter
Custom UI
Components
UI VE Model
CDLC UI base
Look & Feel
MTJ CDLC UI
components
Custom
Mobile proxy
components
Mobile
eSWT proxy
components
Mobile
CLDC proxy
components
GEF EditorPart
MTJ project
scope
MTJ Screen Engine
MTJ Mobile Extension
Legend
Existing in
Eclipse
Custom Screen
Rendering Engine
Common Screen Rendering Engine
BeanInfo
Adapter
Screen Rendering Context
64
Backup slides –
Milestone Plan
65
MTJ Milestone Plan

tbd
17.02.2006
66