SynapseIndia Mobile Build Apps

management

Automated & manual testing

Tdb.

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.

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.

17.02.2006

Runtime Launch

17.02.2006

Debugging

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

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

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

Real
Device
9

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