Mobile tools for java platform
Download
1 / 66

Mobile Tools for Java Platform - PowerPoint PPT Presentation


  • 425 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Mobile Tools for Java Platform' - phong


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Mobile tools for java platform

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)


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

Contents


Eclipse high level architecture
Eclipse High-level Architecture

Ecosystem

Vertical Industry Initiatives

Horizontal Technologies

Enterprise Domain

Internet Domain

Desktop Domain

Mobile Domain

Embedded Domain

Technology Enablers

Data Management

Modeling Tools

Web Tools

Service Oriented Architecture

Embedded & Mobile Tools

Java Dev. Tools

C/C++ Dev. Tools

Business Intelligence & Reporting

Test and Performance

System Management

Frameworks

UI Frameworks

Modeling Frameworks

Graphical Frameworks

Tools Platform

Multi-languagesupport

Update

Workspace

Project Model

Rich Client Platform

SWT

Runtime

Workbench


Java runtime environments

Legend

Java JRE runtime dependencies

J&C and MTJruntime scope

Not used Javaruntime

Java Runtime Environments

Enterprise

Desktop

Low-enddevices

SmartCards

High-enddevices

Optionalpackages

Optionalpackages

Optionalpackages

Optionalpackages

Personalprofile

Foundationprofile

MIDP

J2EE

J2SE

JavaCard

CDC

CLDC

Card VM

KVM

Java Virtual Machine

Java Micro Edition (J2ME)

The MTJ projects focus in Mobile runtimes is in the J2ME area.


Mtj ecosystem

Vendor X SDK

UEI

JavaDocs

API

Vendor Y SDK

X

UEI

JavaDocs

API

Generic SDK

API

JavaDocs

Real Device

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)


Mtj high level layers
MTJ high-level layers

Mobile IDE Components

Device Platform Provider

Device Description Provider

Device Platform Provider

Obfuscation Provider

Signing Provider

Packaging Provider

GUI Builder Provider

Pre-processing Provider

x

Build Provider

Ant Provider

Deployment Provider

Mobile IDE Extensibility Framework Layer

Runtime Management

Build Management

Security Management

Deployment Management

GUI Builder Management

Device Management

Eclipse Tool Services

Multimedia Tools

Data Tools

Visual Editor

Web Tools Project

GEF

Graphical Modeling Framework

Multi-language support

BIRT

Workflow Toolbox

Testing & Profiling Tools

Eclipse Modeling Framework

EMF

Eclipse Platform

OSGI

SWT

Workbench

JDT

Operating Systems: Win32, Linux, MAC


Mtj development by milestone

Legend

1st Iteration

2nd Iteration

1st Release

Future design

MTJ Development by Milestone

Mobile SDK Emulator

Mobile RAD / IDE

GUI builders

Wizards

Provider Components

Game Editor

Create Application

Code Packaging

Build

Other

Build

Project

Audio converter

Obfuscation providers

J2ME Nature

Flow Editor

Create Project

Deployment

Create Class

Code Editor

CustomComponents

Signing provider

LCDUI Editor

Create UI

Symbian templates

J2ME project builders

Localization

Deployment providers

eSWT Editor

Snippets

JAD Editor

Pre-processing

Xx Editor

Runtime launch

Device

Desktop

Help

Packaging

Debugging

Antenna provider

Device

Desktop

IDE Extensible Framework Layer

Runtime Management Framework

Security Management Framework

Device Management Framework

Build Framework

Deployment Framework

GUI Builder Framework

Eclipse Platform


Device fragmentation
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


Device fragmentation mobile value chain

Legend

Information exchange

Cash flow exchange

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

Application Developers

Content aggregators and Distributor

End-user / consumer

Network operators

Retail

Infrastructure providers

Device manufactures


Device fragmentation pre processing

Device Platform

Runtime Platform Definition

Device

Can be seen as one definition

Fragmentation Definition

Real

Device

Emulator

Device

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



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


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




Code editor
Code Editor

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


Deployment and runtime management
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)


Device management

Device Platform

Device

Real

Device

Emulator

Device

Runtime Platform Definition

Can be seen as one definition

Fragmentation Definition

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


Signing and obfuscation
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.


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


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


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


Backup slides

Backup slides

More detail presentation about the top technical items



Device platform

Device Platform

Device

Real

Device

Emulator

Device

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 doesn’t know if the Devices are device emulators or real devices because the plug-in extension point API hides all implementation details


Device platform device platform services

Device Platform Services

Device Platform, 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.


Device fragmentation1

DP

DP

DC

APIs

DC

APIs

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.


Device fragmentation device services

