Visual Mobile Designer 2 - Features List



This document discusses user-view problems in current implementation and all possible usability and productivity features for the next implementations of Designer.

This document is not updated for a year and therefore some features, graphics, priorities, target releases could be changed.

Most Signigicant Problems in Designer 1

The first version of Designer should be considered rather as a proof-on-concept than a full-featured tool, because it has many limitations and usability problems described below. Nevertheless this version proved there is a lot of interest in such a tool among the developers and the ideas behind this tool are heading in a correct way. The most significant problems are described below:


Complex MIDlets usually contains tenths of components and twice as much of transitions. In the flow designer this results in:

  • Realign Screen action is realigning independently on types of components. Related screens could be far away from each other and transitions routing algorithm is forced to create complicated paths (path has more than 6 control points).
  • All components are currently put into the same design and class. With the increasing number of components, this causes rather unreadable flow designs.

Even simple MIDlet does not look simple in Flow because:

  • Using Alerts creates go-through transition. A bunch of these transitions using the same Alert results to serious problem for aligning the screen and its ports.
  • Modeling walking through a wizard using screens with Back, Next, Cancel commands results into a mess of transitions (3 for each screen) which are crossing each other and forces an user to layout ports which has to be done manually.
  • There is a single target port for each screen. A target port of a menu screen is used by more than one transition. These transitions usually leads to screens placed to different directions from the screen. This makes transitions to be more complicated.

Dynamic Behavior

In many application UI is not static - many values of the components are set dynamically as the application retrieves data. In current version, there is no way how to "bind" the data with the UI components, user have to do all changes manually by writing custom code.

Note: Sometimes, even the individual components are added based on some input data.

Complex Flow

Currently a line in Flow represents a transition from one screen to another invoked by a command. This is not sufficient for a real application. In real application an user have to handle network events, flow forking, ... Therefore a connection between two objects have to be more than just atransition between two screens.

Screen Designer WYSIWYG and Custom Looks and Feels

The idea when designing on Screen Designer in Designer 1 was to create an environment, which would provide ability to create 100% WYSIWIG with switchable L&F of the LCDUI components. The renderers could be created by 3rd parties, so companies like Nokia or SonyEricsson could create renderers for their devices which would plug into our IDE. As it turned out, when working with Screen Designer, the user does not look for 100% WYSIWYG (which changes from device to device), but rather for design which would express layout directives and status of individual components with hints.

Enterprise Support

There is no support for corporate users at all. An user must write a JavaME to JavaEE connectivity manually and that code is not visualized in Designer. Corporate users are happy if they could use bundled custom components, so they can develop application more quickly. In the current version of Designer, there are some custom components (TableItem, WaitScree, SplashScreen) Even though it is a good start, corporate users expects more components with more functionality, ideally with possibility to bind to data resources over the network, which they could use out of the box.


There is no public API for specifying components. Therefore users could use just the predefined set of components and custom component created from their project by Add Component wizard. There is possibility for 3rd-party vendors to supply their components but it is limited to specifying properties only (similar to Add Component wizard possibilities).

The API should be devided into two parts:

  • components API - this API would allow 3rd party developers to provide additional components to the designer. This API should be tool independent and ideally it should be developed as an extension to Design Time API (JSR-273 <>)
  • designer API - this API would allow 3rd party developers to add more functionality to the designer. For example tools for developing Games (GameCanvas + LayerManager) or tools for utilizing a special behavior of a 3rd party component.

2way editing

Many users are complaining about guarded block the current designer is using - they usually express a wish to be able to edit the generated code (i.e. to have 2-way editing capability like JBuilder or Websphere Device Developer). Originaly, the designer used single large guarded block to contain the whole application - user had to enter a custom code via special property editors, which are not very well usable.

In the Velvet version, the single guarded block was split into several pieces, so now users can enter a custom code in more natural way. Since Velvet hasn't been released yet, it is too early to evaluate whether "multi guarded blocks" feature is enough for most of the users, or they still feel 2-way editing is the only way.

Device Fragmentation

The only way how to do a device fragmentation is to add preprocessor directives directly to the source code on the user-code places. This still does not allow fully modify transitions and Forms components.

Game Support

There is no support helping game developers with resources (layers, sprites, ...) at all. The game developer could use Designer just for creating a menu for the games but even this is not used in real because even the logo and menu screen are special Canvas classes.

Overall Plan

We would like to create a tool which is:

  • Easy readable and usable. We have to simplify the designs as much as possible and to show things that are needed for sufficient descriptions of the application.
  • Targeted for enterprise users. These users want to do an application very quickly with connectivity to enterprise systems.
  • Able to design dynamic changes. Designer should have a solution for visual editing of dynamic changes (data, UI, and flow) in the application.
  • Able to design a complex flow of a application.
  • Extensible by 3rd-party vendors. An API has to be published, so 3rd-party developers would be able to plug-in their own components into the Designer.

Targeting features for particular releases were considered by following rules:

  • Next release: Internally public Designer API, Internally public Component API, internal redesign of the architecture, basic set of enterprise features, user must have additional value (comparing to current release) - mainly in usability.
  • Next+1 release: Public APIs, Full set of enterprise features integrating different technologies and APIs available to mobile devices to connect.
  • Future releases: Features are not essential and/or could depend on features/APIs that are not available currently.

Feature priorities:

  • Must Have: This feature is essential for the release and must not be released without it.
  • Should Have: The release could be released without this feature but it is recommended to have it. This priority is raised to Must Have for the release after the planned one.
  • Nice to Have: The feature is not essential for the release and could be implemented after all Must Have and Should Have features for the release.

General Features

Support for Device Fragmentation

Priority: Component Level is Must Have for the next release, because of UI/implementation complexity Design Level should be aligned with two-way editing.

Device fragmentation support can be divided into two main areas - design level design fragmentation and component level fragmentation.

