Following with the feedback on the recent survey we spent a lot of time debating how we can improve the general process of documentation and ideally have the community more involved. So one of the first things we did is place our entire developer guide directly into the Codename One Wiki!
This allows any one of you without any special permissions (just a standard github account) to edit the wiki directly. No pull request or anything like that required. The syntax is based on asciidoc which is reasonably intuitive so if you see something wrong/missing etc. just edit it directly, we review all changes after the fact so if you get something wrong we will fix it!
If you want to monitor changes to the wiki and help us maintain it you can use the wiki RSS feed from github: https://github.com/codenameone/CodenameOne/wiki.atom. I also created an ifttt recipe for this but I'm not sure if it works well.
We'd also appreciate pull requests that improve our javadoc comments in the source so feel free to submit such changes as well if you see something that needs adding.
Another issue that was raised in the surveys was performance, this is an ongoing task and a lot of the regressions we had in the past month are related to a heavy commitment we made to native grade performance. Steve recently committed a lot of improvements to the architecture of ParparVM that should significantly boost the performance of some simple calculations and arithmetics bringing them to the level of native C performance by eliminating stack operations and removing the locals overhead.
ActionEvent Type Information
AWT/Swing created a lot of listener type interfaces and classes for practically every possible type of event in the system. This made the code easy to understand but also made generic implementations harder and increased the overall footprint of the JVM for things like AOT compilation.
With Codename One we went to the other extreme which is probably not ideal either (but somewhat hard to fix in retrospect) of using
ActionEvent for everything. This has advantages such as really simple and generic event binding, however it creats a situation where the generic code to process an events can't easily distinguish one type of event from another. Dave Dyer contributed a pull request that added a new type attribute to action events together with a
You can use this new capability with a line like this:
ActionEvent.Type t = ev.getEventType();
You can then use a switch case to handle various types of events or log them to the console for debugging.
Shape API's And Transforms On Mutable Images
Steve implemented the 2D shape API's in Codename One quite a while back. One of the known problems was the fact that some of these API's weren't implemented on mutable images in iOS.
The reasoning for that is that iOS has two very distinct and incompatible pipelines in Codename One. Rendering to the screen is done via OpenGL ES 2.0 and is very fast. Rendering to images is done via the iOS drawing API's which are normally pretty slow but can be done on an offline surface.
With this you can now finally draw charts onto images, however some other effects such as perspective transform probably won't work on an image.
Simpler Padding/Margin in Code
Up until now if you wanted to change padding/margin you had to do something like this:
Getting the padding wasn't much better:
int paddingPixels = style.getPadding(Component.TOP);
We now have two ways to do this that are simpler:
int paddingPixels = style.getPaddingTop();
This obviously applies to the sides/bottom as well.
The main motivation isn't just the shorter amount of code and intuitive nature of the API. Its also slightly faster as some checks become unnecessary by the specific code.
Centering the Toolbar
We added to
Toolbar the ability to center the title that was somewhat lost in the move between the old title and the new
Toolbar class. To the uninitiated it would seem that just styling the "Title" UIID to center should work. It seems to work on the surface but fails when we have uneven element widths to the right & left.
E.g. a sidemenu icon on the left with nothing on the right.
This effectively allocates a space to the title that starts after the side menu and the centering operation is relative to that location not to absolute screen width. By doing it like this we layout everything to the center in the layout level which should produce the desired result.