SynapseIndia Mobile Build Apps management
Automated & manual testing ď Ž
Tdb.
2
17.02.2006
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.
3
17.02.2006
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.
4
17.02.2006
Runtime Launch
5
17.02.2006
Debugging
6
17.02.2006
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
Debug
UI
7
17.02.2006
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 Vendor X X
Eclipse
SDK SDK Emulator Emulator
SDK SDK // Emulator Emulator (Vendor (Vendor X) X)
Plug-in Plug-in Vendor Vendor Y Y Device Device
Platform Platform
MTJ MTJ
SDK SDK Emulator Emulator
SDK SDK // Emulator Emulator (Vendor (Vendor Y) Y)
Plug-in Plug-in Vendor Vendor Z Z SDK SDK Emulator Emulator
Plug-in Plug-in Extensio n point
SDK SDK // Emulator Emulator (Vendor (Vendor Z) Z)
Plug-in Plug-in Vendor Vendor X X Real Real Device Device
Real Real Device Device (Vendor (Vendor X) X)
Plug-in Plug-in Vendor Vendor Y Y Real Real Device Device
Real Real Device Device (Vendor (Vendor Y) Y)
Plug-in Plug-in
8
17.02.2006
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 Emulato r Device
1
Real Device 9
1
Runtime Platform Definition Fragmentation Definition
17.02.2006
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.
10
17.02.2006
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.
11
17.02.2006