Design Level Fragmentation

This fragmentation allows users to create/edit fragmented designs. This means user should be able to create components/modify flow/set properties based on the project configuration. There are two possible approaches to implement this feature:

  • Build device fragmentation capability into the designer model, create rich UI allowing the user to create fragmented components/transitions/properties. This approach could be implemented faster (because it does not depend on 2-way editing), but would require much more effort to do so. Also the UI for device configuration might be quite complicated.
  • Implement 2-way editing to the designer, might want to include some UI to support device-fragmentation. This approach comes (except the UI) basically for free with the 2-way editing feature. Each time the project configuration is changed, the designed models are recreated and always correspond to the source code. The designer might then implement just some ui to allow users to somehow specify whether the changes in the designer should go to the default config or a specific config.

Since device fragmentation is a feature for advanced user, the design level configuration is not an important feature for users targtted by the visual designer, therefore the first approach (fragmented model) is not worth implementing. The second approach (2-way editing) is more aligned with the designer type of users - users not requiring this functionality woudn't even notice it, advanced users should be already familiar with the functionality from the editor and are definitely able use editor for fragmented modifications like that.

Component Level Fragmentation

Component level fragmentation considers only fragmentation in the individual components. This means if a user has a fragmented component in the design, the IDE should be able to use the appropriate version of the component in the resulting built distribution. This should currently work in the case the component is avaiable as a source in the project (or any subproject) and the component signature is not changed for each configuration.

For the next release we should definitely support using binary versions of the fragmented components which has the same method signatures. From the designer perspective, there is nothing to be done - this feature must be implemented on the j2me build system level, perhaps by utilizing a predefined database with appropriate names for devices/abilities.

In the case the component is going to have a different method signatures for different configuration, the designer model will need to implement a light-weight support for this (this will require some additions in component API - descriptors and in model persitence). We might skip this support for the first release and decide for it later if there is going to be a need for it.


Priority: Must Have for next release.

The user should be able to use Strings and possibly other resources (Images) from resource bundles. This is going to require a special String property editor, which will be capable of accessing and getting the localization information from the bundles.

The localization support should utilize both, existing Localization Support and Mobile Internationalization API (JSR-238) <>. The JSR-238 support partially depends on a standalone support for this JSR from Mobility Pack (we should create a new module for the next version of Mobility Pack, or somehow extend current internationalization support from NetBeans to support this JSR).

Live Component Palette

Description: Must Have to next release.

Component Palette will not be as static as it is right now. In the palette there will be a set of predefined component supplied by IDE and 3rd-party component vendors. Additionally there will be a category with dynamically detected components from the project where the active document is located.

Note: Palette should also support code snippets - i.e. parts of the design, which are not components, but could be used to plug-in some functionality. Question: Could we somehow user live templates from NetBeans for such a code snippets?

Public APIs

Description: Should Have for the next release.

This feature allow 3rd-party vendors to extend Designer functionality. There will be two basic APIS:

  • Component API: This API should allow to add user components to the designer. This API should be tool independent and ideally should be based on Design-Time API (JSR-273). Ideally it should allow also register screen renderers and flow renders (discuss this capability in JSR-273 EG)
  • Designer API: This API is tool dependent and it should the developer allow to:
    1. . Add views (e.g. GameDesigner) to the tool
    2. . In the case support for custom screen/flow renderes will not make it in some form into JSR-273, provide abilility to specify these renderers for the components.

Wizard on Drop

Priority: Should Have for next release. (Must Have?)

When a component is dragged from the palette and drop on the designer, currently it just adds the component into the design.

This feature allows the component descriptor to show up a wizard or panel where some inital customization for the new component could be make. This feature should be as less as possible. It could be annoying for users to go through the wizard each time their DND a component. So it will be used only for things that are really essential for the component. For example: it is strange to have Image component without Resource Path property specified. Therefore it this case there should a resource path property editor shown immediatelly after the Image component is dropped on the design.

Note: User should be able to turn off the wizard, so the values of the created component would be set to default values.

Note: this should be aligned with Design Time API. (BeanCreateInfo interface?)

Features Panel

Priority: Should Have for next release.

It is not wise to add all the possible action of a component to its popup menu (for example: connecting an item to a datasource). It is better to have an features panel where all actions and property editors will be available. This panel is an replacement for current Properties Window which has static UI. It could placed at the same location as Properties Window or to the bottom or to the right from the multiview.

The actual size of client area for component customizers could differ from each placements. It will be forbidden for client areas to have a horizontal scroll bars (using two scroll bars makes editing complicated for users and vertical bar is more common to use).

The customizer has to propagate all changes directly into the model. If the customizer is complicated and could be in invalid state (from component view) while it is edited by an user, the customizer could contain Apply and Cancel buttons for actual setting new values and reverting values back to the state before editing. There should be Reset to Default button too. Also the Reset to Default action should be in popup menu on each property editor (if applicable - some values might not have default values - is that true?).

This panel could contain a property sheet in corner case. For a single editable property components it should have some nice customizer or at least their current custom property editors should be embedded directly in the features panel.

Note: The feature panel should contain only the most important actions/properties - all other should be available via property sheet/pop-up menu.

Note: The component has to decide how the changes should be propagated to the model.

Note: This should be coordinated with DesignTime API

Note: Feature panel could be invkoed directly by clicking on a special button on a component in the screen editor (see screen editor for details).

Command Action

Command Action editor could be similar to current one but it must asure to still have assigned its Command resource. Also Action custom property editor should embedded directly into the features panel.


Font customizer should be similar to current one but redesigned for vertical layout. There should be:

  • all possible options with checks for invalid combinations,
  • font preview.


Image customizer should be similar to current one but redesigned for vertical layout. There should be:

  • chooser for an image in project,
  • button for adding an image from external sources,
  • selected image preview,
  • checkbox for "Supported Image Types Only".

