SynapseIndia Mobile Apps

Deployment framework architecture

Deployment framework architecture

MTJ IDE environment

U
E
I

U
E
I

SDK / Emulator (Vendor X)

LEGEND:
MTJ Editor context

X
Deployment
Framework

Interfac
e

Extensio
n
point

Deployment context

O
T
A
O
B
E
X

U
E
I

SDK / Emulator context

(Nokia, Win32 OS)

Real
Devic
e

Interfac
e

S40
S60

Existing SDK /
Emulators
Existing emulator
integrations
Deployment
Interface

Eclipse Plug-in
Extension point
New, open
deployment plug-in,
OBEX based
Mobile Devices

The MTJ provides an Deployment framework that supports the existing SDK
Existing native
Emulators and phones runtimes.
deployment
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.
2
17.02.2006

Mobile Vendor specific view

Vendor X

Eclipse

SDK Emulator

SDK / Emulator (Vendor X)

Plug-in
Vendor Y
Device

Platform

MTJ

SDK Emulator

SDK / Emulator (Vendor Y)

Plug-in
Vendor Z
SDK Emulator

Plug-in
Extensio
n
point

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
3

17.02.2006

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.

17.02.2006

Deployment framework plug-ins

MTJ plug-in wrapper
Vendor X SDK Emulator
Plug-in
Vendor Y SDK Emulator
Plug-in

Mobile vendors devices Device Platform plug-ins have

U
E
I

U
E SDK / Emulator (Vendor X)
I

X
E
I

X
E SDK / Emulator (Vendor Y)
I

X SDK / Emulator (Vendor Z)

Vendor Z SDK Emulator

Plug-in
Vendor X Real Device
Plug-in

O
B
E
X

Real Device (Vendor X)

Vendor Y Real Device Plug-in

HTTP/FTP
service

O
T
A

Real Device (Vendor Y)

Vendor Z Real Device Plug-in

Real Device (Vendor Z)

FTP

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

HTTP/FTP
service

FTP
O
T
A

17.02.2006

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

17.02.2006

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 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.
7

17.02.2006

Deployment framework Model (cont.)

i/f

Deployment

MIDlet

CDC

MEGlet

Resource

Deploymen
Deployment Deployment Deployment
t

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.
8

17.02.2006

Signing and
Obfuscation
Signing and Obfuscating internal
architecture
9

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.

10

17.02.2006

Obfuscating architecture

It is a well known fact that Java Class (bytecode) files can be easily reverseengineered 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.
11

17.02.2006

Backup slides - GUI

Mobile Visual Editor architecture

12

Visual IDE environment in general

IDE

Screen Engine

Graphica
l Editor

Code /
Resourc
e Editor

Property
Sheet

Outline
Viewer

UI,
WYSIWYG

Launcher /
Emulator

Source code, resource files, etc.

Trace,
profile,
debug

Source files

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

13

17.02.2006

VE Internal Component Architecture

Eclipse Visual Editor Framework
JFC
Editor

SWT
Editor

Target
VM

Java
core

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

14

17.02.2006

Mobile Visual Editor GUI Components

Eclipse MTJ IDE

Custom UI
Look & Feel

eSWT Screen
Rendering
Engine

Custom UI
components

Custom UI
Look & Feel

Custom UI
Components

MTJ eSWT UI
components

MTJ eSWT UI
components

Custom UI
Look & Feel

Eclipse Platform

CLDC Screen
Rendering
Engine

Screen Rendering API

Eclipse VE

Screen Rendering API

BeanProx
y 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

15

17.02.2006

Backup slides
Milestone Plan

16

MTJ Milestone Plan

tbd

17

17.02.2006