Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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