Note: term "Supported Image Types Only" is perhaps not correct, since each platform has its own set. We could use either J2ME polish for detecting supported image types, or rename this to "Show Only PNG Images"

Cancelable Task

Customizer will contain a JTextArea for editing the code of the task. Below this there will be Apply and Cancel buttons.

Note: Concerning cancellable task, user should be able to select a custom implementation of CancellableTask interface for the WaitScreen component.


  • ability to connect the data source to the remote service, modify connection settings

Data Aware Components

  • ability to bind the components with datasets

Other UI Components

  • needs to be specified individualy for the actual components

Hint Line

Priority: Should Have for next release.

There should be a hint line at the top of each view in Designer (Screen, Flow). This line should show some kind of important information which belongs to current action which an user is performing at the time (tooltip like details while mouse is over the element (components, links, ports, badges), possible action, DND status, and an advice). This hint line will be visualized as a label with fixed width for showing a single line of text (and an 16x16 px image) placed between a view and its toolbar or below the view.

Note: user should be able to enable/disable this hint line. Power users usually don't want to see.

Note: This should be coordinated with DesignTime API

Inline Property Editor

Priority: Should Have for next release.

This component simplified managing of data sources over the project but it could be used in other case all over Netbeans IDE.


Flow Designer Features

Transition is a Code

Priority: Must Have for next release.

There are two kinds of lines in Flow:

  1. Transition - represents a code.
  1. Association - e.g. a component is used by another or they have some relationship between. 

The transition has its Source Point and Target Point. The Source Point is represents exact place/pointer in the source file where the code will be generated. The Target Point affect what code will be generated.

For example: If the Source Point is a command attached to some displayable, it means that the code will be generated into exact place in the =commandAction= method. If the Target Point is a displayable, it means that the generated code will be =getDisplay ().setCurrent ()=.

There are two kinds to association:

  1. Switch Displayable - represents a property defining target displayable for a switch e.g. WaitScreen success and failure properties. This association eventually behaves as transition.
  1. Relationship - represents a relationship between two elements in the Flow e.g. an Alert badge with releated Alert component.

Both kinds of lines have to be graphically distinguishable e.g. an association as a dashed line and a transition as a solid line.

Support for full lifecycle of MIDlet

Priority: Must Have for next release.

Currently flow designer supports only startApp() and destroyApp() methods in MIDlet. We need to support the whole lifecycle of the MIDlet - this means also to include pauseApp(), notifyPaused(), notifyDestoyed(), resumeRequest() methods. Concerning startApp() - we need to differentiate between the state when the application is started and when the application has been resumed from the previous pause state.

Entry/Call Point

Priority: Must Have for next release. Requires Transition is a Code feature.

The Entry Point and Call Point are two new components.

An Entry Point acts like a Source Point for Transitions in Flow. It represents a method in the source file. The code will be generated into the method body.

The Call Point acts like a Target Point for Transitions in Flow. The generated code will contain a call to specified method.

Flow Class

Priority: Must Have for next release. Requires Entry/Call Point feature.

An application could consists of =x * 10= screens/elements. Currently we support to design their flow in a single Flow view. This makes complex applications unreadable.

This feature allow to have an application split across more classes. Usually each class will be public and therefore placed into its own file. Each class will have its own Flow view. A Flow view will visualize all the components defined in the source code of the class.

The connection between Flow views will be done be Entry and Call Points. This forces users to create well-structured applications.

Following image shows the Flow Design of a MIDlet class with a "openSettings" call point:


Following image shows the Flow Design of used Flow class that declares "openSettings" entry point and uses "openMenu" call point:


Note: A class considered for a flow should be either MIDlet or implement CommandListener or ItemCommandListener interfaces. Related Questions: How to deal with a component declared in and used by a CommandListener in How is user going to be able to set the Flow view for a given component (property?)? How are going to be visualized files which define a set of components, but do not define flow? How to deal with ItemStateChangedListener (in screen designer?)?


Priority: Must Have for next release.

The badges are small icons attached to elements (nodes, ports, links) in Flow. These badges improves readability of Flow by notifying an user that there is something unusual and by removing unnecessary elements from Flow. It must support badges ordering.

User Code

There will a User Code Badge for each pre-init, post-init, pre-action, post-action user code.

Pre-init and Post-init badges will be attached to a displayable (placed at bottom-right corner).

Pre-action and Post-action will be attached to the transition (placed near the Source Point). The post-action badge has to be somehow distinguished from the pre-action badge e.g. using different icon or a separator icon placed before the icon.

Following image shows how pre-init, post-init, pre-action, and post-action user codes will be presented in Flow Design:


Go-Through Alert

This will be used for a transition which is going to a displayable through an alert. These transitions will be visualized like a link directly linked from the source to the displayable and they will have an Alert Badge attached (placed near the Source Point).

Current Designer visualize these transitions as two links going from the source to the alert and from the alert to the displayable. This often cause readability problem, especially when the alert is used in more than one go-through-alert transition.

This feature reduces the number of transitions in Flow. The removed transitions are usually not necessary for overall understanding of the application. If an user want to get an information about used alert, it could be shown his/her request e.g. tool tips.

Following images show how an transition which goes through an alert is visualized.



With the feature:


Question: Since MIDP2 Alerts can have assigned additional commands - how such alert is going to be visualized? As a full component? Should user be able to choose which visualization mode he/she wants for a component (badge/full component)?


This badge will primarily used in Inspector. This error badge is targeted for "ghost" components (components without their descriptors). These component will be shown in Inspector only because other views will not known how to work with them.

For example: When an user accidentaly removes some component descriptor from project/palette, all the component that are using this descriptor will immediatelly become "ghosts" (they are still the design but an user could not work with them). Because of these "ghost" the user could add removed component descriptor back to project/palette and the ghost components will immediatelly become normal ones and the user could work with them as before.

