Mobile Tools for Java Platform

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

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

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

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

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

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

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

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

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

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

11. Automated & manual testing • Tdb.

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

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

14. Runtime Launch

15. Debugging

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

17. Deployment and Runtime management • The MTJ provides an Deployment and DevicePlatform frameworks that supports the existing SDK Emulators and phones runtimes • The framework publishes a Device Platform -interface, that capsulate (hides) the actual runtime environments and protocols. • The framework separates the different vendors products to own plug-ins Eclipse Vendor X SDK Emulator Plug-in SDK / Emulator (Vendor X) MTJ Plug-in Vendor Y SDK Emulator Plug-in SDK / Emulator (Vendor Y) Device Platform Vendor Z SDK Emulator Plug-in SDK / Emulator (Vendor Z) Extension point Vendor X Real Device Plug-in Real Device (Vendor X) Vendor Y Real Device Plug-in Real Device (Vendor Y)

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

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

20. Localization • Localization (I18N/L18N) is a major issue in the wireless space, where a single app deployed to a single carrier may need to support many languages and character sets.  • Key requirements: • The Localization architecture should be capable of supporting all languages. • It should remove the need for application developers to decide which encoding the application will support. • The Localization architecture should be aware the UI differences in devices so that the developers 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.

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

22. GUI Editor • The Eclipse Visual Editor provides an extensible GUI framework, that can be used in the mobile IDE UI area. • Why VE: The 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.

23. Backup slides More detail presentation about the top technical items

24. Backup slides – Device Fragmentation

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

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

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

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

29. Backup slides - Wizards Wizards internal architecture

30. Wizards architecture • [template management]…

31. Backup slides - Runtime Launch Runtime Launch internal architecture

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

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

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

35. Device Services Runtime Platform, Device Services getRuntimePlatforms(String devicePlatformName, String deviceName) : RuntimePlatformDefinition[] ... • Device Services make it possible to query Runtime Platforms of a Device.

36. Backup slides - Debugging Debugging internal architecture

37. Debugging architecture • …

38. Backup slides - Device Management Device Management internal architecture

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

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

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

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

43. Device Platform

44. Device

45. Runtime Platform

46. Project

47. Code Editor Code Editor internal architecture

48. Code Editor architecture • tbd

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

50. Backup slides - Deployment Deployment Framework internal architecture