After a discussion with some members of the community we decided to shift the weight of our support efforts to
StackOverflow from our existing
google group discussion forum. Notice that we will still answer questions
in the discussion forum but we strongly prefer using StackOverflow (don’t forget to use the codenameone tag).
There are issues with StackOverflow which is why we are keeping the existing group and will still answer
questions/issues there but the benefits far outweigh the issues:

• Cleaner – stack overflow is far better structured than the discussion forum. This translates to better
  search functionality that can make finding answers much easier
• Google spring cleaning – Many Google projects moved their support to StackOverflow and with Googles
  history of killing projects in use we have some concerns
• Community Collaboration – one of the big issues with the existing discussion forum is that the community
  finds it harder to collaborate and incentives for community support aren’t clear.

As part of this work we also try to answer questions thru StackOverflow even when we get them in other
channels (e.g. email support). This can be helpful as a future reference to users who are looking at the given
issue encountered by a pro user.

Cordova Support Improvements

A lot has changed in the Cordova support since we
originally announced it, Steve
has been hard at work on the following changes:

1. Plugins are now automatically imported when projects are created.
2. Improved documentation, especially for plugin development
3. Plugin development should now just involve implementation of the native portions in Java. The rest is automated.

All of the details are listed in the main port
site.
Documentation specific to plugin development can be found
here.
This effectively means it should be MUCH easier to port plugins to Cordova with these changes.

Easier Text Component Editing

We’ve simplified text editing features in two significant ways, first we just added a set of methods to TextArea
instead of the venerable yet unintuitive methods of Display.
We now have startEditing, startEditingAsync, isEditing &
stopEditing in TextArea. Most of these are pretty trivial with the exception
of startEditingAsync which wraps the call to startEditing in a callSerially.
That’s generally a good practice if you can follow that.

We also added to Form the methods setEditOnShow/getEditOnShow
which allow you to determine a TextArea that will enter editing mode immediately when the form
is shown. This is a common and somewhat error prone use case since its pretty tricky to know when a form
was actually shown (post transition).

Floating Hint

Hints in text fields are really useful to convey information, however they can become really bothersome when
working with details that aren’t yours. E.g. around here Shai and Almog can be both surnames and given names
so a form showing a text field with Shai and Almog might not convey the right information to the user.

So why have a hint at all if we should always use labels as is the case above?
Hints are really convenient since they show a user exactly where to type and are a great convention for a blank
field… FloatingHint offers the best of both worlds. When there is no input or focus in the field
the floating hint appears like a regular text field hint with some extra space above. When there is input or a user
enters the field the hint animates into a small label on top as such:

You need to style FloatingHint in the designer to provide the style for the label on top (the hint
uses the same TextHint). Other than that the code is trivial just wrap any text area/field with a
new FloatingHint(myTextField).

Validation Error Messages

Up until now we provided great validation hints and constraints but didn’t provide any way to show the error
messages related to validation…
We just committed a fix for that where errors will appear as InteractionDialog with the popup
pointing either at the error emblem or at the component. You can enable/disable this functionality on the validator
by using: val.setShowErrorMessageForFocusedComponent(true);

New Default Icon

Up until recently we used our logo as the default icon for Codename One applications, in the next plugin update
we’ll replace it with this image. Obviously you would need to replace it as you would for every shipping application
but as a person whose phone is filled to the brim with Codename One logo icons for all the testcases I need to
run I think this is a huge improvement.