Note: User should be able to delete these components from design. Also Undo/Redo should work.

Automatic Ports

Priority: Must Have for next release.

There are two problems with current implementation:

  1. A port is placed somewhere around a node. Port location is not changed automatically. When nodes are moved on Flow, it needs to change the location of its ports too e.g. when there is a link to a target node and the node is moved to another direction from the target node, it would be better to place ports to the opposite node direction.
  1. Often a displayable is used as a target for transitions. Currently there is only one port attach to a node and acts like a target for transitions. This creates bus-like structure of lines. This reduces readability of Flow because an user is forced to track line paths.

This feature makes:

  1. One port is attached to none or exactly one link only. Therefore each transitions will have its own port attached to the target node.
  1. Ports will be automatically placed around the node where are attached. Their locations will be resolved from directions of their opposite nodes. In case there are more ports on a side than available places, ports must be placed to another sides too.
  1. Port icons will be shown only for source ports which are not attached to a link. Target ports and source ports attached to a link will hide their icons. Only a target point of a link will be possible to relink to another target.

Following images show how ports is/will be automatically organized by default without any manual change of ports logical ordering.



With the feature:


Still there could be problems even this feature will be implemented. Mainly for time performance optimalizations the algorithm will not check the order of ports on each side of components with order on other components. It could result into a state that ports will be placed on correct side of components but will have different order comparing to order on opposite component. For example: In example image above there could be the menu component that has exchanged locations of a case port and apropriate target port on a side. For these cases there still has to be a possibility to manually change ports logical ordering.

Note: IMHO user still should be able to change the position of the ports and ideally also change the shape of the line. Also when performin automatic layout, user should be able to specify whether he/she wants to include also the modified lines/ports in it.

Improve Realign Algorithm

Priority: Should Have for next release.

Improve Realign Algorithm. New algorithm could be based on star topology. This could help align related nodes to be more closely. There should be also more available algorithm to be used by user because each algorithm suits for different application.

Optionally the algorithm could count with lines crossings and try to avoid them. In case that 2 lines are crossing each other, one of them should have "jump-over" at the place.

Note: we should implement several algorithms for auto layouting. User should be able to use the one which suits him/her.

Non-visual Components in the Flow

Priority: Nice to Have for next+1 release.

Currently on the Flow there are shown visual components (the components derived from Displayable and Mobile Device) only.

Sometimes it will be useful to see non-visual components too. Non-visual components are usually resources. Not all non-visual components will be shown. Usually only those that represents some highlevel information:

  • Connections
  • Web Services
  • DataSources
  • Alerts

This could be also helpful for users to see relationship between components. For example: When an user has a mouse over some Alert badge, a direct association link from the badge to the related Alert node could be shown.

Note: this should be solved in more generic way - even resources are non-visual components some users might want to see. Perhaps for both, screen and flow, designers there should be a configurable area, which would show all such components as icons. By default all non-visual components should be visible there, but users should be able to disable/enable categories of the non-visual components.


Priority: Should Have for future releases.

Labels are virtual components. They act like symbolic links to original components. Labels will be used as transition targets only (otherwise it could lead into lost-expliciteness problem that cause hard maintainance). The reason to use Labels is to make the design more clear.

For example: You have two components in Flow and they are far away from each other. You want to create a transition from one to another. This transition very often reduces readability of Flow. Therefore you could create a label for the target displayable. Place this label near to the source displayable. Because the label acts like a symbolic link to the target displayable, you are able to create a transition from the source displayable to the label. This will have the same functionality as a transition which leads directly to the target displayable.

SVG in Flow Designer

Priority: Nice to Have for next release.

The feature allows to render displayables/items in the Flow using SVG. This improves usability of public API because SVG currently a standard for a graphics rendering and allows to describe a component using XML file only.

Screen Designer Features

Non-WYSIWYG Screen Designer

Priority: Must Have for the next release.

In current implementation of Screen Designer there is often problem that it tries to be WYSIWYG. It could result into a usability problem, when some element on the screen is not visible. For example: If you have a StringItem with text and label st to null values, the StringItem is not visible very well(actually it is still there but rendered as a small 1x2 pixels size place).

Another problem is layout in Form - in MIDP2 Form's layout uses several hints, which migh or might not be used by the actual implementation. To see what is being set, the user should be informed by hints on the indiviudal items what are the layout settings.

A solution to current imperfections is a non-WYSIWYG Screen Designer. This allows for previous example to have the StringItem still rendered as a StringItem with "<No Label>" label and "<No String>" string.

Note: This feature must not affect supplying custom screen renderers by 3rd-party vendors.

Idea: Investigate possible usage of SynthLookAndFeel in JDK 1.5 for delivering L&F for components by 3rd party vendors

Embedded Feature Panel

Priority: Must Have for the next release.

When an user wants to change properties of a component in the screen designer, he/she has to select the component and then go to property sheet and set the value. Because property sheets are becoming complicated and from usability point of view, going to property sheet is slightly interrupting user's work, it is much better to allow to change the property value directly on the component. Currently the screen designer allows in-place editing for the most important properties, but this is not enough.

A good solution this is to use approach currently implemented in Microsoft Visual Studio 2005 - add a small customize button to component, which, when being clicked on, is going to show some sort of pop-up menu, which embedds already discussed feature panel. This feature panel contains the most often used properties and actions (e.g. for StringItem "Assign ItemStateListener" or "Assign Command").


Visualization of Commands and Resources

Priority: Must Have for the next release.

In the current designer, the assigned commands are showing description of ations what is going to happen when the command event is being processed. With introduction of multiple guarded blocks, this information is becoming not so important, because it now shows only the screen to which the application is going to switch. Because this information is perfectly shown in flow designer, it is better to drop it from the screen designer and use the saved screen space for visualizing application resources (fonts, images, ...)

