LWUIT VKB Localization

I just posted a new video showing how you can localize the LWUIT VKB, notice that this only applies to the LWUIT VKB in J2ME. For platforms that have native VKB's such as RIM & Android LWUIT will use the native keyboard by default.

JavaOne 2011 Content Catalog Open: 7 LWUIT sessions/BoF's

Searching through the J1 2011 content catalog for LWUIT produces 7 sessions and BoF's. Surprisingly I didn't even know about most of them and don't know the speakers in quite a few cases.
The one you should probably attend is the one given by Chen and myself 24026 "What's New In LWUIT?". Other than that Ofir & Peter will talk about the LWUIT accessibility effort which is something I haven't talked about much in this blog. Its the effort to make LWUIT usable for people with disabilities ranging from color blindness, blurry vision to blindness etc. Both Peter & Ofir are very engaging speakers and I was personally able to learn quite allot from this important humane effort.

I also have a BoF which I will be presenting with Martin our graphics designer (first time for J1, hell I think this is the first time a designer took the stage at J1), titled Graphics Designer Secrets for Compelling Mobile User Interfaces (20340). In this BoF we will try to bridge the developer-graphics designer gap by showing you how the dynamics and technicalities of the back and forth process between the designer and the developer can become a fertile grounds for innovative UI.

Toggle Buttons & Grouping Them Together

Historically LWUIT never had toggle buttons mostly because we just never got around to implement them. This situation couldn't go on for long and a while back we added toggle buttons although not quite in the way we thought we would.

A toggle button is a button that is pressed and then stays pressed, when pressed again its released. Hence the button has a selected state to indicate if its pressed or not. Just like the radio button & checkbox components in LWUIT. So LWUIT's new toggle buttons are really any button (checkbox & radio buttons derive from Button) that has the setToggle() method invoked with true. It thus paints itself with the toggle button style unless explicitly defined otherwise (note that the UIID will be implicitly changed to "ToggleButton").

The cool thing about this is that you can effectively take your knowledge about checkboxes & radio buttons and apply it to toggle buttons.

That's half the story though, to get the full effect of some cool toggle button UI's we would like to assign the buttons on the edges with a rounded feel like some platforms choose to do... That's pretty easy, you can just assign a different UIID to the first/last buttons and be over with it.

But what if you want your code to be generic? After all you might add/remove a button in runtime based on application state and you would like it to have the right style.

To solve this we introduced the ComponentGroup.

The ComponentGroup is a special container that can be either horizontal or vertical (Box X or Y respectively), it also does nothing else. You need to explicitly activate it in the theme by setting a theme property to true (by default you need to set ComponentGroupBool to true).

When ComponentGroupBool is set to true the component group will modify the styles of all components placed within it to match the element UIID given to it (by default GroupElement) with special caveats to the first/last/only elements. E.g.
1. If I have one element within a component group it will have the UIID: GroupElementOnly
2. If I have two elements within a component group they will have the UIID's GroupElementFirst, GroupElementLast
3. If I have three elements within a component group they will have the UIID's GroupElementFirst, GroupElement, GroupElementLast
4. If I have four elements within a component group they will have the UIID's GroupElementFirst, GroupElement, GroupElement, GroupElementLast

