Fork us on GitHub

Request Body, Dialog & Border Layout

Minor usability improvements to the API for everyday calls
Post Image

Request Body, Dialog & Border Layout

Subclassing isn’t bad but it becomes tedious especially if it’s just there to implement something trivial. One of the pain points we had with the ConnectionRequest API’s is the submission body wasn’t as convenient as it should be.

E.g. if my web service accepts JSON in the post argument I have to write something like this:

ConnectionRequest r = new ConnectionRequest(myURL, true) {
    protected void buildRequestBody(OutputStream os) throws IOException {

This works great but does it really require subclassing?

So we added this:

ConnectionRequest r = new ConnectionRequest(myURL, true); {

Notice that you must use post and if you have an argument (or try to add one later) it will fail as you can’t have both…​

Dialog Layouts

A while back we fixed Form to have a constructor with a layout manager which reduces one line of code but is also a slight optimization as it saves an allocation of the default FlowLayout that would be there in the first place.

We now added two constructors to Dialog as well that allow you to create a Dialog with a layout manager and a layout manager + title.

Border Layout Improvements

I don’t like the syntax of border layout, the constraint argument makes it overly tedious to work with for most cases but it is one of the best layouts as it’s remarkably consistent and predictable.

To make this slightly easier we added two new capabilities, first we added two new enclose methods:

public static Container centerEastWest(Component center, Component east, Component west)
public static Container centerAbsoluteEastWest(Component center, Component east, Component west)

These allow us to shorten the common use case of wrapping a component in a border layout, e.g. up until now if I wanted to add two components to a border layout one in the center and one in the west I had to do this:

Container c =
            add(BorderLayout.WEST, cmp2);

Now I can do this which is a bit better:

Container c = BorderLayout.centerEastWest(cmp1, null, cmp2);

Another common problem we had in the past is this, see if you can spot the error here:

public class MyClass extends Form {
    public MyClass() {
        super(new BorderLayout());
        add(CENTER, new Label("Hello World"));

Those of you who spotted this might think this won’t compile but it will…​ BorderLayout expects one of it’s constants the string BorderLayout.CENTER but in this case we used Component.CENTER which is an int we derive thru Form.

While this is a "mistake" in theory it occurred to me that there is no "real" mistake here. The programmers intention is clear, why force the usage of a specific constant?

So we added code into BorderLayout that will detect this case and do what you expect for the other constants too (BOTTOM, LEFT, TOP, RIGHT). I would still recommend using BorderLayout as it is slightly more efficient (no autoboxing allocation)

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.