Fork us on GitHub

New GUI Builder

We are rewriting our GUI builder from the ground up and will be previewing it soon
Post Image

New GUI Builder

Our GUI builder is the result of many twists and turns in our product line mostly due to corporate bureaucracy hacks and last minute deadlines from our days at Sun. Its also written using Swing which is pretty much a dead end API that isn't seeing any maintenence and since FX is even worse off there isn't much hope for the tools future.
The GUI builder is also one of the most controversial parts of our UI. While it has its strengths and simplicities its UI could do with a facelift and its architecture was designed before tablets existed. It was designed when Apple just barely surpassed Blackberry sales and had just announced the iPhone 4 (first with Retina display).

With that in mind we decided to rethink the GUI builder from the ground up with a complete from scratch rewrite. This allows us to keep the existing GUI builder for 100% compatibility for the forseeable future and add a decent migration path to developers who want to move to the new approach.
We did learn from the bad experience with FX where there is still no decent migration path for Swing apps to this day so we intend to make the long term migration as easy as possible and intend to support the existing tool for a very long time!
The obvious question is how will the new GUI builder differ from our current GUI builder?

Built Using Codename One

With the new certificate wizard you saw the beginning of a trend that we hope to accelerate. Writing our tool using Codename One itself. This has numerous advantages to us but is also probably the best tool out there with Swing/FX being effectively dead, SWT somewhat stagnated there is really no decent Java UI library for us to use other than Codename One.
When you add the JavaScript port of Codename One into the mix (not to mention the ability to run on devices) the value proposition is even bigger!

The Resource File Format

The resource file format is a binary format we originally invented for themes, images etc. This made features like the GUI builder powerful yet somewhat awkward.
As we moved forward we added an auxiliary XML format that supports themes and allows teams to work more effectively on the resource file. As part of that we added GUI builder XML file format support, this is the format that we will use for the GUI builder which will make the migration process very easy.

The Statemachine

The original GUI builder was designed for simpler mobile apps that had far simpler UI. Most of the UI builders work was navigating between forms and adding commands. The state machine was a common practice that made a lot of sense for that point in time.
Today we support, tablets, desktops and even web. With that in mind we decided to switch to a more traditional approach similar to standard desktop GUI builders where every Form/Container or Dialog in the GUI builder is represented by a single class and an XML file used to maintain the GUI builder state (see above).
However, we intend to add a statemachine compatibility layer in the future to allow easier migration from the existing GUI builder to the new GUI builder with as little work as possible (although we can't promise 100% seamlessness).

Code Generation

The new GUI builder will generate code directly into a class representing the UI. So if you have a form called "MyForm" then you will have a Java source file named "MyForm.java" under the "src" hierarchy and an XML file called "res/guibuilder/mypackage/MyForm.gui" under the "res" hierarchy. This ".gui" file will be used to store/load the actual state from the GUI builder. The GUI builder ignores the source file almost completely except for the special case of event handling.
The code generation will happen thru a new ant task that we already introduced in the build XML. It runs during build and scans the res directory for ".gui" files which it then converts to Java source blocks. The "MyForm.java" will have a special commented section that you aren't allowed to touch, this is very similar to the NetBeans GUI builder architecture but we probably won't physically lock these code blocks like NetBeans does.

Releases & Limitations

We'd like to have a technology preview out for 3.2 but will probably release something sooner than that maybe within the next month (which marks the 5 year anniversary of the launch of the previous GUI builder). We don't recommend the technology preview for production apps since the new tool might generate invalid code and require that you manually edit the XML files to workaround issues. With the 3.3 release we hope to graduate into beta level where we will start emphasizing this tool as "the gui builder" for new projects.
The initial release won't include standardized migration tools although we'll try to add them as soon as possible as this is the best possible way for us to test the tool (by converting existing apps).
The following big ticket features from the designer won't be available with the initial release:

  • List renderers - currently the designer uses a separate container as a renderer. Since the new GUI builder works in isolation this would be more tricky for us to expose.
  • Commands & Navigation - similarly to renderers this requires something more than a simplistic view of a single form.
  • Back Navigation, Embedded Container - These features won't be available in the standard GUI builder since they rely on the statemachine architecture. We will add back navigation to the compatibility layer we plan to add and will try to include embedded container there too
  • Toolbar - the old GUI builder was very flexible in terms of command behavior which effectively made it very limited since it assumed nothing about command behavior. This turned out to be very in-flexible and prevented basic usability features such as "placing a button on the title". The new designer assumes that the Toolbar class is used and will allow greater control over command placement to facilitate that.
  • Style manipulation/Localization - the existing GUI builder allowed customizing styles directly from the GUI builder UI. Since we are now separating the tools styles & localization won't be available. You'd still be able to make use of both but not directly from the GUI builder UI.

Feedback

We are looking for feedback on the tooling and direction, we want to make the transition as seamless and painless as possible as we move forward. With that in mind I hope that once we launch this tool you'd give it a try and let us know what you think.

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.