You get the picture... This allows you to define special styles for the sides (don't forget to use the derive attribute to generalize your theme) and provide toggle buttons that include special effects simply by placing them into this group.
You can customize the UIID set by the component group by calling setElementUIID in the component group e.g. setElementUIID("ToggleButton") for the picture above will result in:
ToggleButtonFirst, ToggleButton, ToggleButtonLast

There is a sample of this in the SVN version of the LWUITDemo within the fonts demo. This is a short snippet from there:

 1: 
 2: ComponentGroup buttons = new ComponentGroup();
 3: buttons.setElementUIID("ToggleButton");
 4: buttons.setHorizontal(true);
 5: RadioButton plain = new RadioButton("Plain");
 6: RadioButton underline = new RadioButton("Underline");
 7: RadioButton strikeout = new RadioButton("Strikethru");
 8: ButtonGroup bg = new ButtonGroup();
 9: initRb(bg, buttons, listener, plain);
10: initRb(bg, buttons, listener, underline);
11: initRb(bg, buttons, listener, strikeout);
12: 
13: Container centerFlow = new Container(new FlowLayout(Component.CENTER));
14: f.addComponent(centerFlow);
15: centerFlow.addComponent(buttons);
16: 
17: private void initRb(ButtonGroup bg, Container buttons, ActionListener listener, RadioButton rb) {
18:    bg.add(rb);
19:    rb.setToggle(true);
20:    buttons.addComponent(rb);
21:    rb.addActionListener(listener);
22: }

Keep It In Focus

I rewrote the focus behavior in LWUIT yet again, this is the fifth time so far and I am weary of doing it yet again. We all have these "don't want to touch that" areas of the code, which we avoid like the plague and in LWUIT it was always the focus handling so I gritted my teeth and decided: it can break my compatibility but it will never take the freedom of the code.

I maybe a bit melodramatic here but focus was a nightmare in LWUIT, the main issue is the complex edge cases where a component becomes unreachable via focus. Normally we would say: just call setNextFocusLeft/Right/Up/Down.
However this doesn't work for the HTML component and worse, its not always obvious.
E.g. a specific device with a specific font size/DPI ratio might have a layout that looks different enough for focus to fail on that device and not on another (this actually happened in some of the previous focus implementations).

Eventually after so many focus failures I broke down and wrote the focus vector code where I guarantee every component will receive focus.

So what made me regret that?
The focus is really unintuitive for standard applications and even for HTMLComponent, it jumps around (to satisfy the requirement of visiting everything) and generally doesn't make much sense. However, the thing that triggered a complete rewrite was a benchmark which we failed (more on that in a future post).

Anyway what does this means to you?
You need to test your code with the new LWUIT and make sure your components are reachable, if not you need to use the component methods of setNextFocusUp/Down/Left/Right to define the focus order as you need it.

Shrink Those Resources

I made the t-zone/tipster demo in one day (each... I spent most of the time on the logic), they were really easy to make (once Martin made the PSD's) but when you rush you miss on many "details" such as size. I must admit I was quite negligent letting the t-zone resource file balloon to over 900kb in size and the tipster theme was close to 300kb!
Its easy to lose track of size/performance when you are working within the comforts of a visual tool like the resource editor even if you are the guy who wrote the resource editor...

I suddenly noticed this issue when running on an S40 device (which has a 1mb jar size limit) and so I reduced both resources almost in half without reducing functionality!

When optimizing resource files you need to keep in mind one thing: its all about image sizes.
Images will take up 95-99% of the resource file size, everything else is peanuts in comparison.

Like every optimization the first rule is to reduce the size of the biggest images which will provide your biggest improvements, for this purpose I introduced the ability to see image sizes in KB (see the menu option Images -> Image Sizes (KB).
This produces a list of images sorted by size with the amount of KB each takes. For the t-zone theme the Sun, the moon & Martin were the largest images (which kind of made me think of Game Of Thrones). Turns out these images were all multi-images that I used the wizard to make & in them by mistake I allowed the creation of all multi-image resolution including Very High and HD resolutions. These very high resolution images take up ALLOT of space! Just going to the multi-images, selecting the unnecessary resolutions & deleting these HUGE images (note you can see the size in KB at the top right side in the image viewer) saved a HUGE amount of space!

Next most should probably use the "Delete Unused Images" menu option as well (its also under the Images menu) in my case it detects allot of images used programmatically and didn't help much (it also seems to have a regression in failing to detect usage of timeline images).

If you have a very large image that is opaque you might want to consider converting it to JPEG and replacing the builtin PNG, JPEG's work on most devices and are much smaller. I did this with the LWUIT demo to reduce size but not with the t-zone theme.

Last but not least I added a new feature to the resource editor where you can use the excellent OptiPng tool to optimize image files right from the resource editor. To use this feature you need to install OptiPng then select "Images -> Launch OptiPng" from the menu. Once you do that the tool will automatically optimize all your PNG's, this didn't help much with the LWUIT Demo images but made a huge difference for both t-zone & tipster themes!

The t-zone theme went down to 412kb before compression (from well over 900kb!) and 376,765 compressed bytes!!! The obfuscated JAR which was well over 1.1mb is now 580kb! (594,705 bytes). The icon is 11,233 bytes which means the application logic, MIDlet and LWUIT sum up to 206,707 bytes  a reasonable 201kb for an entirely visual environment.

When faced with size issues make sure to check the size of your res file, if your JAR file is large open it with a tool such as 7-zip and sort elements by size. Start reviewing which elements justify the size overhead.

Preview Of The New LWUIT Demo

Those of you who don't keep up to date with the trunk might not be aware of some of the new stuff going on in LWUIT and even for those of you who do I have some new features bringing the LWUIT demo up to date. Here is an updated version of the LWUIT demo with some new art live as a playable applet.
I updated the resolution to 800x480 to better represent newer devices (although this is entirely configurable and runs well in 240x320 and practically any other resolution). The icons are now multi-images allowing them to scale smoothly to 140x140 behemoths that show the vision of Martin (or UI designer) with much more detail.

To Use the applet just use the pointer for touch, the arrow keys/enter. F1 acts as a menu button (the applet is configured as a Menu button device not as a softkey device) and ESC acts as a back button.

Check out several of the demo features specifically:
1. The animation demo was rewritten to better represent our view of what constitutes an animation.
2. The layouts demo now animates nicely between layouts (highly addictive)
3. The Scrolling demo transitions nicely between list types (grid/horizontal/vertical) even when you are in the middle of scrolling...
4. The fonts demo allows manipulating text decorations and shows off toggle buttons.

There are obviously new themes and allot more going on under the hood which we can't really go into right now.