Device Services

Device fragmentation, 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.


Backup slides wizards

Backup slides - Wizards

Wizards internal architecture


Wizards architecture
Wizards architecture

  • [template management]…


Backup slides runtime launch

Backup slides - Runtime Launch

Runtime Launch internal architecture


Runtime launch architecture
Runtime Launch architecture

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


Runtime platform

API

DP

DC

Device Configuration

Device Profile

Service API

Runtime Platform

Device

Runtime Platform Definition

1..n

JVM Impl.

1

1

1..n

1

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


Runtime platform cont

API

Service API

Runtime Platform (cont.)

JVM Impl

Library Jar

Library Jar

1

1

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


Runtime platform device services

Device Services

Runtime Platform, Device Services

getRuntimePlatforms(String devicePlatformName,

String deviceName) : RuntimePlatformDefinition[]

...

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


Backup slides debugging

Backup slides - Debugging

Debugging internal architecture



Backup slides device management

Backup slides - Device Management

Device Management internal architecture


Device management architecture

Device

Real

Device

Emulator

Device

Runtime Platform Definition

Extended device definition

Fragmentation Definition

Device Platform

Device Management architecture

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

Mobile Project

1..n

1..n

1

1


Device management1
Device Management

Device Description Provider

Device Platform Provider

Device Management

<< extension point >>

<< extension point >>

<< extension point >>

Device Management Implementation

Device Platform

Device Description Implementation

<< extends> >

<< extends> >

<< extends> >

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


Device management control flow

Device Management Implementation

Device Description Impl.

Out

MTJ Core Plug-in

Device Platform

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 [ ]

Device Management control flow


Device platform device platform services1

Device Platform Services

Device Platform, 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.






Code editor1

Code Editor

Code Editor internal architecture



Project1

DP

APIs

APIs

DC

APIs

DP

DP

DC

DC

Project

  • LEGEND:

Device

Project

APIs

  • Project’s defined Device Configuration

  • Project’s defined Device Profile

  • Service APIs that are selected to the Project

  • Device’s Device Configuration

  • Device’s 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 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.


Backup slides deployment

Backup slides - Deployment

Deployment Framework internal architecture


Deployment framework architecture

  • LEGEND:

    • MTJ Editor context

    • Deployment context

    • 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

X

UEI

X

UEI

Real Device

O B E X

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.


Mobile vendor specific view
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


Mobile vendor specific view details
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.


Deployment framework plug ins

X

UEI

XEI

FTP

FTP

OTA

OTA

HTTP/FTP service

Deployment framework plug-ins

MTJ plug-in wrapper

  • 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

Mobile vendors devices

Vendor X SDK Emulator

Plug-in

U EI

SDK / Emulator (Vendor X)

Vendor Y SDK Emulator

Plug-in

X EI

SDK / Emulator (Vendor Y)

Vendor Z SDK Emulator

Plug-in

X

SDK / Emulator (Vendor Z)

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)


Deployment framework design
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


Deployment framework model

Device Platform

Deployment framework Model

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


Deployment framework model cont

Deployment

Deployment framework Model (cont.)

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, what’s inside the received deployment and how to handle it.


Signing and obfuscation1

Signing and Obfuscation

Signing and Obfuscating internal architecture


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


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


Backup slides gui

Backup slides - GUI

Mobile Visual Editor architecture


Visual ide environment in general

Source files

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


Ve internal component architecture

Local or Remote Java VM

Target VM

BeanInfo VM

Java source files

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

SWT Editor

JFC Editor

Java core

Java Element Model(JEM)

Common Diagram Model (CDE)

Java Code Generation Adapter

EMF

GEF


Mobile visual editor gui components

Legend

Existing in Eclipse

MTJ projectscope

Custom UI Components

Custom UI Look & Feel

Custom UI Components

CDLC UI base Look & Feel

Custom UI Look & Feel

Custom UI components

eSWT Screen Rendering Engine

CLDC Screen Rendering Engine

Screen Rendering API

BeanProxy Adapter

Screen Rendering API

Common Screen Rendering Engine

Mobile Visual Editor GUI Components

Eclipse MTJ IDE

MTJ Screen Engine

Custom Mobile proxy components

Mobile CLDC proxy components

Mobile eSWT proxy components

MTJ CDLC UI components

Custom UI Look & Feel

MTJ eSWT UI components

MTJ eSWT UI components

Eclipse VE

MTJ Mobile Extension

UI VE Model

GEF EditorPart

Custom Screen Rendering Engine

Screen Rendering Context

BeanInfo Adapter

Eclipse Platform




ad