Fork us on GitHub

Terse Syntax, Migration Wizard & more

A few additional features and updates before 3.2 finally lands
Post Image

Terse Syntax, Migration Wizard & more

In this last minute before 3.2 finally comes out we have a batch of new features & updates. Some of the last minute features that went into Codename One include: shorter more terse syntax for creating forms, migration wizard for the new GUI builder & dialog adaptive sizing.

Better Syntax For Populating Containers and Toogle Buttons

Codename One is slightly verbose. In part its due to Java's tradition of verbosity but some of that comes from the fact that we never considered terse to be a virtue. Obviously a lot of developers disagree with that notion and would like shorter syntax, which does have a point...
One such small modification of the "why didn't we do this sooner" variety is new methods we added to container that are shorter (add instead of addComponent) but also return the Container instance thus allowing chaining. E.g. this is taken directly from the KitchenSink's input demo:

Container input = new Container(new BoxLayout(BoxLayout.Y_AXIS));
input.addComponent(new Label("Text Field"));
input.addComponent(new TextField("Hi World"));
input.addComponent(new Label("Text Field With Hint"));
TextField hint = new TextField();

With the newer syntax we can cut down the verbosity significantly. Notice we can just add("String") which is equivalent to addComponent(new Label("String")):

TextField hint = new TextField();
Container input = new Container(new BoxLayout(BoxLayout.Y_AXIS)).
    add("Text Field").add(new TextField("Hi World")).
    add("Text Field With Hint").add(hint);

The thing I really like about the code above is that its short enough to place the label and component side by side to each other without side scrolling in the IDE window.
Another feature we added in the same vain is a simple factory method for RadioButton/ ToggleButton creation. Up until now if we wanted to create a toggle button we would do something like:

Container toggles = new Container(new BoxLayout(BoxLayout.Y_AXIS));
ButtonGroup bg = new ButtonGroup();
RadioButton a = new RadioButton("a");
RadioButton b = new RadioButton("b");

That's pretty verbose and ridden with boilerplate code. So we shortened this slightly using the createToggle factory method that combines 3 lines above into one e.g:

Container toggles = new Container(new BoxLayout(BoxLayout.Y_AXIS));
ButtonGroup bg = new ButtonGroup();
RadioButton a = RadioButton.createToggle("a", null, bg);
RadioButton b = RadioButton.createToggle("b", null, bg);;

Dialog Adaptive Sizing

Dialogs in Codename One are forms that show the previous form as a background. This causes some confusion since developers often think of them as standard OS "windows" which isn't the case at all...
We position the dialog by padding the dialog body from the sides to move it into the right place and for most standard dialogs we "auto calculate" this margin based on the preferred size of the dialogs content. This is all great until we want to change something with the content of the dialog....

We normally try to discourage people from building complex UI's into a dialogs body but sometimes this is necessitated by the UI/UX and can't be avoided. Up until now our workaround to grow the dialog was to dispose the current dialog and show a new dialog (without the transitions). However, with the new update we now have a new method: growOrShrink() which will implicitly resize a dialog to its new preferred size.

GUI Builder Updates

The new GUI builder and its integration with Codename One has been going on very well, we were even able to add a preliminary migration wizard for existing resource files just before the 3.2 release. This wizard and the rest of the GUI builder are HIGHLY experimental so caution is advised, copy your project to the side and experiment on that!

The migration wizard will appear for GUI builder projects and effectively should convert them to manual projects with the new GUI builder in place. It will replace the StateMachineBase class with a hardcoded class that does a lot of the work for partial compatibility. Its quite possible your code will work after the migration as is (although we would assume some work would be required).

The following things might have an issue with the new GUI builder and the migration wizard, please use the comments section below with other things you notice and file issues in the github issue tracker:

  • Renderers - at this time renderers aren't supported in the new GUI builder.
  • State machine navigation is MUCH simpler and keeps an instance of the previous form so before/exit behaviors might vary a lot.
  • The new GUI builder always uses the Toolbar class, code that relies on different command semantics might not work properly
Share this Post:

Posted by Shai Almog

Shai is the co-founder of Codename One. He's been a professional programmer for over 25 years. During that time he has worked with dozens of companies including Sun Microsystems.
For more follow Shai on Twitter & github.