The commands and resources are going to be organized in several groups:

  • screen commands - commands assigned to the edited screen are going to be visualized in this section
  • item commands - for each item with assigned command, the screen editor is going to show its own category named "${item_component_name} commands" with commands assigned to this item
  • resources - resources is going to be just one category, but it will be formatted (see example), so each resource type is going to appear in its own paragraph

Nice to have feature would be a 'resource usage' - when user selects a resource, screen designer is going to highlight all components using this resource. For example if an StringItem is using a font resource, when an user select the font resource, the StringItem is highilghted. This could work both ways (when an user selects the StringItem, the font resource is highlighted).


SVG Renderers in Screen Designer

Priority: Nice to Have for the next release.

The feature allows to render displayables/items in the Screen using SVG. This improves usability of public API because SVG currently a standard for a graphics rendering and allows to describe a component using XML file only.

Binding data to UI components

Priority: Should Have for the next release.

This feature allows the user to bind some data object to an UI component. This means a value of the specified object should be automatically set to the component and in the r/w mode, the value from the ui component should be set to the binded object.

The screen designer should visualize the binding in the UI components - instead of static text, it should show something like '<:=instanceName.propertyName>'. It should also let user edit the binding.

Note: how to keep track on changes of the binded object (we don't have any JavaBeans mechanism) Note: should we support something like validation? I.e. the binded data object could refuse the entered value?


Java Code Generation/Synchronization

Generated Code

There are 3 ways how to generate code.

Single Guarded Block

Priority: Must Have for next release.

This code generation is the simplest one. All the code generated by Designer is placed into a single guarded block which could not be modified by an user. This is easy to implement but it requires to have text editor for user-codes. Also an user is loosing the connection between the user code and the rest of the source code.

Multi Guarded Blocks

Priority: Should Have for next release.

This code generation is compromise between Single Guarded Block and 2-way Editing types. The code is generated by Designer is placed into many guarded block. By an user it could looks like a single guarded block which has a gas inside. An user could enter his/her user code directly into the source code. For users this is more natural way of editing. This requires some kind of "2-way editing" support for synchronizing user codes written into the gaps by the user.

Note: Currently multi-guarded blocks cannot be controlled from components - e.g. SimpleCancellableTask. The next version should allow the components to define where the guarded blocks start and end.

2-way Editing

Priority: Nice to Have for future releases.

For users this is the most natural way of editing the source file. The source code with will be fully editable by user without any guarded block. The source code will be automatically synchronized with the Designer views. A change made in the source code will be propagate into the views and a change made in a view will be propagated into the source code.

The synchronization from the source code to Designer will be based on searching for patterns. For example: A class component is recognized following pattern:

ClassType fieldName;
get_fieldName () {
    if (fieldName == null) {
    return fieldName;

There will be a set of pattern that will search in the source file. There is a resctriction for searching: every single part of the code must be found by one pattern at maximum.

Also there is a problem that there are not existing well-known standard rules and design patterns for JavaME. Therefore it could happen that users will use patterns that we will not recognize.

Short Class Names

Priority: Must Have for next release. This feature is valid for Single Guarded Block and Multi Guarded Blocks features only.

Code generation will update import sections of a source file and it will use short class names for the generated code in the guarded blocks. This feature will be enabled by default but there must be an option to disable it (means: force to use fully qualified class names).

In-line Components

Priority: Nice to Have for future releases.

The feature allows to design a "in-lined" command or an entry/call point. It means using a command resp. entry point without its field declaration resp. method declaration in the source code. The component will be used in the source code just on the places where it is needed.

There are following constraints for components:

  • A component that represents an exception (e.g. class component such Command) could be created by contructors and cannot use setters for setting additional properties. Therefore a component representing a class must use properties that could be set by constructors or factory methods only.
  • A component that represents a set of commands (e.g. transitions) could be fully used. If their are declaring a local variable they have to be enclosed in brackets.
  • A component that represents an in-lined entry point could has on Switch Displayable association only.

This feature will be essential when 2-way editing feature will be implemented. Until that time it is not. Therefore this feature is has Nice to Have priority.

Custom Components

If, Switch Component

Priority: Must Have for the next release. Requires Transition is a Code feature.

These components allow to fork a code into more branches. A component will act like a target point for transitions. It will have source points for other transactions. The "if" and "switch" conditions and cases will be fully editable. The "if" component will support if-else-if pattern. These components could be connected together into a chain.

Following image shows how these components could be connected in Flow Design:


Note: These components perhaps should be visualized somehow differently (i.e. not as a full component, but with a different icon? different style?), because from user's point of view they are not components, but rather a block of code.

Back Command

Priority: Must Have for the next release. Requires Badges feature.

Usually applications contain a chain of screens. On each screen there is a Back and some kind of Next command. These commands allow an user to walk through screens back and forward.

In current Designer it could be visualized as screens - each with two 2 commands - each command is attach to a transition. Usually an user has to manually change locations of commands in Flow otherwise transitions have many corners. Therefore this design pattern made a Flow hardly readable.

This feature allows to add a Back Badge to a displayable. The badge means:

  • A Back command is added to the displayable permanently but the command is visualized as a badge only.
  • When code generator for a transition requests for a code to generate on the displayable: It must add following code before a code for display switching. The code:
backCommandHashtable.put (assignedDisplayable, getDisplay ().getCurrent ());
  • commandAction method will contain following code for handling the back command:
// pre-action code
if (command == backCommand)
  getDisplay ().setCurrent (backCommandHashtable.get (getCurrent ()));
// post-action code
  • The pre-action and post-action codes and the backCommandHashtable field will be store/handled in back-command-handler component.

This feature reduces the number of commands and transitions in Flow. There will not be back transitions anymore. This helps transitions in Flow to keep their planar graph structure which is easy readable.

Following images show how the back command pattern is visualized:



With the feature:


Note: Back Command ability should be exposed also as an API from nbmidp components, so users can use this facility programatically. To verify we need to create a sample MIDP implementation to see how it works and how it is usable. We should also discuss the actual MIDP implementation.

Note: How and when the back transition should be visualized?

Cancel Command

Priority: Must Have for next+1 release. Requires Badges feature.

This feature is similar to Back Command feature. It is also designed for applications that contain a chain of screens. On each screen there could be a Cancel command. This command allows an user to jump to some specific displayable (usually a menu) from any steps independently on where the user currently is.

In current Designer each "cancelable" displayable have to have a Cancel command attached and there has to be a transition from the command to a target displayable.

This feature allows to add a Cancel Badge to a displayable. The badge means:

  • A Cancel command is added to the displayable permanently but the command is visualized as a badge only.
  • There will be a non-visual component representing this badge where a target displayable could be set.
  • commandAction method will contain following code for handling the cancel command:
// pre-action code
if (command == cancelCommand)
  getDisplay ().setCurrent (cancelCommandTargetDisplayable);

This feature also reduces the number of commands and transitions in Flow. There will not be cancel transitions anymore. This is really helpful because usually they are cross whole visible area of Flow and often breaking planar graph structure.

Following images show how the cancel command pattern is visualized.



With the feature:


Note: Cancel Command ability should be exposed also as an API from nbmidp components, so users can use this facility programatically. To verify we need to create a sample MIDP implementation to see how it works and how it is usable.

Note: How and when the cancel transition should be visualized?

API support - Push Registry, WMA (SMS, MMS), MMA (Media Players), IR, Bluetooth communication component, ...

Priority: Should Have for next+1 release. Requires Entry/Call Poin and Connection Component feature.

This feature allows integration of different APIs available in MIDP. APIs will be intergrated using specific communication components. There will be two usecases:

  1. Each part which is able to call/perform an user code will be presented as an Entry Point in the Flow.
  1. Each part which could be called will be presented as a Call Point in the Flow.

It should be possible to specify a connection manually or by selecting connection component.

Note: all components cannot be presented as connections - each case should be described in more details with impact on flow/screen designer.

SVG Canvas Component

Priority: Should Have for next+1 release.

This component is a Canvas component. Its visual appearance is defined be SVG file. The SVG file could be used for rendering in the Screen too.

Note: delete this item, it should be included in SVG components feature

High-Level components

Priority: Should Have for the next+1 release

Currently the designer works with low level MIDP UI components. Since our target users might not be familiar with these components, we should create a set of high-level components which would help them to design the application faster and more effectively. These components could be based either on existing LCDUI framework or could utilize a different one to provide better user experience. One of the candidates for graphic presentation might be SVG - this would give us an unique oportunity to share renderers in both runtime and design time.

Note: High-Level components framework based on Canvas will need to deal with keyboard input. Better support for this is expected in MIDP3.

SetCurrent Method

Priority: Nice to Have for future releases.

This feature creates setCurrent method in the the source code and use this method for each change of displayable on the mobile device screen. This allows handling dynamic changes that should happen when a displayable is going to be hidden and shown. For example: loading/refreshing values of elements in displayables or implementing stacked version of back command feature.

This feature is workaround/replacement for events that are missing in MIDP API. Therefore it could be obsolete in the future. Therefore this feature is has Nice to Have priority.

Note: would this cause problems for 2way editing?


End2End Support

Description: Should Have for the next Must Have to next+1 release. Requires Entry/Call Point and Connection Component feature.

This feature allow integration of End2End into Designer. End2End support creates client classes with methods. The client class will be presented in the Designer. An user will be able to select which method should be accessible in Designer. For each selected method there should a Call Point in the Flow.

There will be also possible to define callback methods. This means when End2End support allows receiving "signals" from ouside of the device, for each signal there will be a Entry Point in the Flow.

It should be possible to specify a connection manually or by selecting connection component.

Note: this needs coordination of work of Designer team with E2E team.

Remote Services (JSR-172 WebServices + SOA (JSR 279: Service Connection API for JavaME) + Javon)

Description Should Have for the next release, Must Have to next+1 release.

This feature allow integration of remote services like WebServices into Designer. Currently in the Velvet release, in the Wireless Connection Wizard, the user is able to generate sample MIDLet, which contains a basic UI for setting parameters, calling the service and showing the output. This can be considered as a good start for some application, but the level of integration is quite low - all the code handling binding the data structures with UI is generated as a user custom code.

For the future release, the integration of remote services must be more tight. Ideally the tool would offer the following functionality:

  • Registry of remote services
  • Bind the remote services with UI
  • Wizards

Registry of web services

Currently user is able to use web services in mobility projects by using wizards that generate either JSR-172 stubs or Javon classes. Even though this attitude is ok for developers using the generated code manually, it is not enough for use in Designer - here users expect interactivity, so they can easily customize the application to their needs.

To achive the interactivity, the designer needs to have a registry of remote services, where the user would see all services available for use in the designer. To make a remote service to be available in the registry, the user would need to either generate JSR-172 stubs or to generate Javon middleware for it.

During the design, the user should be able just to drag the registered remote service and drop it on design. This should automaticaly register the service within the application and allow user to use it. On the source code level, this basically means instantiation of the remote service stub class.

Binding the remote services with UI

When the remote service is ready for use (registerd within the designed application), the user would like to bind it with the UI components. This can be divided into two parts:

  • Binding data structures - in this part the user binds the generated data structures with the individual UI components. The binding can work in two modes - r/o and r/w.

  • Bindind method calls - when binding method call, the user is actually creating an action, where the remote service is being called. This should use


Note: how to bind arrays?


The tool might provide some wizards which would be able to connect either the existing UI to a remote service or to create some UI based on the remote service.


Connection Component (HTTPS, HTTP)

Priority: Should Have for the next, Must Have for the next+1 release.

This feature is allows to use connection components that are an abstraction of connections. (

Note: Do we actually need this? This should be rather embedded within solution for e2e support.


Description: Must Have to next+1 release.

This feature adds a data model abstraction. Data source is anything what holds data in a table like structure. Each column of the table represents property e.g. name, attribute. Each row of the table represents an instance of data. The table will be implemented using cursor pattern. This means there will be cursor which will point to some row in the table and only data from this row will be possible to read/write.

DataSource is defined in MIDP as following interface:

public interface DataSource {

    public void update (); // load data and set cursor before the first row

    public boolean hasPrevious (); // is there any row before the cursor?
    public boolean hasNext (); // is there any row after the cursor?

    public void previous (); // move the cursor to previous row
    public void next (); // move the cursor to next row

    public String[] columns (); // get the names of the columns

    public Object getValue (int column); // get value of a column in the current row
    public Object getValue (String column); // get value of a column in the current row

    public void setValue (int column, Object value); // set value of a column in the current row
    public void setValue (String column, Object value); // set value of a column in the current row

    public void prepareNew (); // set the cursor to a new row
    public void commit (); // commit values
    // added 
    public long getCount(); // get number of available records;   // delete this?
    public long getRowIndex(); // returns index of the current row
    public void update(long index); // loads data for the supplied row index


Note: it might be good idea to split the above interface into two pieces DataSource and DataRow. DataRow is a single row of the database source.

public interface DataRow {
    public DataSource getDataSource(); // gets data source which produced this data row
    public String[] columns (); // get the names of the columns

    public Object getValue (int column); // get value of a column in the current row
    public Object getValue (String column); // get value of a column in the current row

    public void setValue (int column, Object value); // set value of a column in the current row
    public void setValue (String column, Object value); // set value of a column in the current row

Note: Should we automatically include support for writing? IMHO DataSource is going to be used for r/o access by most of the users. R/W support should be available, though.

Note: cursor pattern might not be enough - because of low latency of mobile devices communication, the user might want to specify pages of data to be downloaded and available. Thus the interface needs to be extended with methods handling page caching. It might look rather in the following way:

public interface PagedDataSource {
    public void update(int pageSize); // loads data for the first page
    public void update(long page, int pageSize); // loads data for the supplied page

    public int getPageCount(); // gets number of available pages
    public int getCurrentPageIndex(); // gets current page index

    public boolean hasPreviousPage (); // is there any page before the cursor?
    public boolean hasNextPage (); // is there any page after the cursor?

    public void previousPage (); // move the cursor to previous page
    public void nextPage (); // move the cursor to next page


In Designer there will be various components which represent particular data sources. Particular data sources could differ in a set of implemented methods:

  • Full implementation
  • Combination of these restrictions:
  • Read only access - setValue, prepareNew, and commit methods are not implemented
  • Update once - update method is not implemented
  • Forward only access - hasPrevious and previous methods are not implemented

Note: What does it mean "update once"? Also "Forward only access" - do we need really need this?

In Designer almost all components will have a possibility to be attached to some datasource component. From that on their content will be driven by data in datasource. An appropriate behavior will be described below. All the updating will be handled by specified component implemented by DataSourceConnector class in MIDP.

Listing of signature of DataSourceConnector class and its methods:

public class DataSourceBinder {

    public void update ();
    public void update (DataSource dataSource);

    public void bindTextBox (DataSource dataSource, String column, TextBox textBox);
    public void bindList (DataSource dataSource, String column, List list);
    public void bindStringItem (DataSource dataSource, String column, StringItem stringItem);
    public void bindTextField (DataSource dataSource, String column, TextField textField);
    public void bindDateField (DataSource dataSource, String column, DateField dateField);
    public void bindChoiceGroup (DataSource dataSource, String column, ChoiceGroup choiceGroup);


Note: In the case we decide to use DataRow - this interface should use this one

Note: Binder needs to support and differentiate between read/write access ...

Note: We might need to support binding not only of "values" of the components, but also titles (either displayables or items)

Note: We should support also images (ImageItem, ChoiceGroup) - how?

All components (for Items their Forms too) must have a badge shown in Screen and Flow.

Note: ??? I'm not sure about flow - is this really needed? Also in screen designer, instead of badges, the actual component needs to somehow visualize it is binded with some data - for example using the same style as RIM BlackBerrt MDS - they use "@columnName" notation. We might use something like "@dataSource.columnName".


This component will be updated with String value from specified column of an active row of specified datasource. It also needs to be able to write the specified value back to the datasource? Using command?


This component will be updated with String values from specified column of all rows of specified datasource. Requires a datasource without update-once restriction. ???


This component will be updated with String value from specified column of an active row of specified datasource.


This component will be updated with String value from specified column of an active row of specified datasource. It also needs to be able to write the specified value back to the datasource? Using command?


This component will be updated with Date value from specified column of an active row of specified datasource. It also needs to be able to write the specified value back to the datasource? Using command?


This component will be updated with String values from specified column of all rows of specified datasource. Requires a datasource without update-once restriction.

It also needs to be able to write the specified value (for checkboxes) back to the datasource? Using command?

Also ChoiceGroup can have an image assigned to the element. We should support this as well.


This component will be updated with whole rows of specified datasource. Optionally it will be possible to filter rows, filter columns, change order of columns.

Note: depends on correct implementation of Table component (ideally with R/W support)

Database DataSource

Database datasource allows to query a database. The result is a 2-dimensional table. This source should be supplied by Javon database support (need to discuss with Javon owners).

RMS DataSource

RMS datasource allows to work with RMS (Record Management System). The result is a 2-dimensional table. Each item will be stored as a record in RMS. The structure of a record will be defined by user. He/she specifies columns (names and types). From this order and types the record structure could be exactly defined.

Optionally the feature could support versioning of RMS records. So each record will hold the version number. This number will be used for recognizing which structure should be used to deserialization. This requires to have possibility to defined convertors from previous/old to current/newest version. DataSource will still present the current version.

Note: ?? Is this really necessary? RMS stores can use names ....

Transparent Persistent Cache DataSource

This feature will be specially used for off-line applications. For example: Let us have an application for querying time table of trains. Now user is connected to the internet (and therefore to the server). He/she makes a query on server and gets an aswner. The answer is shown to the user and everything is ok. Next time the user will not be connected but he/she would like to make the same query query. Now he/she will not get answer because of connection error.

Therefore it will be good to have a cache that is persistent and allows an user to get his/her answer even without original data.

It should be based on RMS datasource. This datasource will be have pointer to original datasource. Datasource will represent the data stored RMS. The Transparent Cache datasource will have an additional method =forceUpdate= that will call update on original datasource and all of the original data will be stored into the RMS.

This datasource will be read-only. In the future it could be extended to read-write, so it will resolve changes in the cache and commit it into the original datasource.

Optionally it will possible to specify filters: what columns and rows should be persisted.

Note: RMS stores usually have a limited size - the implementation should limit the cache size to a specified value. Also note some RMS might have as low as 8k for all applications.

End2End DataSource

This datasource will use End2End module for viewing results from End2End client methods.

For example there could be a method call which returns an array of String values. Each update request on datasource will call the peer to get fresh values. Then the result will be propagated to appropriate components.

Note: Fo we need this? This should be supplied by Database DataSource.



Priority: Should Have for the next release. (Nice to Have?)

Currently an user is able to easily get "top-bottom" information e.g. what commands are assigned to particular displayable. But he/she is able to get "bottom-top" information e.g. where is particual command used/assigned.

The feature adds a new view named "Analyzer" in the Designer. This view will show hard-to-observe (usually bottom-top like) information. Also there could action buttons that performs some optimalizations. Here is the list of possible information:

  1. . Resources (Images, Fonts, Tickers, Tasks, Table Models, Network Connections, Entry Points, ...) and Commands should be listed with a number of their usages. Also there should be action button for searching for duplicities, optimalizations like remove unused resources, ...
  2. . All external connections/communications should be listed with their usages. This allows to gather all information for used connections like network communications, IR, Bluetooth, used webservices, jdbc connections and queries on one place.
  3. . List of all ghost (not used) components in the design and an action button for removing these ghosts.
  4. . All items in the listings should use the same color scheme:
  • Black color means the item is used.
  • Gray means the item is not used.
  • Uellow means there are some warning like this item has its duplicate.
  • Red means the item has serious error.

Online UI Preview on Target Platform

Priority: Should Have for rthe next release.

This feature allows users to see the UI of designed application on a target platform. This preview should be online. Technically it means that all changes done in the views should automatically appear in the target platform too.

This feature works as following: The device/emulator is going to use a special MIDlet, which would listen on changes of the designer UI on server (IDE). The description of the UI will be sent via a special procol (Javon based?), and the MIDlet is going to create the UI elements and preview it to the user.

The feature is essential but currently it is technically not possible to implement it fully in the way that users would like to have. The problem is that users would like to have their custom components visible in this UI preview too. It is not easy due to possible compilation errors, class dependencies, network communication approval, ... Therefore this feature could be reduced by support for non-default MIDP components.

Note: MIDP1 devices/emus support only HTTP protocol, thus the preview is not easy to implement (the device have to poll server for changes in the desgin). MIDP2 supports additional procols (sockets? - are they in standard), so the server can push new desing to the client.

Note: Network communication is ok for emulators, users might want to preview the UI on real devices - in this case we should consider additional media to communicate - e.g. com ports, bluetooth, infrared (see also"ir://...")...)

Game Support

Priority: Nice to Have for next release.

This feature add support for game developers. The basic task to support working with Sprites and TiledLayers. There should be addition view for designing frame sequences and tiles layouts. These sequences and layouts will be integrated into Designer and will be presented/generated in/into the source code. There will be following components:

  • Sprite - a class component for Sprite class
  • Sprite Frame Sequence - an array of primitive int
  • TileLayer - a class component for TileLayer class
  • Tiles Layouts - a two-dimensional array of primitive int

J2ME Polish

Priority: Nice to Have for future releases.

J2ME Polish framework could be integrated into the Designer. It will contain:

  • J2ME Polish project type based on J2ME project type except its build-system,
  • CSS editor for editing UI,
  • optionally renderers for Screen that will understand CSS file.

Device Fragmentation

Priority: Nice to Have for future releases.

There are following types of device fragmentation:

  • components: There could be different components for each configuration.
  • properties: There could be different property values for each configuration.
  • user-code: There could be different user-code for each configuration.

Currently it is supported to have an user-code with preprocessor directives. Other fragmentation types are not supported.

This cannot not be solved in general. There is a problem with handling code generation and visualizing/editing differences between configurations. Therefore this feature is has Nice to Have priority.

Other GUI APIs

Priority: Nice to Have for future releases.

There are other GUI APIs e.g. AWT, AGUI, DoJa. Currently there are not support and probably will not be supported for a long time. This feature is listed here as a feature that asures that the Core API of model and other views will be fully independent on MIDP and allows describing other APIs and design patterns.


  • Designer - Visual Mobile Designer
  • Screen - Screen Designer
  • Flow - Flow Designer
  • screen - a displayable component
  • node an icon with text in Flow
  • port an point attached to a node in Flow
  • link an orthogonal line from a source to a target in Flow
  • menu screen - an archetype of a displayable component which is connected to other (usually more than 3) screens

Back to MobilityDesignerHome

contact: Karol Harazlak

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo