This Blog Has Moved

Blog moved

2012-01-23T11:36:00.000-08:00

This blog has moved to http://codenameone.blogspot.com/

Delaying Beta Release (Please Blame Git Hub)

2012-01-23T06:07:00.000-08:00

I just lost two days worth of work because of f'ing github, its merge system and UI tool is such an unholy mess that it created a branch long story short I lost 2 or maybe more days of work. (Hard to tell just how much).
This will probably delay us further since now we need to find a new host for the open source and backend sources. I highly recommend you avoid github. They have a nice interface on the Mac but it just fails with weird error messages and on Windows git is a no show, tortoise GIT isn't even remotely in the league of SVN.

Sorry, I won't post any Codename One related material this week. We are trying to get the beta out of the door and this came out in the absolute worse time.

What Is Codename One

2012-01-13T01:00:00.000-08:00

The signup for the private beta of Codename One is now complete, thank you all for the great response to this. You should receive an email within 24 hours regarding your signup status (assuming you signed up).

Codename One is a cross device platform allowing you to write your code once in Java and have it work on all devices specifically: iPhone, Android, Blackberry, Windows Phone 7 & J2ME devices. The biggest goals for the project are ease of use/RAD (rapid application development), deep integration with the native platform & native speed.

To achieve this we looked at the pain points and missing elements within the current environments and added/refined the elements we think are missing. We used the portability experience of LWUIT to effectively reinvent Java programming for mobile devices and still allow full access to the underlying OS including embedding native components in place.

The Codename One solution consists of the following parts:

Codename One API - a Swing like API geared for mobile devices with support for IO, GPS, Media/Camera etc. The UI/IO portions of the Codename One API are based on LWUIT which is highly optimized to mobile device development, multi-resolution and multi-DPI programming.
Native Themes - Codename One ships with native device themes that are implicitly set to a project to ease the integration with the native OS.
NetBeans/Eclipse plugins - for the beta period we will focus mostly on NetBeans support but the intention is to provide a choice of IDE's. The plugin allows easy development without requiring any additional installations of device emulators or platforms.
Simulator environment - Codename One provides a FAST, easy to use and flexible simulator environment to simulate common devices on the market. This environment is highly pluggable and extensible allowing the community to quickly pick it up.
Codename One Designer - GUI builder, theme creator, localization tool and generally the Swiss army knife of Codename. It allows drag and drop application creation as well as unique features such as live preview of the GUI on an actual device.
Build Server - its remarkably hard to get a device build working on one platform and getting it working on 6 (RIM is effectively 2 or even 3 platforms) is one of the hardest things in device programming. Codename One offers a cloud service to seamlessly build your applications for free. You can always compile them locally and avoid the cloud service entirely, that is pretty difficult to accomplish in comparison it also requires a Mac for iPhone builds and Windows for RIM/Windows Phone 7 builds.
Cloud services - Codename One offers cloud services ranging from crash protection to on device debugging and access to web services, push notification, location etc.

I'm hoping you have lots of questions and feedback to give so please provide it in the comments section bellow. I will try to update the FAQ with answers to all the questions.

Simulate It

2012-01-07T23:28:00.000-08:00

One of the things I really don't like about mobile development is the simulators. For those of you who might not know it, I was a member of the WTK (Sun Wireless Toolkit) 1.0 team and Chen was the lead for the Sprint WTK. So we have lots of experience in building device simulators and working with Simulators/emulators.

Despite our best efforts the experience of working with a simulator sucks there are better and worse simulators but the fact still remains that you can't provide the same tooling/ease of use that you get when developing "proper" Java SE code.

As part of Codename One we intend to revolutionize simulators by providing the worlds simplest simulator, it supports proper device scaling (where the fonts are scaled separately to keep them readable) which allows developing on smaller screen sizes. Its wicked fast, highly pluggable, customizable and most importantly completely open source.

Check out the quick demo above and notice how the simulator adapts to different devices resolutions/scaling. I didn't show off some of the nicer things such as its ability to assume native device themes since the tzone demo enforces its own theme.

Live Preview On Device And Beta Signup

2012-01-03T01:53:00.000-08:00

The video above shows the upcoming live preview resource editor feature that will be landing together with everything that's coming. This feature essentially allows you to edit a theme/GUI within the resource editor and the devices are updated INSTANTLY with the changes. This is a huge boon for designers who often need to feel the final result on the device.

Within a couple of weeks we will make the full announcement regarding the upcoming roadmap and exactly where we are headed...

You can start signing up for the private beta cycles by going here, please don't be offended if you don't get picked for the first beta cycles since we are trying to keep them small to iron out the kinks.

One Code. All Devices. No Compromises!

2011-12-26T10:10:00.000-08:00

Wouldn't it be great if you could write your code once and actually have it work on all the devices out there?
Wouldn't it be great if you could develop to iPhone/iPad without a Mac?
Wouldn't it be great if you could develop to Windows Phone 7 without a Windows 7 PC?
Wouldn't it be great if the simulators started instantly and were fast so you don't have to wait for them?
Wouldn't it be great if the simulators allowed you the full richness of the Java debuggers and QA tools?
Wouldn't it be great if the you had a single visual development environment that "just worked"?
Wouldn't it be great if that environment would just preview all your changes instantly onto devices?
Wouldn't it be great if you could do wireless on device debugging?
Wouldn't it be great if application crashes would just send you the stack trace information and user feedback?
Wouldn't it be great if you could just give a design tool to your designer to work with and then just bind the code afterwards?

So many great things are coming, too much to mention.

Sorry for being a tease ;-)

Coming Soon

2011-12-19T21:04:00.000-08:00

I will provide more details as I can divulge in January. Keep watching this space.

I Suck At Photoshop

2011-12-12T06:17:00.000-08:00

I was looking at the presentation from Eric Burke about the work square did with Android which resulted in a really nice UI. He tells about quite a few struggles they had with the Android API which seem to be pretty easy to get around in LWUIT.
Anyway, one of the nicest things they did was the screenshot on the right which features a leather texture with stitches as the UI for the application which is a really nice touch for a wallet application (assuming you aren't a vegan).
Anyway, that took me back a bit... How do you make a UI like that regardless of the platform that will look nice for all resolutions. I came up with the answer but because I suck at Photoshop I wasn't able to achieve anything remotely close to the image on the right... This just goes to show you how valuable professional design can be to a team.
The way to produce an image like that is start with a clean tileable leather texture such as this one which I got from here and scaled down:

I set this as the style of the Form UIID and made it TILE on both axis's. Then I created a simple transparent gradient image, its so transparent you might not even see it but its very important to create the texturized depth to the image above:

I created a container and placed it above the form and gave it a style of Gradient, then I set this image as the scaled background (since this is an alpha mask scaling won't hurt the image quality much).
Last I created a stitch image by using a stitch brush tool I found on the internet and this is the stitch image I was able to make (I set the background to red since the image is barely visible otherwise):

I set the stitches as a 9-piece border which allowed them to grow nicely. However, due to the bad source material the end result doesn't look nearly as polished as the work the guys from square were able to achieve. I'm guessing they have a depression overlay with the stitch layer to create an additional effect and their images are obviously more refined. This is what I ended up with in the resource editor:

Using EmbeddedContainer

2011-12-04T23:55:00.000-08:00

EmbeddedContainer is a class I added to LWUIT 1.5 without much fanfare out of a simple necessity, the problem is that this necessity existed only within the GUI builder and the class makes no sense outside of the context of the GUI builder. How do you document something like that???
The necessity came about due to Triplay's application designs (our original GUI builder beta site), their design was iPhone inspired and so it relied on tabs (iPhone style tabs at the bottom of the screen) where different features of the application are within a different tab.

This didn't mesh well with the LWUIT GUI builder navigation logic and so we needed to rethink some of it. I wanted to reuse GUI as much as possible while still enjoying the advantage of navigation being completely managed for me.
Android does this with Activities and the iPhone itself has a view controller, I don't like both approaches and think they both suck. The problem is that you have what is effectively two incompatible hierarchies to mix and match which is why Android needed to "invent" fragments and Apple can't mix view controllers within a single application.

The Component/Container hierarchy is powerful enough to represent such a UI but we needed a "marker" to indicate to the UIBuilder where a "root" component exists so navigation occurs only within the given "root". Here EmbeddedContainer comes into play, its a simple container that can only contain another GUI from the GUI builder. Nothing else. So we can place it in any form of UI and effectively have the UI change appropriately and navigation would default to "sensible values".

Navigation replaces the content of the embedded container, it finds the embedded container based on the component that broadcast the event. If you want to navigate manually just use the showContainer() method which accepts a component, you can give any component that is under the EmbeddedContainer you want to replace and LWUIT will be smart enough to replace only that component.

You can see an example of building a simple Tab based UI with the GUI builder and embedded container in the video above. The nice part about this is that this UI can be very easily refactored to provide a more traditional form based UI without duplicating effort and can be easily adapted to a more tablet oriented UI (with a side bar) again without much effort.

Interview With Peter & Ofir From JavaOne

2011-11-30T00:46:00.000-08:00

When we were at JavaOne this year Ofir and Peter sat down for a chat about the LWUIT accessibility, which you can read about there. Its a fascinating and complex subjects that we don't spend much time thinking about.
Listen to their interview in the Java Spotlight mobility podcast.

How LWUIT Is Different (better) From Swing

2011-11-27T23:54:00.000-08:00

I've been meaning to write an introduction to LWUIT for Swing developers, for quite a while so this is it. We were highly inspired by Swing when writing LWUIT and that inspiration allows Swing developers instant familiarity into LWUIT thus providing them a very easy path into mobile development without the hassle.

The best way for a Swing developer to get into mobile is just to open a LWUIT based project and start working, its just that simple! At first the use of styles might seem slightly alien but you get used to it instantly and its ridiculously familiar.

There are quite a few differences between LWUIT and Swing which came thanks to the fact that we could learn and adapt from Swing. So LWUIT is in effect better than Swing mostly thanks to it being newer. Here is a list of highlight/bullet points for Swing developers wishing to take a look at LWUIT.

What's Similar:

Component/Container hierarchy with layout managers to arrange the elements. All the old friends are there with some additional added features (GridLayout, BorderLayout, BoxLayout, FlowLayout, GroupLayout) and some new (TableLayout, LayeredLayout). Naturally LWUIT doesn't feature the whole JComponent sub hierarchy and maintains a simpler hierarchy.
You can override paint and get a graphics object to do whatever you want. LWUIT is lightweight (just like Swing) and draws everything on its own to maximize portability and flexibility
You can add/remove action listener and similar observer based patterns for various events
Dialogs can be modal, so when you use Dialog.show() or similar method the next line won't execute until the dialog is disposed. Like in Swing, this is entirely optional.
LWUIT has a glasspane, its a bit different from the Swing glasspane but very similar in functionality
List model and list cell renderer, pretty much like Swing's API with added functionality for animations and horizontal lists.
ContentPane for the body of the Form (LWUIT's root component) which is technically hidden
The LWUIT EDT requires that you interact with it over a single thread, it has a callSerially method (invokeLater), callSeriallyAndWait (invokeAndWait) and even an invokeAndBlock (foxtrot for the advanced swing users)

What's Different :

Optimized for phones/tablets both touch & feature phones. This includes support for gestures and complex key layouts
Styles & Themeing - the PLAF is much narrower in LWUIT (due to size constraints) but LWUIT makes up for it by having a Style object associated with every component. Furthermore, LWUIT allows customizing said styles with a theme that can be created visually using an open source resource editor tool!
Animations are integrated in the core of LWUIT in several levels. You can animate layouts, transitions and just arbitrary objects.
The resource file format is an integral part of LWUIT (although technically completely optional) it offers a GUI builders (optional but quite helpful), theme creator, localization etc. Unlike matisse it doesn't generate any code thus providing a more VB like experience where the UI and code are cleanly separated. The tool can be given to a designer with no coding experience
Painters - Swing tried to integrate painters after the fact and failed since the framework needs to be designed with them to begin with. We did just that. We also separated background painting from foreground painting and made it easier to override just background painting.
Deep and elaborate porting layer allowing LWUIT to be ported to any platform easily
LWUIT is truly open source - while Swing was technically open sourced, debugging/modifying Swing was not trivial since it was integrated into the JDK. This also prevented developers from incorporating fixes (or a known working version) into their build.
LWUIT is bundled with the application so you can easily fix it and very easily modify code/debug to locate/fix issues. The development is easy to follow with a public viewable SVN. You can actually get commits from us as we fix issues and add features.

Places Demo Part V: Location Animation

2011-11-21T04:38:00.000-08:00

Simple animations to provide a sense of place/navigation are what makes an application shine. They attract the attention of the user to the ongoing operation within the application while providing a sense of continuity, in that sense they are not "fluff" and should be taken very seriously.
One of the nicest things in the places demo is the animation on the map bellow which you should be able to see in the video above. When selecting a city within the demo we can see an animation of the map highlight moving to a new location. To do that we need to start with the map location image here (I set the text background to red to make the white image visible):

We can add this image by using the add multi-image dialog as such:

And now we need to go back to the GUI builder to place the image on the map, don't worry about the location we will get to that soon enough. I select the Map Label entry and change its name to Map (to make it easier to work with it in code), I also change the name of the List at the bottom to cityList.
Next drag a container into the same container where the Map is currently at and set its layout to layered layout. Make sure that the Map entry is before the Container entry which you just added (you can rearrange them in the tree). Drag the Map into that container and place another new container next to it. Drag a label into the new container and call it "MapHighlight", set its text to an empty string, set its UIID to container and select the mapPosition.png image as its icon. You should end up with something that looks like this:

Now its FINALLY time to start writing some code... Click the menu Application->Generate Netbeans Project. Type the name "LWUITPlaces" and select a directory into which the project should be generated.
Important: you do this only ONCE after that saving the file will automatically update the generated code for you. Also important: If you saved the file in the past the old location is no longer relevant! The resource file will now be within the src directory of the generated project and can't be moved from that location.

In the GUI select the Form and select the events tab in the properties on the right, click the "Before Show" button. This should open the StateMachine.java file in Netbeans and create a method like this:
    protected void beforeMain(Form f) {
        // If the resource file changes the names of components this call will break notifying you that you should fix the code
        super.beforeMain(f);

    }

Before we continue go to the top of the class and add the following variables and constants:
    private static final int MAP_ORIGINAL_WIDTH = 178;
    private static final int MAP_ORIGINAL_HEIGHT = 114;
    private int mapActualWidth;
    private int mapActualHeight;
    private static final int [][] MAP_POINTS = {
        {10, 65},
        {0, 42},
        {77, 75},
        {146, 37},
        {107, 33}
    };

    private int mapSelection = 0;

We will also need these methods to exist:
    private int mapXCoordinate(int c) {
        return (int)(((float)c) / ((float)MAP_ORIGINAL_WIDTH) * ((float)mapActualWidth));
    }

    private int mapYCoordinate(int c) {
        return (int)(((float)c) / ((float)MAP_ORIGINAL_HEIGHT) * ((float)mapActualHeight));
    }

Some of these things might seem obvious but others might not. When we animate to a particular list offset we need to know the pixel coordinate of the city within the Map. This worked great in Martin & Chen's demo since they used a regular image as the map. The problem is that a regular sized image would not work for lower/higher resolution devices which is why I used a multi-image.
Once I used a multi-image the resolution of the image (hence the coordinates) would change depending on the device, so all the old city coordinates from Martin will no longr work (these are the MAP_POINTS coordinates).

The trick is simple, I ask the size of the map image in runtime and store it within the mapActualWidth/Height variables. Then I calculate the position in map offsets using a simple ratio equasion in the mapXCoordinate/mapYCoordinate methods.

Back to the beforeMain method (under the super call) we will write the code to position the selection based on coordinates. With the comments within the body I hope the content of this method is clear enough:

Places Demo Part IV

2011-11-14T07:15:00.000-08:00

Last time we left off with the UI partially implemented yet we left one of the hardest features still ahead: the annoying circular button.
To implement that button we will first select the top area container (the one with the MainList UIID) and set its layout to box layout Y. We will then drag a container (which will represent the first entry in the list) into that container, we will set the layout of that container to LayeredLayout!
We will then place two containers within the layered layout container and set both to BorderLayout. We will add a button to the center of the first (label it Attractions) and a label to the west of the second (give it a " " space label, important do not leave it blank make sure a space is there!).

One last thing I forgot the last time, update the padding of the MainList UIID to 10 on all sides to keep the entries at a healthy distance from the border.

You should end up with something like the image bellow:

What we did is create a layered layout which places one component on top of the other and we used two containers with their layout to position a label on top of a button pretty much like we would do for the actual layout of the button.

Now lets style this to actually look like the end result, change the UIID of the attractions button to ListEntry and open its unselected style. Use this image to create an image border (notice I placed the same image in my first post in this series but it had a small artifact on it so use this one!):

And define the image border as such:

After generating the image border select the Margin and define 5 Millimeters on the left side and 1 millimeter on every other side. Notice that using millimeters allows us to scale the padding/margin more appropriately to higher/lower resolutions.
Then select the padding tab and define 5 Millimeters on the left and 15 pixels on the other sides.
After pressing OK you should have something like this:

Now select the parent container of the button and set its style to PaddedContainer, set the padding to 10 pixels on the left 0 on the right 4 on top and 4 on bottom. In the derive tab select deriving from Container. This will ensure that the button will always be smaller than the label which is important for the base design.

Now add the following images as multi-images:

Using the "Add Multi-Images" add these 4 icons as such:

Open ListEntry's selected/pressed style and in the derive tab type "ListEntry" unselected to derive the same style.

Select the label for the first entry and set its UIID to AttractionsIcon, edit its style and set the background to image scaled and attractions.png image from above:

Set the padding of the style to 5 millimeters on all sides and the margin to 0 on all sides.

You should end up with this result:

Which is already pretty much what we are looking for. Now just right click on the attractionsContainer and copy it. Paste it to the parent container 4 times and update every entries icon/text to this end result:

Now just so you will understand why we did all of this, this is how the UI will look on the iPhone scale resolution (3GS = 320x480):

Here is what it will look like on a Nexus One device (480x800, larger font):

Notice that after blogger scaled down the images they look almost identical, but if you will click to zoom you will see they are sized very differently.

Lets proceed with the easy parts!
Select the main form and uncheck the scrollable Y property. Then select the Container with the MainList style and check its scrollable Y property. This will effectively make sure that horizontal scrolling doesn't hide the bottom section of the screen.

Now lets add the entries in the list, select "Add Multi-Images" and select the following images:

Use these values for the multi-image dialog:

Now select the UI section in the GUI builder and click the + button on the top left to add a new Blank Container. Call it CityRenderer.
Set its UIID to "Renderer" and edit the style, set its derive tab to derive from Container and set its margin left/right to 15 millimeters.

Set the layout of the container to border layout and place two labels one in the north which you should name "Icon" (notice this should be the name not the label text!) and another in the south which you should name "Name" (yep).
Set the UIID of the North label to Container and the UIID of the south label to WhiteLabel. Edit the style of white label, set its foreground color to white and make its transparency 0. Set its alignment to Center.

In the theme add a new Style in the selected tab called RendererFocus and set it to derive from Container.

You should end up with something like this:

Go back to the Main form in the UI builder and select the list of cities at the bottom, select the ListItems property and remove all the elements within it. Click add entry and add elements one by one starting with San Francisco (and the matching image from above) using the key Name for the city label and the key Icon for the image to this end result:

Follow this up and add all the cities from above to the list.
After pressing OK select the list and set the fixed selection to Center and uncheck the scroll visible flag.

Last but not least select the Main form and type "LWUIT Places" in the title attribute, then create a title style and use this image to generate the border:

Now use the border wizard as such:

And we are done! This is the final result:

Places Demo Part III

2011-11-07T03:42:00.000-08:00

OK, its time to get started with actual resource editor work. First we need to launch the resource editor and create a new blank theme.

BTW If you follow along don't forget to save frequently, unfortunately the resource editor doesn't yet offer proper "crash recovery" it is in my todo list but is a rather hairy problem.

Then I define the form background to a vertical gradient starting from d8fe:

The next stage is going to the GUI builder and creating a new form (I called it Main, but call it whatever you want). I set its layout to border layout and placed two containers within it (in the center and in the south), these containers will hold the UI for the two portions of the screen.

It should look something like this:

Then we need to allow for the design of the top area texture, for that we will add a new multi-image using the Images->Add Multi-Images option and select the skyline image here:

Notice that I am selecting the full size image and not the one included in the blog!

Then I am prompted to select the resolutions to the multi images. Notice that I filled out the percentages (to 100 and 61) and only then updated the values to 0 where appropriate.

This dialog effectively tells the resource editor which size images it should manufacture for every resolution. I selected 100% for width which means I want the typical width of a device class as listed above (since the image needs to occupy the full width) and selected 60 percent height to match the image dimensions.
I zeroed out the values of the fields for which I didn't want an image created, very high resolution images would make my resource file too large and very low res images will be pointless for this sort of application.

After pressing OK I select the first container and set its UIID property to "MainTexture", I then right click it and select Style->Unselected to edit its style. I select "Image Tile Horizontal Align Top" and within the derive tab I type in Container (to inherit the behavior of the Container style).

Notice that the image might not tile properly sometimes due to its size, in which case we can increase its width slightly. Ideally an image that tiles "properly" will provide the best background texture.

You should have something that looks like this:

And the GUI should look like this:

Now we would like to add the carousel to the bottom of the screen and the map.
We add the map image using the same multi-image approach from before:

We then select the second container and select BoxLayout_Y as its layout. We drag two containers into it. We select the containers and select for both the FlowLayout layout type, and configure it to align to center. This allows us to center the elements within the containers.
We drag a label into the top first of these two containers, set its UIID to Container and set its icon to the map image.
We drag a List to the second container and configure its orientation to be Horizontal. You should end up with something that looks like this:

We will implement the list bellow in the next part but lets at least finish the main sections of the top part... Go to the top container (the one I called Container1 which we placed in the Center) and set its layout to border layout, drag a container into its center area.
Set the UIID of that new container to MainList and its layout to box layout Y.
Edit its style by right clicking it and selecting Style->Unselected, in the derive tab type in "Container". Select the border tab and click the image border wizard.
Use pick image to pick the list image here:

And fill out the cutting setting as such with 30 px for every direction and Low/Medium multi-image generation:

After pressing the generate button close the wizard and select the margin tab, define 10 pixels for every direction and click OK.
This should produce something like this:

Next time I will continue from this point to complete the UI of the first form.

Places Demo Part II

2011-11-02T02:22:00.000-07:00

In the first part of this series I went over the image Martin and Chen produced, in this part I'll review the path that needs to be taken in order to take this image and make it into an actual application fit for all devices.

The first part is divide & conquer, we need to divide the image into its basic elements:
Backgrounds
Component looks
Content

Photoshop makes this division relatively easy since it already divides elements to layers, although often these layers make sense in photoshop and not within our application. So reviewing this image:

We have the following elements in the background:

Gradient from 00d8fe to black:

Translucent texture image, notice that this image is translucent and it appears here on the background of the blog. When layered on the gradient it will look quite different:

Effectively these two come together to form a background like this:

Notice the color at the top its actually the area where the title bar background should reside, that is a part of the title component design.

The components within the design are far more complex, there are easy elements such as the title:

And the list background:

Which are both pretty easy. It gets complicated when looking at an element like this:

Obviously the word Bars is part of the foreground its just here for visualization. As you can see the round portion of the cup fits snugly into the button, because it contains and icon and is aligned perfectly to that icon it can't be separated from that icon.
Yet because it aligns to the button and the button needs to grow with the text within it we might end up with something that looks like that:

Which is obviously very far from the original design! There is no way to actually solve this problem that would be truly satisfying so we will make some compromises.
We will treat this element as the component:

And we will always scale the icon on the left to fit that element so it will be covered perfectly. Its not an ideal solution since it requires scaling the background image which can cause degradation.

The rest of the images and the text within the application are really just the content, this separation is critical since elements that are background elements should be incorporated in the theme and elements that represent content should be incorporated into the UI.

In the next post I will start explaining how to move this logic into the resource editor and create the UI for this demo.

Places Demo & The Graphics Designer BoF

2011-10-24T23:53:00.000-07:00

With the uncertainty of travel arrangements to JavaOne we didn't prepare anything for the Graphics Designer BoF & just intended to review our existing demos.
A day before the BoF Martin created this Graphic PSD, he and Chen worked quite allot to get it into a working demo state. I initially dismissed the attempt to do this when I glanced at the graphic he prepared, there are several "mistakes" you can see in the graphics if you have any experience in building UI's to scale to multiple resolutions/devices.

The first and obvious "mistake" is the background, its a texture. If we will scale it, it would look "odd" and when a device is rotated we won't have an option. Not to mention supporting multiple device resolutions.
Sure we can add a version for every resolution but once you start going down that path you enter the maintenance hell that is the true cost of software development.

The second mistake isn't quite as obvious, the icons for the 4 options are round and perfectly aligned to the content. This might not seem like a problem but it is quite a big one. The font will have different sizes on different devices (due to device density variation) but the icons have a fixed size that doesn't depend on the font size. Due to the box that surrounds the font the text effectively becomes dependent on the icon size. So the text might appear grotesquely small or freakishly large in comparison to the icon and the box that surrounds it.
Martin "solved" this by using a bitmap font, however that's a poor solution since it might look good on one device and awful on a higher/lower DPI device.

The last major issue isn't as obvious, the map on the bottom wouldn't have enough space in landscape mode due to the large amounts of whitespace distributed all around.
This might actually be the easiest issue to resolve by moving the map graphic to the side in landscape mode.

Its unclear from the graphic but Martin intended to have the map animate and the cities in the bottom to be swipeable, Chen and Martin actually implemented this full demo with a few additional screens not shown here. In the next few weeks I will try to go over the process of creating a demo like this from a PSD deliverable and adapting that demo to partially resolve these various issues I raised.

Interview and HOL

2011-10-19T21:54:00.000-07:00

Here is a LWUIT interview I did at J1. I was sick and after a long flight, normally I'm more eloquent...

The hands on lab that Daniel Green submitted and I wrote was refined by his team and is now an easier to follow PDF which you can download from the Java One content catalog by searching for 24682 and clicking the small PDF icon that appears next to the session details. Thanks to Terrence for that tip.

Back From J1 2011

2011-10-10T23:54:00.000-07:00

JavaOne 2011 is finally over, its been a hectic week for us both because of the cramped timeline (we had to hurry back home due to complex holiday logistics) and because of the huge distance between my hotel and the venue.

By all accounts this years J1 was bigger & better than last years although it wasn't the same as the old J1 in moscone. Hopefully the trend of improvement will persist to next year and the conference will be restored to its former glory.

Despite the relatively weak attendance in the the mobility track and our own session (which had problematic scheduling) the BoF I had with Martin (in the picture above you see from left to right, Martin, myself & Chen) was pretty full. The hands on lab was also full although it was mired by an admin choosing to randomly reboot peoples PC's while they were working and problematic lab setup. Since we arranged this lab as a sort of last minute thing its amazing that we got it off the ground and even had a decent attendance.

Martin & Chen created a pretty cool demo for our BoF, when I get the time I will clean it up and create something more robust based on it. Right now my desk is full with so many tasks postponed to "after" JavaOne.

My Music Cloud Finally Available

2011-09-30T02:02:00.000-07:00

Remember Triplay? They guys behind the musix application. They are back now with My Music Cloud, a music service similar in a way to Google Music effort with a few advantages such as being available internationally on all devices etc.
The service essentially downloads music to the device from the cloud server and allows you to purchase additional music directly to the cloud server.

The entire application is based on LWUIT with the exception of the iPhone port. The J2ME, Blackberry & Android versions of the application were implemented using the LWUIT GUI builder.

Unlike the musix application which was operator bound you can check the MMC application right now by going to their website right now and following the instructions to try out this application.

Major LWUIT Developer Purchased For 300M USD

2011-09-27T21:13:00.000-07:00

Telmap was just purchased by Intel for the sum of 300,000,000, they haven't made an announcement though. While a huge portion of their effort is the server side and that deserves a great deal of their value, I can't think of a single company who bet more heavily on LWUIT.
In a recent visit to their headquarters they showed us pretty spectacular things such as their LWUIT port to native Windows Phone 7 and a tool that allows them to modify and preview resource files on devices. Very cool.
Telmap adopted LWUIT at a time when it had a fraction of the features it had today and used it to get their applications UI far and wide into the devices of the world. Their Android port is based entirely on LWUIT and the work from Thorsten and their RIM port as well.
Telmap has also made one of the most elaborate LWUIT source contributions for RTL (right - to left, bidi) support, displaying their faith in the open source model and giving back to the community.

Congratulations guys on a well deserved exit and recognition of your efforts!

Update: The story has made it to the usual guys, here is an English article in Slashgear. BTW I neglected to mention that during our visit to Telmap headquarters we talked quite a bit about their future and past with LWUIT. The technical guys were very bullish on LWUIT and indicated that they have no intention of shifting direction. They claim that they save a fortune in maintenance costs by focusing on a single code base, their mobile team is indeed quite small relatively to the complexity of their application and the amounts of platforms supported.

LWUIT and Facebook API - by Chen Fishbein

2011-09-18T03:59:00.000-07:00

Nowadays almost every app needs to be connected to facebook in some level: post a message to your friends wall, post on your wall, like a post, etc...

We are well aware of such need and we are well aware of the lack of support for J2ME devices.

Connect an app to facebook sounds something trivial that every smart phone is doing very easily, but doing the same on a J2ME device is almost impossible.

Facebook uses Oauth2 to authenticate which basically means you need a browser to display the login page and the ability to handle a session on the client until login is authenticated.

In the last couple of months we worked very hard to finally offer such solution to LWUIT developers, now you can use a very simple API to access Facebook.(it's important to note that this won't work on all J2ME devices, due to a relatively new/complex certificate facebook is using, which some old devices has difficulties with, even the good old WTK won't work - this will require a nokia SDK or the upcoming SDK 3.0.5 from Oracle which should be released soon)

The new API has a new Demo which is available from our svn:

https://svn.java.net/svn/lwuit~svn/trunk/Apps/FaceBookDemo

In addition we created an official facebook lwuit page which is open for lwuit discussions

https://www.facebook.com/pages/Lwuit/132932836804285

Some API samples:

//authenticate your facebook app with the permissions you need

FaceBookAccess.getInstance().authenticate(appid, redirect_uri, new String[]{"user_photos", "friends_photos", "publish_stream", "read_stream", "user_relationships", "user_birthday", "friends_birthday", "friends_relationships", "read_mailbox", "user_events", "friends_events", "user_about_me"});

//then create a User Object and ask the FaceBookAccess to fill it with the data

User me = new User();

FaceBookAccess.getInstance().getUser("me", me, null);

Recipe Book HOL Draft

2011-09-15T04:01:00.000-07:00

This is a quick draft of my hands on lab for JavaOne where we go over creating a GUI builder Recipe book application. Let me know what you think.

Launch the LWUIT Resource Editor application from the utils directory under the LWUIT distribution directory.

Create a new basic wood theme in the theme tab

Go to the UI Tab in the resource editor and add a new UI entry, name it “Splash Screen” to create a new splash screen.
Set its layout to border layout with “absolute center” place a label in the center and give it the text Recipe Book.
At the south area place a slider component, set it to infinite mode and set its text to an empty string.

Create a new GUI form and name it Main. Go back to the Splash Screen and define next form as Main.
Set the title of Main to “Recipe Book”, set the layout to BoxLayout Y so elements may be organized from top to bottom.
Drag a Container into the form and select it. Set its layout to GridLayout with 2 rows and two columns.
Drag 4 buttons into that container and name them add, edit, exit & settings. Make sure to update their labels as well.
Use the “Images->Add Images” menu item and select the images add.png, edit.png, exit.png & settings.png

Go to each of the buttons, select the appropriate icon and set the text position to bottom. You should end up with a form that looks like this:

Create a new form and call it “Add Recipe” go back to the main form and select the add button. In the properties section click the Command entry, leave most of the defaults select the Action to point at “Add Recipe” which will trigger navigation to the add recipe page.

Click the exit button and click the command for that button, select the “Exit” action for this button.
Select the “Add Recipe” form and click the form. Set the title to “Add Recipe” set the layout to border layout. Drag a container into the North portion of the form and set its layout to table layout with 2 columns and 4 rows.
Drag the following components into the table layout container 4 labels, text field, combo box, text area & button.
Arrange the elements within the table layout container either by dragging on the tree or within the UI place all the labels to the left and arrange the component order so the text field is first, the combo box second the text area third and the button last.

Give the labels the following text: “Title”, “Type”, “Steps” & “Image”.

Give the components equivalent names to the labels besides them: text field = title, combo box = type, text area = steps & button = image.

Set the text of the text field to an empty string.
Click the list items entry in the combo box and remove all the “Item *” entries. Add 3 entries by selecting the String radio button and typing in the text field bellow the table. “Savory”, “Sweet” & “Spicy”:

This should be the result:

Select the text area and clear the current text, set columns to 20 and rows to 5.
Select the “Steps” label next to the text area, click “Layout Constraints” and set the vertical align to top.

Select the button and set its text to “...”, set its UIID to “Label”.

You should end up with this:

Now you can actually go to the “Theme” section in the resource editor and play with a live functioning version of your application. Within the theme select the “Preview Settings” button and select “Splash Screen” as the first form.

Select the Menu Item “Application->Generate Netbeans Project”.
You will be prompted to select the main screen select the “Splash Screen”

Then you would be prompted for a project name, its probably best to avoid spaces or special characters in a project name:

You will now receive a directory to which the project will be generated, notice that if you saved the resource file previously this old copy would be discarded and the resource file will now reside in the src directory under the directory you have given.

If Netbeans isn’t detected you will now be prompted to find the Netbeans executable under Program Files. Once the project is generated you should have 4 projects in Netbeans:
RecipeBook - Main library project where the cross platform LWUIT code & resources reside
RecipeBook_Desktop - Port to Java SE allowing you to rapidly run your code on the desktop and also generate Applets from LWUIT applications.
RecipeBook_RIM - Enables building native RIM applications from LWUIT applications.
RecipeBook_MIDP - Enables building MIDlets for J2ME mobile devices

Some of the projects might be marked in red for unresolved dependencies due to different emulator settings etc. If the RIM project is marked in red ignore it for now since it requires setting up a RIM environment. For the other projects right click the project and select properties, select Platform and make sure the proper environment is configured as CLDC 1.1, MIDP 2.0 and all the optional packages are checked (this is mostly for compilation and isn’t required in runtime).

Go back to the resource editor and select the “Add Recipe” form click the “Commands” entry and select “Add”. Type “Add” as the name of the command, select “Main” as the action of the command and click the “Go To Source” button (if Netbeans pops up go back to the resource editor) click OK to dismiss the dialog and press the save button in the resource editor toolbar (whenever save is pressed code is generated).

Go to Netbeans you should see the source code for the “Add” command callback:
    protected boolean onAddRecipeAdd() {
       // If the resource file changes the names of components this call will break notifying you that you should fix the code
       boolean val = super.onAddRecipeAdd();

       return val;
    }

What we have is a method that will be invoked before the command is processed we can add our custom code to save the data. First lets create a recipe object, right click the userclasses package and select “New Class”. Give the class the name Recipe and enter the following fields:

    private String title;
    private int type;
    private String steps;
    private byte[] image;

Select the menu “Refactor->Encapsulate Fields” and select all the fields so you will have getters/setters for the fields.

Add an implements Externalizable to the class and make sure to import com.sun.lwuit.io.Externalizable.
You will be prompted to implement the missing methods, accept this prompt which will generate the following method stubs:
    public int getVersion() {
    }

    public void externalize(DataOutputStream out) throws IOException {
    }

    public void internalize(int version, DataInputStream in) throws IOException {
    }

    public String getObjectId() {
    }

Make sure to import com.sun.lwuit.io.util.Util for the following step, implement these methods as such:
    public int getVersion() {
           return 1;
    }

    public void externalize(DataOutputStream out) throws IOException {
            Util.writeUTF(title, out);
            out.writeInt(type);
            Util.writeUTF(steps, out);
            if(image == null) {
                   out.writeInt(0);
            } else {
                   out.writeInt(image.length);
                   out.write(image);
            }
    }

    public void internalize(int version, DataInputStream in) throws IOException {
            title = Util.readUTF(in);
            type = in.readInt();
            steps = Util.readUTF(in);
            int s = in.readInt();
            if(s == 0) {
                    image = null;
            } else {
                    image = new byte[s];
                    in.readFully(image);
            }
    }

    public String getObjectId() {
           return "Recipe";
    }

Go back to the state machine to the onRecipeAdd method and add the following code:
protected boolean onAddRecipeAdd() {
       // If the resource file changes the names of components this call will break notifying you that you should fix the code
       boolean val = super.onAddRecipeAdd();
       Form root = Display.getInstance().getCurrent();
       Recipe entry = new Recipe();
       entry.setTitle(findTitle(root).getText());
       entry.setSteps(findSteps(root).getText());
       entry.setType(findType(root).getSelectedIndex());
       EncodedImage e = (EncodedImage)findImage(root).getIcon();
       if(e != null) {
                   entry.setImage(e.getImageData());
       }
       Vector recipes = (Vector)Storage.getInstance().readObject("recipes");
       if(recipes == null) {
               recipes = new Vector();
       }
       recipes.addElement(entry);
       Storage.getInstance().writeObject("recipes", recipes);

       return val;
}

In the initVars method of the state machine you must register the recipe class as such so the deserialization code can work:
       Util.register("Recipe", Recipe.class);

Go to the Main class in the Desktop project and the MIDP project and add this code just bellow the Display.init() call :
       Storage.init("RecipeBook");
       NetworkManager.getInstance().start();

Go to the resource editor and select the “...” image button, in the tabs pick the events tab and click “Action Event”. This should create a new method in the state machine class:
    protected void onAddRecipe_ImageAction(Component c, ActionEvent event) {
           // If the resource file changes the names of components this call will break notifying you that you should fix the code
           super.onAddRecipe_ImageAction(c, event);

    }

Update the code to allow image picking:
protected void onAddRecipe_ImageAction(final Component c, ActionEvent event) {
       // If the resource file changes the names of components this call will break notifying you that you should fix the code
       super.onAddRecipe_ImageAction(c, event);
       final GoogleRESTService r = new GoogleRESTService(findTitle(c.getParent()).getText(), GoogleRESTService.IMAGE_SEARCH);
       r.setResultSize(8);
       final Progress p = new Progress("Searching", r);
       p.showPacked(BorderLayout.CENTER, false);
       r.addResponseListener(new ActionListener() {
                public void actionPerformed(ActionEvent ae) {
               p.dispose();
               Vector results = r.getResults();
               Container options = new Container();
               for(int iter = 0 ; iter < results.size() ; iter++) {
                   if(results.elementAt(iter) instanceof GoogleRESTService.ResultEntry) {
                           GoogleRESTService.ResultEntry e = (GoogleRESTService.ResultEntry)results.elementAt(iter);
                           if(e.getTbUrl() != null) {
                           Button selection = new Button();
                           options.addComponent(selection);
                           ImageDownloadService img = new ImageDownloadService(e.getTbUrl(), selection);
                           NetworkManager.getInstance().addToQueue(img);
                           selection.addActionListener(new ActionListener() {
                                   public void actionPerformed(ActionEvent ae) {
                                             ((Dialog)Display.getInstance().getCurrent()).dispose();
                                            findImage(c.getParent()).setIcon(((Button)ae.getComponent()). getIcon());
                                            c.getComponentForm().revalidate();
                                      }
                                 });
                              }
                       }
               }
               Command cancel = new Command("Cancel");
               Dialog.show("Pick Image", options, new Command[] {cancel});
               }
       });
       NetworkManager.getInstance().addToQueue(r);
}

Create a new form in the resource editor called “List Recipes”, go back to the Main form and edit the command for the “Edit” button so its action will be “List Recipes”.
Go back to “List Recipes” and set the layout to BorderLayout, uncheck the scrollable Y property, set the title to “List Recipies” and drag a list to the center. Select the List and name it recipeList, move to the events tab and click List Model.
You should end up with something that looks like this:

Save the resource and go to Netbeans where a new method should appear:

protected boolean initListModelRecipeList(List cmp) {
       // If the resource file changes the names of components this call will break notifying you that you should fix the code
       super.initListModelRecipeList(cmp);
       cmp.setModel(new DefaultListModel(YourDataHere));
       return true;
}

Replace the setModel line with this code:
cmp.setModel(new DefaultListModel((Vector)Storage.getInstance().readObject("recipes")));
cmp.setRenderer(new DefaultListCellRenderer(false) {
       public Component getCellRendererComponent(Component list, Object model, Object value, int index, boolean isSelected) {
           if(value instanceof Recipe) {
               Recipe r = (Recipe)value;
               super.getCellRendererComponent(list, model, r.getTitle(), index, isSelected);
               setIcon(r.getEncodedImage());
               return this;
           }
           return super.getCellRendererComponent(list, model, value, index, isSelected);
       }
   });

Go to the Recipe class and add the following code to allow image caching:
    private EncodedImage img;

    public EncodedImage getEncodedImage() {
           if(image == null) {
                    img = null;
           } else {
                   if(img == null || img.getImageData() != image) {
               img = EncodedImage.create(image);
                   }
           }
           return img;
    }

In the Resource Editor select the Add Recipe form and select the menu item “Edit->Duplicate”.
Call the new form “Edit Recipe”.

Change the title for the form to “Edit Recipe”. Remove the “Add” command from the form and add a “Save” command instead.

Go back to the “List Resources” form and select the List & the events tab, within it select action event for the list. Go to Netbeans where you should see the code:
protected void onListRecipes_RecipeListAction(Component c, ActionEvent event) {
       // If the resource file changes the names of components this call will break notifying you that you should fix the code
       super.onListRecipes_RecipeListAction(c, event);

}

Add the offset field to the State machine class:
    private int offset;

Then add the following code into the onListRecipes_RecipeListAction method:
       offset = findRecipeList(c.getParent()).getSelectedIndex();
       showContainer("Edit Recipe", null, c);

Go back to the resource editor and select the “Edit List” form, select the “Events” tab and click “Before Show”. Go to Netbeans where you should see this method:
    protected void beforeEditRecipe(Form f) {
       // If the resource file changes the names of components this call will break notifying you that you should fix the code
       super.beforeEditRecipe(f);

    }

Insert the following code into the method:
       Vector recipes = (Vector)Storage.getInstance().readObject("recipes");
       Recipe r = (Recipe)recipes.elementAt(offset);
       findTitle(f).setText(r.getTitle());
       findSteps(f).setText(r.getSteps());
       findType(f).setSelectedIndex(r.getType());
       findImage(f).setIcon(r.getEncodedImage());

Select the properties tab in the resource editor GUI builder and edit the commands of the form, edit the save command. Set the action of the command to list recipes. Click Go To source and press OK to close the dialogs that are open.
Go to Netbeans where you should now have:
    protected boolean onEditRecipeSave() {
       // If the resource file changes the names of components this call will break notifying you that you should fix the code
       boolean val = super.onEditRecipeSave();

       return val;
    }

Insert the following code instead of the method body:
       super.onEditRecipeSave();
       Vector recipes = (Vector)Storage.getInstance().readObject("recipes");
       Recipe entry = (Recipe)recipes.elementAt(offset);
       Form root = Display.getInstance().getCurrent();
       entry.setTitle(findTitle(root).getText());
       entry.setSteps(findSteps(root).getText());
       entry.setType(findType(root).getSelectedIndex());
       EncodedImage e = (EncodedImage)findImage(root).getIcon();
       if(e != null) {
               entry.setImage(e.getImageData());
       } else {
               entry.setImage(null);
       }
       Storage.getInstance().writeObject("recipes", recipes);
       back();
       return true;

Go to the “Edit Recipe” form and add a command, name it “Delete” and press “Go To Source”. Press OK for both dialogs and save the resource file.
Go to Netbeans where you should see the following code:
protected boolean onEditRecipeDelete() {
       // If the resource file changes the names of components this call will break notifying you that you should fix the code
       boolean val = super.onEditRecipeDelete();

       return val;
}

Insert the following lines instead of the method body:
       // If the resource file changes the names of components this call will break notifying you that you should fix the code
       super.onEditRecipeDelete();
       Vector recipes = (Vector)Storage.getInstance().readObject("recipes");
       recipes.removeElementAt(offset);
       Storage.getInstance().writeObject("recipes", recipes);
       back();
       return true;

LWUIT Hands On Lab For Java One

2011-08-31T08:33:00.000-07:00

I got tasked with writing a Hands On Lab (HoL) for JavaOne about LWUIT. For those of you who haven't been to a JavaOne (or Java Developer Day) HoL's are generally a bootcamp like class where you get your feet wet building a quick and dirty demo with a tool to get a feel of the tool.
I already wrote a HoL for LWUIT a while back but it was before the GUI builder was ready and it required internet connectivity to actually work & provide value. The problem with the latter portion is that the internet connectivity might be flaky on people's laptops when everyone tries to reach webservice X in a crowded conference.

So I'm working on a long overdue lab rewrite that will incorporate the latest and greatest resource editor GUI builder and LWUIT 1.5. Generally I would like to create something that is simple yet elegant and I will try to post most of the "how to" in the blog, to actually learn first hand from Chen and myself you would need to actually attend the lab.
If you have any ideas which are simple enough for a first time mobile developer to implement and still show value without an internet connection (we can use some mockups etc. to get the point across) then feel free to post suggestions because I'm somewhat stumped with ideas.

Resource Editor Mac Integration

2011-08-24T08:31:00.000-07:00

I just uploaded a new version of the resource editor application which features much improved Mac OS integration to ease the work of designers who use a Mac with LWUIT.

Fixing Netbeans RIM Integration On Windows 7 And Vista

2011-08-22T01:17:00.000-07:00

For some reason which is entirely unclear to me the guys who implemented Netbeans RIM integration chose to copy the resulting COD files from the dist directory to the RIM program files directory effectively breaking this integration for newer MS OS's which fixed the faulty behavior of a user writeable program files directory.
The problem is that the error you get is misleading, it claims that the directory is read only and when trying to change the read-only status windows "seems" to do some work but fails. The reason for the problem is permissions and fixing this problem is actually quite easy once you understand that.

First go to the Program Files directory (or Program files x86 for 64 bit machines) and select the RIM directory.

Right click and select properties, go to the security tab and click edit.

Select your user name from the list and check the allow for all the boxes, click OK for all the dialogs (this will take a bit of time since the operation is recursive).

Java Spotlight Podcast Interview With Chen Fishbein on LWUIT 1.5

2011-08-11T21:27:00.000-07:00

Roger Brinkly recorded this a while back in India (at the local JavaOne where Chen spoke) when we thought we would be releasing 1.5 soon. Regardless its a great interview and interesting podcast worth the listen especially if you haven't been following 1.5 news.

LWUIT 1.5 Released (finally!)

2011-08-11T01:18:00.000-07:00

After multiple delays we are thrilled to announce the release of LWUIT 1.5 which you can download here. This is probably the biggest, most complete release of LWUIT since version 1.0 hit the scene, it includes both groundbreaking changes and refinements to LWUIT core features.

The major features of this release are:

GUI Builder With major revamp of the Resource Editor tool

LWUIT4IO a tightly integrated Storage, Networking & Filesystem framework with ports to multiple platforms

Far deeper theming including, theme constants, declarative style inheritance, disabled styles etc.

New JavaSE & CDC ports allowing easier debugging/testing/profiling on the desktop as well as easier demos by deploying LWUIT applications as applets

New Components:
- ContainerList allows variable row size list & complex list layouts
- Tabs supersedes the TabbedPane providing swipe gestures, elaborate theming and much more
- Slider provides progress indication and gauge control

New recommended project structure for demos allowing for easier porting to RIM/Desktop/CDC

PeerComponent allowing the embedding of native components within a LWUIT UI (applicable on some platforms)

Improved & simplified animations for layout effects

Multi-Images and improved SVG support

HTML 4 tag support and public parser API for HTML/XML

Virtual Keyboard is now builtin to LWUIT with deep support for native VKB input and toggling between multiple VKB's

Focus rewritten from scratch to be more intuitive

Performance/RAM improvements

Drag & Drop API, copy and paste API and much more

Parsing In LWUIT & LWUIT4IO

2011-08-09T11:46:00.000-07:00

Generally LWUIT as a UI framework focuses on the visual aspect of things and not so much on the unsexy backend logic such as parsing. However, thanks to Ofir we now have an HTMLComponent that included within it a parser for XML which now has its own public API.

Normally we would all try to reuse code from existing projects such as kXML etc. however due to licensing conflicts and the requirement to get permissions from management for every dependency we tend to just solve problems by writing code which is easier than going through the Sun/Oracle bureaucracy.

In LWUIT4IO I needed and subsequently wrote a JSON parser as well which allowed me to easily traverse results for queries to Google, Facebook and other API's. So now LWUIT includes two separate API's allowing you to parse server responses whether in XML or in JSON.

Using both API's is rather simple and both API's include two versions: Parse Tree or Event based.
The parse tree approach returns a data structure containing the parse data, for JSON this is a simple Hashtable with nested data structures. For XML this is an element node that can contain the whole XML hierarchy.

The event based approach allows subclassing the parser and overriding key methods within it to store the data in the way you see fit.

XML can be parsed by creating an instance of XMLParser and invoking the parse() method on that instance, which returns the root Element object for the XML tree. Alternatively the XMLParser class can be subclassed and the eventParser() method invoked, this will be followed by callbacks to the methods: startTag, endTag, attribute & textElement all of which can be overriden to provide custom behavior.

The JSONParser class allows us to parse JSON data either by using the static parse method which provides callbacks to the JSONParseCallback interface thus providing events of the data within the JSON structure. It also contains an instance method named parse() that returns a Hashtable containing the resulting JSON structure, this structure is a set of nested Strings, Hashtables and Vectors to match the JSON JavaScript based hierarchy.

You can take a look at the LWUIT4IO services package source code to see samples of how we use these parsers to implement several builtin services.

Drag And Drop Support In LWUIT

2011-08-01T03:29:00.000-07:00

I recently committed support for a drag and drop API in LWUIT to simplify the task of implementing this functionality. LWUIT always allowed dragging and dropping which was a part of our demo for quite a while now, however we didn't have a convenient generic drag and drop API.

Unlike other platforms who tried to create overly generic catch all API's I tried to make things as simple as possible. We always drag a component and always drop it onto another component, if something else is dragged to some other place it must be wrapped in a component, the logic of actually performing the operation indicated by the drop is the responsibility of the person implementing the drop.

There is a minor sample of this in the LWUITDemo whose drag and drop behavior is now implemented using this API. However, the LWUITDemo relies on builtin drop behavior of container specifically designed for this purpose.

To enable dragging a component it must be flagged as draggable using setDraggable(true), to allow dropping the component onto another component you must first enable the drop target with setDropTarget(true) and override some methods (more on that later).

Notice that is a drop target is a container that has children, dropping a component on the child will automatically find the right drop target. You don't have to make "everything" into a drop target.

You can override these methods in the draggable components:
getDragImage - this generates an image preview of the component that will be dragged. This automatically generates a sensible default so you don't need to override it.
drawDraggedImage - this method will be invoked to draw the dragged image at a given location, it might be useful to override it if you want to display some drag related information such an additional icon based on location etc. (e.g. a move/copy icon).

In the drop target you can override the following methods:
draggingOver - returns true is a drop operation at this point is permitted. Otherwise releasing the component will have no effect.
dragEnter/Exit - useful to track and cleanup state related to draging over a specific component.
drop - the logic for dropping/moving the component must be implemented here!

Notice that Container.java has a simple sample drop implementation you can use to get started.

LWUIT VKB Localization

2011-07-27T09:28:00.000-07:00

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

2011-07-26T00:36:00.000-07:00

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

2011-07-21T04:45:00.000-07:00

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

2011-07-13T04:52:00.000-07:00

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

2011-07-11T00:44:00.000-07:00

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

2011-07-02T23:57:00.000-07:00

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.

FYI: Swimming Servers

2011-06-29T07:19:00.000-07:00

It seems the java.net servers are in the process of taking a swimming lesson at their data center, hopefully they are wearing their floating devices... The center is flooded and java.net itself is down.

Anyway the forum/svn/website/issue tracker etc. are all down for now with no definite ETA, if this continues for too long we will try to setup a contingency plan for an alternate website to host all of the material (source/resource editor etc.). For now you can use stackoverflow.com for support (make sure to tag your questions as lwuit) as well as this blog.

Dropping Support For RIM JDE 4.7

2011-06-20T04:10:00.000-07:00

Don't panic we still support devices all the way back to JDE 4.2, however 4.7 was a special case. RIM created version 4.7 for the initial Storm device and added touch support there in an incompatible way (which is why we have a separate build for that platform). A few years ago RIM issued an update for Storm and moved all of the 4.7 users to 5.0 OS.
So if you are using a blackberry device you either have a non-touch device that might still be using OS 4.6 or older or you might have a touch device which is probably using 5.0 or newer. So 4.7 is redundant except for the fact that up until now it was our recommended JDE platform for touch devices.
This version of the JDE will no longer work with the touch port and you will need the 5.0 JDE going forward, this will allow us to use some of the new API's available in 5.0 when targeting newer devices and still keep support for older none-touch devices.

LWUIT's New Layout Animation Facility

2011-06-15T06:15:00.000-07:00

I'd like to create some more demo animations and some additional animation utilities like this one and I probably will as soon as I get some time.

While the animations in this video might seem elaborate, they are really simple to achieve and work great even on feature phones. All that is really needed is one LWUIT method: Container.animateLayout(int)

To understand this I'll just explain a couple of things about LWUIT components, when we add a component to a container its generally just added but not positioned anywhere. A novice might notice the setX/Y/Width/Height methods on a component and just try to position it absolutely.
This won't work since these methods are meant for the layout manager which it implicitly invoked when a form is shown (internally in LWUIT) and the layout manager uses these methods to position the components as it sees fit.
However, if you add components to LWUIT on your own it is your responsibility to invoke revalidate (or layoutContainer) to arrange the newly added components. LWUIT doesn't "reflow" implicitly since that would be hugely expensive, imagine doing the layout calculations for every component added to the container the cost would be closer to a factorial of the original cost of adding a component.

The animateLayout() is simply a fancy form of revalidate. After changing the layout when you invoke this method it will animation the components to their new sizes and positions seamlessly.

The first example in the tipster demo shows an "interlace" effect where the components each slide from a separate direction into the screen. This is the code I used before showing the form:

f.revalidate();
for(int iter = 0 ; iter < c.getComponentCount() ; iter++) {
Component current = c.getComponentAt(iter);
if(iter % 2 == 0) {
current.setX(-current.getWidth());
} else {
current.setX(current.getWidth());
}
}
c.setShouldCalcPreferredSize(true);
c.animateLayout(1000);

Lets go over this line by line:

f.revalidate();

I make sure the layout is valid so I can start from the correct component positions.

if(iter % 2 == 0) {

current.setX(-current.getWidth());

} else {

current.setX(current.getWidth());

}

I manually position every component outside of the screen, if they are odd I place them to the right and if they are even I place them to the left.

c.setShouldCalcPreferredSize(true);

I mark the UI as needing layout. This is crucial since I validated the UI earlier (by calling revalidate). Changing the X/Y/Width/Height doesn't trigger a validation! LWUIT doesn't know I made that change!

By calling setShouldCalcPreferredSize I'm explicitly telling LWUIT that I changed something in the UI and I want it to validate, normally this method is implicitly invoked by LWUIT.

c.animateLayout(1000);

Perform the animation over the length of a second, this might seem like much but the animation starts before the form entry transition so it isn't that much.

The other animations are even simpler than this one and all follow the same basic rules, place the components wherever you want either manually (or by changing the layout) and use animateLayout() to automatically rearrange them to the new position.

BTW we fully intended to have a new LWUIT release by now but its getting delayed due to the typical bureaucratic nonsense that is an unavoidable reality within a large corporation. We apologize it is taking so long and even more so that we do not have an ETA. Those of you following the SVN know we already have everything ready for 1.5.

Interesting Couple Of Weeks

2011-06-09T02:28:00.000-07:00

This post isn't about LWUIT, its about Java on the desktop and its current direction. Microsoft just introduced Windows 8, for those of you who haven't been following here is the gist:
Run's on Arm (as well as Intel obviously), Completely new touch/gesture based UI, less emphasis on Windows.

Apple also introduced Tiger (next Mac OS X), which also focuses more on full screen applications as well as eliminates the scrollbar... Mac OS X will now scroll like the iPhone and hide the scrollbar when it isn't used.
Rumors are also abundant about Apple's laptop line moving to Arm chips which they can easily do since they have a fat binary .app directory structure (which MS doesn't have).

To me these things signal a massive UI convergence trend where the mobile UI takes the lead. Up until now mobile UI's were influenced by desktop paradigms and now we finally see the reverse coming on in full force.

Where does this leave Java developers?

Swing hasn't been moving forward for quite a while now & Java FX isn't even in production and already it seems behind the curve on these sort of features. I'd love to say that LWUIT can take over but right now we still don't have many of the features necessary to write full scale desktop apps...
However, I would say that this is a great time to be a mobile developer since an upheaval is on its way and it seems that we are leading the pack.

This sort of convergence also means a huge migration to the cloud, when using multiple mobile devices its just impossible to sync them in any other way. Even those reluctant about privacy and security would probably shift to the cloud to remain competitive.

LWUIT Timeline Tutorial Video Part One

2011-06-06T09:01:00.000-07:00

This one required tremendous amounts of work to make and I still didn't finish. Since its quite a long video I have some doubts on whether people will have the energy to watch it all the way through and follow up to part two.
This actually goes most of the way in creating the theme for the t-zone demo (which is now in the LWUIT SVN), if I do the second part it will continue from where I left off all the way to creating the actual code backing this.

BTW I uploaded a new binary of the resource editor today, this new version includes theme templates based both on this theme and on the Tipster demo theme. Check them out and please improve your UI designs accordingly ;-)

Martin Is On Fire: New LWUIT Tipster Demo

2011-06-01T05:44:00.000-07:00

Martin (our designer) has finally come through with two professionally designed demos in a row, showing off the difference a proper designer makes when building such applications. He cranked the designs for these ridiculously fast and once I had the designs in place it reduced allot of the doubt of designing. Overall I got the design yesterday morning and now the video is on youtube... I will commit the code to SVN in a few hours (hopefully).
I already committed the code for Martin's previous t-zone demo which I've been showing around a bit and getting allot of surprised reactions from people. It just goes to show you how far the effect of a good UI designer can take your UI regardless of the technology you are using.

We are trying to get a release up to speed so I don't have the time to do the tutorials but I would like to get detailed step by step "how to" tutorials explaining exactly how I implemented both applications.

Preview Of The New LWUIT Friends t-Zone Demo

2011-05-29T14:45:00.000-07:00

This demo is coming soon, full source code and everything. It doesn't really have much source code since the whole thing was created in the GUI builder with very little code. I hope to also create a tutorial showing off exactly how this demo was made.
BTW If you have a stack overflow account please go to this question and vote up my answer, its amazing how the worst possible LWUIT screenshots could be picked off this blog... Frankly its also a bit of my fault since finding proper screenshots of newer applications (not videos) is a bit hard. I should get on to that.

Clicking Within A Cell Renderer

2011-05-25T06:11:00.000-07:00

One of the things people looked for quite often in Lists was the ability to click on a specific element within a ListCellRenderer to get an event specific to that element. E.g. a list with X's drawn on the side to remove the element.
In the past we contended that since the list is stateless its impossible for us to provide such information and recommended people use a Container with items. We now have a solution which works only for touch devices, this feature allows adding a listener to a component within the renderer which will now trigger an event if the component is touched.
Notice that the component will not contain the right data since the list selection indicates the actual selection, however if you add a listener to a button containing the X you should get an action event on that button before the list action event. This will allow you to toggle a flag indicating that the X was pressed and not a different portion of the renderer.
This isn't ideal but since the list is stateless this is the best we could come up with.

Assuming you used the GUI builder & GenericListCellRenderer you can use the method GenericListCellRenderer.extractLastClickedComponent() in the action listener for the list to get the button that was pressed to generate this event or null if no button was pressed.

I apologize for the lack of videos recently, we are working very hard towards a LWUIT release in June (hopefully, bureaucracy is always our foe) so I don't have quite the same amount of cycles to dedicate for proper blogging. I'll try to get something decent going soon.

Logging & Caching In LWUIT4IO

2011-05-18T04:48:00.000-07:00

We've been quite busy with holidays and Chen going off to JavaOne in India so I didn't have as much time to blog as I normally do or prepare the videos I should be working on. Hopefully I'll recover some time soon and be able to get back to my normal pace.
In recent LWUIT SVN's I deprecated and effectively removed the venerable log class. The main motivation behind that is the fact that logging didn't go through the platform code and never made sense in LWUIT. It was hardcoded for MIDP and had many issues.

That class is replaced by an almost identical class within LWUIT4IO which has similar functionality with a few cool new features. First, it can run on all platforms including Java SE, RIM, MIDP and even Thorsten's new Android port of LWUIT4IO.
Then it has one more "killer feature", it can track file IO seamlessly!

Unlike J2SE, most mobile platforms are really sensitive regarding forgotten streams and its essential to close every stream you open. The problem is that its often really hard to keep track in a large application that deals with many dynamic files constantly. However, since all LWUIT4IO streams are buffered it can easily tell when a stream is opened/closed or double closed. This gets logged automatically if you invoke Log.getInstance().trackFileSystem() which will cause entries to appear in your log containing the URL opened/closed and the number of open streams. This feature helped me in tracking some pretty hairy bugs.

Another feature in LWUIT4IO to which I didn't give enough spotlight is the cache map, its effectively a lean hashtable which stores its data using weak/soft references (depending on the platform) and falls back to storage when not enough memory is available. Its a great way to cache data without going overboard.
One of the cool things about it is the fact that we use it seamlessly for our storage abstraction (which hides RMS or equivalent services) in effect providing faster access to RMS storage which is often slow on devices.

While writing on that subject it dawned on me that I never blogged about our "seamless" serialization support in LWUIT4IO. The Storage class and util class contain methods for reading/writing of objects. All the basic JavaME data types should be supported including: primitive arrays, Strings, Object arrays, Hashtable's and vectors. Arbitrary objects can be stored by implementing com.sun.lwuit.io.Externalizable. This allows easy/efficient persistence and networking between applications.
Give these features a try and let us know how they work for you.

As a side note: due to recent issues with the forum/mailing list that unfortunately remain unresolved to this moment I decided to start answering issues in stack overflow which has a great LWUIT section.

Terrences Cool Meet Me For Dinner Demo

2011-05-07T21:25:00.000-07:00

Terrence has just released the sources for his cool "Meet Me For Dinner" JavaOne demo. The demo shows off some pretty cool effects and social web/location interaction.
Check out his post for more information.

Play It Again LWUIT

2011-05-04T04:19:00.000-07:00

The next version of LWUIT will completely replace the way to interact with media and supersede it with our own API's. When we initially introduced LWUIT's MediaComponent, MIDP was the major target for LWUIT and blackberry support was on top of MIDP.
Since then we had Thorsten porting LWUIT to RIM/Android and introduced ports to TV, Java SE etc. MMAPI isn't available on all of those platforms.

This called for a rethinking of our approach to media and so we introduced VideoComponent which uses the peer component architecture to embed a video into LWUIT. Unlike the older MediaComponent code there is no need for MMAPI know how or any information on the underlying playback. Just use a URL or stream+mime type to playback any video file.

Audio is integrated even deeper right into the Display class with methods to create an audio stream and play it. The main feature here is automatic resource cleanup which is a frequent problem with audio files (neglecting to close an audio resource properly is a big portability issue). LWUIT automatically closes resources as necessary in a way that is completely seamless for the developer, again with no need to know anything about MMAPI or the platform native implementation.

Generating A Netbeans Project From The Resource Editor

2011-04-26T06:50:00.000-07:00

I already had a similar tutorial in the past but this one is more refined and concise (thanks to http://www.screencast-o-matic.com/). This is a simple developer oriented tutorial showing how simple it is to create a hello world application directly to Netbeans and reviewing the output you get as a result.

Mini Tutorial On Editing a Theme Attribute

2011-04-20T07:26:00.000-07:00

Theme attributes and UIID's are some of the more challenging aspects of creating a theme. In this tutorial we try to break down the elements that can be customized for every component within the theme dialog.

Oracle Magazine Cover Article About JavaME

2011-04-19T21:31:00.000-07:00

Talks quite a bit about LWUIT including interview with Telmap, read it here. Via Terrence.

Contain That List - Bringing Containers & List's Together

2011-04-13T06:59:00.000-07:00

LWUIT's List's are a unique component in their adherence to the Swing concepts of MVC (model, view/controler, renderer). The difference between lists and container/component hierarchy can be summed up quite easily: "Lists are about showing data, containers are about showing widgets".
Widgets can be anything, tend to be interactive and have elaborate hierarchies.
Data can be presented in many ways and might come in very large volumes.

This is easy to illustrate with the features of list, e.g. a list can be horizontal or fixed in various ways (as you would do to data) but its very hard to implement something like that with the container/component model.

Naturally each approach has its use cases and advantages and sometimes its really hard to shoehorn one approach to the other but we are sometimes forced to do so due to design aesthetic e.g. variable sized list.
Allot of people had an issue with implementing our recommended approach since they wanted to share code that used the list model/renderer approach with code that used layout managers. While this was technically possible its not trivial and is a common enough use case to fold it into LWUIT which is exactly what we did.

ContainerList is effectively a container that tries to abide by the contract of the list component, it creates thin internal components that render themselves using the cell renderer. To achieve this we had to replace the ListCellRenderer (which is now deprecated but still working) with the new CellRenderer interface. The original ListCellRenderer methods accept a List component which doesn't make sense for the new component, the CellRenderer interface resolves these issues.

Generally the class is a plugin replacement for a list with the addition of quite a few features from container through the ability to set the layout to anything we want, e.g. to accomplish variable size lists just use BoxLayout on Y_AXIS. To accomplish a grid just use grid layout as we do in the LWUIT demo that I just committed (see the video above).

The newest version of the resource editor now includes support for this component in the GUI builder as well as some other nifty features such as marking the components that have code associated with them.

Resource Editor Tutorial Rebooted: Introduction And Walkthrough

2011-04-06T12:58:00.000-07:00

Yes a "do over" so soon for the resource editor tutorial. You must admit this one is way better than the last one.
While the first part is very verbose I'll try to keep the following to a more concise "How To" format which I think will be more helpful when integrated with the tool itself.

The Many Images Of LWUIT

2011-04-04T22:40:00.000-07:00

When we initially came out with LWUIT we inherited some baggage from J2ME in the form of several image types: loaded, RGB (builtin), RGB (lwuit) and Mutable. We quickly added Indexed and StaticAnimation. We later on added then replaced SVG support (then replaced it again) but the image landscape remained relatively static until this past year.
In LWUIT 1.4 we finally introduced EncodedImage which to us was a complete epiphany in how images "should" work in mobile devices. We now also have an even newer approach to SVG, Multi-Image & Timeline. And I won't even go into LWUIT4IO which has the FileEncodedImage and FileEncodedImageAsync options...

I will now try to explain the pros/cons and logic behind every image type and how its created:

Loaded Image - this is the basic image you get when loading an image from the jar or network using Image.createImage(String)/Image.createImage(InputStream)/Image.createImage(byte[], int, int).
In MIDP calling getGraphics() on an image like this will throw an exception (its immutable in MIDP terms), this is true for almost all other images as well. This is strictly a MIDP restriction and might not apply for all platforms.
The image is encoded based on device logic and should be reasonably efficient.
RGB Image (internal) - close cousin of the loaded image. This image is created using the method Image.createImage(int[], int, int) and receives ARGB data forming the image. It is usually (although not always) a high color image. Its more efficient than the LWUIT RGB image but can't be modified, at least not on the pixel level.
RGBImage (LWUIT) - constructed via the RGBImage class constructors this image is effectively an ARGB array that can be drawn by LWUIT. On many platforms this is quite inefficient but for some pixel level manipulations there is just no other way.
IndexedImage/StaticAnimation - Both are deprecated and replaced by the more efficient and effective EncodedImage/Timeline. IndexedImage's allow storing images using a palette array and a byte per pixel (indexed images must not contain more than 256 colors). Static animations add to that by animating frames using a line difference algorithm.
EncodedImage - created via the encoded image static methods, the encoded image is effectively a loaded image that is "hidden". When creating an encoded image only the PNG (or jpeg etc.) is loaded to an array in RAM. Normally such images are very small relatively so they can be kept in memory without much effect. When image information is needed (e.g. pixels, dimension etc.) the image is decoded into RAM and kept in a weak/sort reference.
This allows the image to be cached for performance and allows the garbage collector to reclaim it when the memory becomes scarce.
Encoded image is not final and can be derived to produce complex image fetching strategies such as lazily loading an image from the filesystem.
SVG - SVG's can be loaded directly via Image.createSVG() if Image.isSVGSupported() returns true. When adding SVG's via the resource editor fallback images are produced for devices that do not support SVG.
Multi-Image - This is seamless to developers who receive a multi-image as an EncodedImage. In the resource editor one can add several images based on the DPI of the device (one of several predefined family ranges). When loading the resource file irrelevant images are skipped thus saving the additional memory.
Multi-images are ideal for icons or small artifacts that are hard to scale properly. They are not meant to replace things such as 9-image borders etc. since adapting them to every resolution or to device rotation isn't practical.
Timeline - Timeline's allow rudimentary animation and enable GIF importing using the resource editor. Effectively a timeline is a set of images that can be moved rotated, scaled & blended to provide interesting animation effects. It can be created manually using the Timeline class.

All image types are mostly seamless to use and will just work with drawImage and various image related image API's for the most part with caveats on performance etc. For animation images the code must invoke images animate() method (this is done automatically by LWUIT when placing the image as a background or as an icon! You only need to do it for drawImage code).
All images might also be animated in theory e.g. my gif implementation returned animated gifs from the standard Loaded Image methods and this worked pretty seamlessly (since Icons's and backgrounds just work). To find out if an image is animated you need to use the isAnimation() method, currently SVG images are animated in MIDP but most of our ports don't support GIF animations by default (although it should be easy to add to some of them).

Performance and memory wise you should read the above carefully and be aware of the image types you use. The resource editor tries to conserve memory and be "clever" by using only encoded images, while these are great for low memory they are not as efficient as loaded images in terms of speed. Also when scaled these images have much larger overhead since they need to be converted to RGB, scaled and then a new image is created. Keeping all these things in mind when optimizing a specific UI is very important.

A New Way To LWUIT Explained Visually

2011-04-03T12:03:00.000-07:00

My latest post covering the development in LWUIT using the new project structure might not have been clear enough so I decided to pull up screencast-o-matic.com to make a quick video of how this looks on my PC (and really got a kick off of their zooming and annotation capabilities in the process).
I hope this makes it clear how cool it is to have a proper SE port and this new project structure to work with.

A New Way To LWUIT

2011-03-29T22:15:00.000-07:00

LWUIT had a MIDP bias. It started as a MIDP project so it is perfectly understandable, however moving forward to support RIM and other platforms (e.g. Thorsten's great work) we wanted to completely disconnect LWUIT from its platform specific roots and offer some great new features in the process.
It started off when we generated projects for the GUI builder, but we decided to take this further into the LWUIT Demo and make that approach into our project structure recommendation. You can checkout the source code for the new LWUIT Demo from SVN to see the actual structure.

Basically what we are doing is placing all the LWUIT portable code into a MIDP shared library, this is effectively the common code for the project. Here we also place the common resources used within all the different ports.
Underneath this project (mostly for convenience not due to necessity) we place subprojects that depend on that parent project and are platform specific. That way we don't need a pre-processor or any similar tool to gain both portability and the ability to utilize platform specific features when we want to do so.

The really cool feature hidden beneath this is the ability to utilize the JavaSE port to run the application. Besides running practically instantly (no simulator!), the biggest hit is the ability to use Java SE level development tools!
Edit & continue, profilers, threadalizers, memory monitors etc. Its a whole different scale of debugging for business logic (assuming the issue reproduces on the SE port). Besides debugging this feature allows you to embed your application as an Applet right into a web page to provide users with a live preview of your application! How cool is that!

To your right you can (hopefully) see a running Applet containing the current version of the LWUIT demo. You can use escape as a back button, F1 as the menu button and the arrow keys/mouse to navigate within this Applet.

FYI About the videos I've been uploading

2011-03-22T23:07:00.000-07:00

I'm currently in the midst of making major usability UI improvements to the resource editor which already changed quite allot since I started making the screencasting videos of it. I also discovered http://www.screencast-o-matic.com/ which seems to be exactly what I needed and is written in Java!

As a result of all of these I decided to complete the changes for the upcoming resource editor version and "reboot" the video tutorial with better planning for my goals. I'll keep the existing videos online for reference but will start making a far improved tutorial in a short while. One of the biggest blockers for me is actually finding some quite time to record, not a moment of quiet for the wary...

List Rendering: The Easy Way. Generic List Cell Renderer

2011-03-21T02:45:00.000-07:00

LWUIT is really powerful and flexible, we took the power and flexibility of Swing and went even further (styles, painters) and one such power is the cell renderer. This is a concept we derived from Swing which is both remarkably powerful and pretty hard for newbies to figure out, frankly its pretty hard for everyone...
As part of the GUI builder work we needed a way to customize rendering for a List but the renderer/model approach seemed impossible to adapt to a GUI builder (it seems the Swing GUI builders had a similar issue). Our solution was to introduce the GenericListCellRenderer which while introducing limitations and implementation requirements still manages to make life easier both in the GUI builder and outside of it.

A small refresher of the LWUIT List MVC approach for those who haven't read the links above:
A LWUIT list doesn't contain components but rather arbitrary data, this seems odd at first but makes perfect sense... If you want a list to contain components just use a Container.
The advantage of using a List in this way is that we can display it in many ways (e.g. fixed focus positions, horizontally etc.) and that we can have more than a million entries without performance overhead. We can also do some pretty nifty things like filter the list on the fly or fetch it dynamically from the internet as the user scrolls down the list.
To achieve these things the list uses two interfaces: ListModel and ListCellRenderer.
List model represents the data, its responsibility is to return the arbitrary object within the list at a given offset. Its second responsibility is to notify the list when the data changes so the list can refresh, think of it as an array of objects that can notify you when you get changes.
The list renderer is like a rubber stamp that knows how to draw an object from the model, its called many times per entry in an animated list and must be very fast. Unlike standard LWUIT components it is only used to draw the entry in the model and immediately discarded hence it has no memory overhead but if it takes too long to process a model value it can be a big bottleneck!
This is all very generic but a bit too much for most, doing a list "properly" requires some understanding. The main source of confusion for developers is the stateless nature of the list and transferal of state to the model (e.g. a checkbox list needs to listen to action events on the list and update the model in order for the renderer to display that state... Once you understand that its easy).

GenericListCellRenderer is a renderer designed to be as simple to use as a Component-Container hierarchy, we effectively crammed most of the common renderer use cases into one class. To enable that we need to know the content of the objects within the model, so the GenericListCellRenderer assumes the model contains only Hashtable objects. Since Hashtable's can contain arbitrary data the list model is still quite generic and allows storing application specific data, furthermore a Hashtable can still be derived and extended to provide domain specific business logic.
The GenericListCellRenderer accepts two container instances (more later on why at least two and not one) which it maps to individual Hashtable entries within the model by finding the appropriate components within the given container hierarchy. Components are mapped to the Hashtable entries based on the name property of the component (get/setName) and the key value within the Hashtable e.g.:
For a model that contains a Hashtable entry like this:
"Foo": "Bar"
"X": "Y"
"Not": "Applicable"
"Number": Integer(1)

A renderer will loop over the component hierarchy in the container searching for component's whose name matches Foo, X, Not and Number and assign to them the appropriate value. Notice that you can also use image objects as values and they will be assigned to labels as expected. However, you can't assign both an image and a text to a single label since the key will be taken. That isn't a big problem since two labels can be used quite easily in such a renderer.
To make matters even more attractive the renderer seamlessly supports list tickering when appropriate and if a CheckBox appears within the renderer it will toggle a boolean flag within the Hashtable seamlessly.
One issue that crops up with this approach is that if a value is missing from the hashtable it is treated as empty and the component is reset, this can pose an issue if we hardcode an image or text within the renderer and we don't want them replace (e.g. an arrow graphic). The solution for this is to name the component with Fixed in the end of the name e.g.: HardcodedIconFixed.
Naming a component within the renderer with $number will automatically set it as a counter component for the offset of the component within the list.

Styling the GenericListCellRenderer is slightly different, the renderer uses the UIID of the container passed to the generic list cell renderer and the background focus uses that same UIID with the word "Focus" appended.
It is important to notice that the generic list cell renderer will grant focus to the child components of the selected entry if they are focusable thus changing the style of said entries. E.g. a Container might have a child label that has one style when the parent container is unselected and another when its selected (focused), this can be easily achieved by defining the label as focusable. Notice that the component will never receive direct focus since it is still a par of a renderer.

Last but not least, the generic list cell renderer accepts two or four instances of a Container rather than the obvious choice of accepting only one instance. This allows the renderer to treat the selected entry differently which is especially important to tickering although its also useful for fisheye. Since it might not be practical to seamlessly clone the Container for the renderer's needs LWUIT expects the developer to provide two separate instances, they can be identical in all respects but they must be separate instances for tickering to work. The renderer also allows for a fisheye effect where the selected entry is actually different from the unselected entry in its structure, it also allows for a pinstripe effect where odd/even rows have different styles (this is accomplished by providing 4 instances of the containers selected/unselected for odd/even).

The best way to learn about the generic list cell renderer and the hashtable model is by playing with them in the GUI builder, however they can be used in code without any dependency on the GUI builder and can be quite useful at that.

Here is a simple sample for a list with checkboxes that get updated automatically:

List list = new List(createGenericListCellRendererModelData());
list.setRenderer(new GenericListCellRenderer(createGenericRendererContainer(), createGenericRendererContainer()));


private Container createGenericRendererContainer() {
    Container c = new Container(new BorderLayout());
    c.setUIID("ListRenderer");
    Label name = new Label();
    name.setFocusable(true);
    name.setName("Name");
    c.addComponent(BorderLayout.CENTER, name);
    Label surname = new Label();
    surname.setFocusable(true);
    surname.setName("Surname");
    c.addComponent(BorderLayout.SOUTH, surname);
    CheckBox selected = new CheckBox();
    selected.setName("Selected");
    selected.setFocusable(true);
    c.addComponent(BorderLayout.WEST, selected);
    return c;
}

private Hashtable[] createGenericListCellRendererModelData() {
    Hashtable[] data = new Hashtable[5];
    data[0] = new Hashtable();
    data[0].put("Name", "Shai");
    data[0].put("Surname", "Almog");
    data[0].put("Selected", Boolean.TRUE);
    data[1] = new Hashtable();
    data[1].put("Name", "Chen");
    data[1].put("Surname", "Fishbein");
    data[1].put("Selected", Boolean.TRUE);
    data[2] = new Hashtable();
    data[2].put("Name", "Ofir");
    data[2].put("Surname", "Leitner");
    data[3] = new Hashtable();
    data[3].put("Name", "Yaniv");
    data[3].put("Surname", "Vakarat");
    data[4] = new Hashtable();
    data[4].put("Name", "Meirav");
    data[4].put("Surname", "Nachmanovitch");
    return data;
}

Constantly Theme'd

2011-03-17T14:37:00.000-07:00

One of the often requested features in LWUIT's themes has been the addition of constants for themes. Constants allow the theme designer to "hint" of desired functionality to the application code, e.g. a particular theme might have a constant indicating that it wants the scrollbar to fadeout when unused.
The LWUIT resource editor now includes an additional tab for creating such constants which can be used to add constant values. These can be added in the ant task by prepending the @ sign before the constant key in the theme and setting the value to the appropriate string.
Constants are always strings, they have some conventions where a constant ending with Bool is treated as a boolean true/false value and a constant ending with Int or Image (for image the string name of the image is stored but the image instance will be returned).

To use a constant one can use the UIManager's methods to get the appropriate constant type specifically:
getThemeConstant
isThemeConstant
getThemeImageConstant

Internally LWUIT has several builtin constants and the list is constantly growing as we add features to LWUIT, we will try to keep this list up to date when possible.


.	LWUIT Constant	Description
.	centeredPopupBool	Popup of the combo box will appear in the center of the screen
.	checkBoxCheckDisImage	CheckBox image to use instead of LWUIT drawing it on its own
.	checkBoxCheckedImage	CheckBox image to use instead of LWUIT drawing it on its own
.	checkBoxUncheckDisImage	CheckBox image to use instead of LWUIT drawing it on its own
.	checkBoxUncheckedImage	CheckBox image to use instead of LWUIT drawing it on its own
.	comboImage	Combo image to use instead of LWUIT drawing it on its own
.	commandBehavior	Indicates how commands should act, as a touch menu, native menu etc. Possible values: SoftKey, Touch, Bar, Title, Right, Native
.	defaultCommandImage	Image to give a command with no icon
.	dialogButtonCommandsBool	Place commands in the dialogs as buttons
.	dialogPosition	Place the dialog in an arbitrary border layout position (e.g. North, South, Center etc.)
.	dialogTransitionIn	Default transition for dialog
.	dialogTransitionInImage	Default transition Image for dialog, causes a Timeline transition effect
.	dialogTransitionOut	Default transition for dialog
.	dialogTransitionOutImage	Default transition Image for dialog, causes a Timeline transition effect
.	disabledColor	Color to use when disabling entries by default
.	dlgCommandButtonSizeInt	Minimum size to give to command buttons in the dialog
.	dlgSlideDirection	Slide hints
.	dlgSlideInDirBool	Slide hints
.	dlgSlideOutDirBool	Slide hints


.	fadeScrollBarBool	Fade transition hints
.	fadeScrollEdgeBool	Fade transition hints
.	fadeScrollEdgeInt	Fade transition hints
.	firstCharRTLBool	Indicates the GenericListCellRenderer should determine RTL status based on the first character in the sentence
.	fixedSelectionInt	Number corresponding to the fixed selection constants in List
.	formTransitionIn	Default transition for form
.	formTransitionInImage	Default transition Image for form, causes a Timeline transition effect
.	formTransitionOut	Default transition for form
.	formTransitionOutImage	Default transition Image for form, causes a Timeline transition effect
.	hideEmptyTitleBool	Indicates that a title with no content should be hidden even if the border for the title occupies space
.	ignorListFocusBool	Hide the focus component of the list when the list doesn't have focus
.	listItemGapInt	Builtin item gap in the list, this defaults to 2 which predated padding/margin in LWUIT
.	menuHeightPercent	Allows positioning and sizing the menu
.	menuPrefSizeBool	Allows positioning and sizing the menu
.	menuSlideDirection	Defines menu entrance effect
.	menuSlideInDirBool	Defines menu entrance effect
.	menuSlideOutDirBool	Defines menu entrance effect
.	menuTransitionIn	Defines menu entrance effect
.	menuTransitionInImage	Defines menu entrance effect
.	menuTransitionOut	Defines menu entrance effect


.	menuTransitionOutImage	Defines menu entrance effect
.	menuWidthPercent	Allows positioning and sizing the menu
.	otherPopupRendererBool	Indicates that a separate renderer UIID/instance should be used to the list within the combo box popup
.	popupCancelBodyBool	Indicates that a cancel button should appear within the combo box popup
.	popupTitleBool	Indicates that a title should appear within the combo box popup
.	pureTouchBool	Indicates the pure touch mode
.	radioSelectedDisImage	Radio button image
.	radioSelectedImage	Radio button image
.	radioUnselectedDisImage	Radio button image
.	radioUnselectedImage	Radio button image
.	rendererShowsNumbersBool	Indicates whether renderers should render the entry number
.	reverseSoftButtonsBool	Swaps the softbutton positions
.	slideDirection	Default slide transition settings
.	slideInDirBool	Default slide transition settings
.	slideOutDirBool	Default slide transition settings
.	snapGridBool	Snap to grid toggle
.	tabsFillRowsBool	Indicates if the tabs should fill the row using flow layout
.	tabsGridBool	Indicates whether tabs should use a grid layout thus forcing all tabs to have identical sizes
.	tickerSpeedInt	The speed of label/button etc. tickering in ms.
.	tintColor	The aarrggbb hex color to tint the screen when a dialog is shown


.	touchCommandFillBool	Indicates how the touch menu should layout the commands within
.	touchCommandFlowBool	Indicates how the touch menu should layout the commands within
.	touchMenuBool	Force the touch menu
.	transitionSpeedInt	Indicates the default speed for transitions

One "odd" behavior of constants is that once they are set by a theme they don't get "lost" when replacing the theme. E.g. if one would set the comboImage constant to a specific value in theme A and then switch to theme B that doesn't define the comboImage, the original theme A comboImage might remain. The reason for this is simple, when extracting the constant values components keep the values in cache locally and just don't track the change in value. Furthermore, since the components allow manually setting values its impractical for them to track whether a value was set by a constant or explicitly by the user.
The solution for this is to either manually reset undesired values before replacing a theme (e.g. for the case above by calling the default look and feel method for setting the combo image with a null value) or defining a constant value to replace the existing value.

BTW I haven't been blogging or posting videos as often as I should both because I have been a bit under the weather and because I have been quite swamped with work (checkout the SVN changes). Hopefully I'll feel a bit better next week and increase my blogging a bit.

New Project Hierarchy For LWUIT

2011-03-07T12:42:00.000-08:00

I haven't posted in a short while because we have some big things coming for LWUIT, I just committed a major restructuring of the LWUIT workspace which essentially moved everything around to more sensible locations. We made a tag just before the move so if you have hard dependencies on the old LWUIT workspace structure you can use that tag.
The new structure makes more sense for LWUIT ports since it removes all the none cross platform (MIDP specific code) from LWUIT and moves it entirely to the ports directory. This allows LWUIT to treat all ports to all platforms on even grounds and simplify the build process for such ports. In the past allot of things such as applications and LWUIT4IO were located under MIDP which made no sense at all (other than historic sense), so now we have two portable projects: UI & IO. Which are actually useless on their own.
You need to pick the specific project for your platform to link against from the ports folder where we have both an IO and a UI project for every supported platform.

Put A Face On It

2011-02-21T06:40:00.000-08:00

majimob, long known for its music related apps as well as some other LWUIT based endeavors has just released a facebook application written entirely in LWUIT and using LWUIT4IO. The application was written in the new LWUIT GUI builder in record time and features direct access to the facebook API.
The application supports both touch and feature phone interaction, it was designed to work on all mobile phones including blackberries and Android devices (although since Android has a pretty good facebook app there are no current plans for such a version).

Musix Under The Skin

2011-02-14T07:26:00.000-08:00

In this video I review the GUI of the musix application in the resource editor shedding some light on how it was implemented using the LWUIT GUI builder.

A Touch Of Musix

2011-02-09T05:47:00.000-08:00

This is a preliminary video of the new touch optimized Musix DRM'd media player application from Triplay/majimob deploying on the network of the Israeli operator Pelephone. This is the first commercially available LWUIT application that I know of that was developed entirely in the GUI builder and in fact help us shape allot of the requirements for the GUI builder.
As a beta tester of the GUI builder implementation we worked very closely with the application development and I have full access to the source/UI code. I will try to post a quick walk-through of how the GUI builder was used to create such an application (its even bigger than the video makes it out to be).

LWUIT Resource Editor Developers Tutorial Part 2 (PSD Tutorial Part 4)

2011-02-06T01:35:00.000-08:00

In this part of the LWUIT developer tutorial we go into details of mapping the demo created in the PSD tutorial to actual code that calls LWUIT4IO. We show mapping regular LWUIT components to server REST operations as well as mapping a LWUIT List model to server results.
I committed the code and res file to the lwuit incubator project (notice it has a new SVN URL! https://svn.java.net/svn/lwuit-incubator~svn/trunk). There was a minor bug in my code near the end triggering an exception it was due to the for loop adding to the vector before setting the offset for the request. This is fixed in the incubator project.

LWUIT Resource Editor PSD Tutorial Part 3: Image Search Application

2011-02-02T07:36:00.000-08:00

In this part of the resource editor PSD tutorial we take the design and turn it into a simple image search application. I stopped at this cutoff point since the bounds are limitless, I could go on with extracting the dialog UI and various other widgets but hopefully the picture of what can be done with photoshop and some resource editor hacking should be clear from these tutorials.
Next time I will go into details on how to bind this to actual code in the second part of the developer tutorial.

New Resource Editor (change your URL's) & Kenai updates

2011-01-31T06:12:00.000-08:00

We are trying to get up to speed with Kenai, allot of the functionality is lost or very different so we currently don't have many of the things we used to have like the customized home page or the featured apps page. But at least we now have the new version of the resource editor launchable again.
Since the SVN changed (make sure to update to the new LWUIT SVN!!!!), the URL's for the resource editor webstart application have also changed and we can no longer deliver updates on the old URL. Please use the following button to launch the new resource editor:

If you are experiencing troubles with the above link (e.g. if you disabled Java in your browser) you can use the jnlp directly.

New LWUIT website in project Kenai now live

2011-01-28T07:48:00.000-08:00

The Java.net migration is nearly complete and LWUIT now has a new home page at http://lwuit.java.net/. In the future the current http://lwuit.dev.java.net/ address will redirect to the new location but right now it still leads to the old outdated site!

Upcoming commits and information will all be in the new site, thanks for your patience.

Location Based Cross Platform Game In LWUIT

2011-01-26T02:23:00.000-08:00

I have been negligent in posting about cool new LWUIT app's mostly because I have so much to do, however Chen insisted I post about Tourality and I agree it is different. Its a location based game written for all platforms with LWUIT, it runs on Android, Blackberry & J2ME. The upcoming iPhone version probably won't be based on LWUIT though ;-)
In the words of its author: "Tourality is a location based scavenger hunt game. Reach geographic spots in different challenges in your vicinities. Collect gold to outsmart your co-players with gadgets but beware of thieves. Play alone or with others in multiplayer games with up to 40 players. Choose from various game sets in your city. Discover the action-packed outdoor GPS game and register for free at www.tourality.com. Supported smartphone platforms include Android, BlackBerry, Nokia, iPhone (in development)."

LWUIT Resource Editor PSD Tutorial Part 2: Converting To LWUIT

2011-01-24T05:49:00.000-08:00

The second part of the tutorial covers the creation of the first UI skeleton before building the actual application. There are still some missing refinements in this version e.g. I forgot to make the title area transparent which would allow the background texture to peek through.

LWUIT Resource Editor PSD Tutorial Part 1: Introduction

2011-01-19T08:25:00.000-08:00

I'm starting here a new mini tutorial on taking a PSD and converting it to a LWUIT application, this is a very useful talent for a developer since graphics artists would often produce a Photoshop PSD and expect you to develop from it.
Its also useful since there are many free PSD resources on the web from which you can pick up existing designs, even designs originally designed for web which is exactly what I did... I picked a design from this site whichI found here. There are MANY free design resources you can find and leverage over the web and many Photoshop tutorials, by combining your technical skills with very minimal access to these UI tools you can produce remarkable UI's.

LWUIT Resource Editor Tutorial Part 10: Taking The Lead

2011-01-10T07:56:00.000-08:00

In this part of the resource editor tutorial covers the Lead Component feature of LWUIT/resource editor which allows creating some elaborate composite components. A composite component is a single component that is assembled of multiple distinct components of its own. E.g. a multiline button, checkbox etc.
In the tutorial I go over a couple of different strategies eventually settling on the lead component strategy.

LWUIT Resource Editor Tutorial Part 9: A Splash of Timeline

2011-01-03T07:46:00.000-08:00

This time in the resource editor tutorial series I go into the details of creating the simple timeline animation from the previous part. Here I animate the spoon swinging effect to create a compelling (yet cheap in terms of RAM/CPU) effect that's useful for splash screens and form backgrounds.

LWUIT Resource Editor Tutorial Part 8: Splash Screen Revisited

2010-12-27T03:15:00.000-08:00

In this part of the LWUIT resource editor tutorial I go in depth into details of how to create a photoshop like layered UI and make it animate for complex UI constructs that can adapt to different resolutions more effectively.

LWUIT mailing list down

2010-12-23T21:02:00.000-08:00

As part of the changes to the java.net site the users mailing list echo emails are bouncing since they aren't recognized by the spam filter. I hope this problem gets resolved soon, in the meantime please use the LWUIT forum instead of the mailing list.

LWUIT Resource Editor Tutorial Part 7: Localization And Internationalization

2010-12-22T03:39:00.000-08:00

In this part of the resource editor tutorial I cover how a user can localize a LWUIT application especially one built with the UI builder but generally this logic can be applied to any application. I also show off some new UI builder features for localization. Specifically the ability to fetch all the keys from the UI and edit localization data directly in the builder tool.

A Better Way To Blackberry And Misc Announcements

2010-12-09T04:09:00.000-08:00

In the past I posted some instructions on how to get LWUIT working on the blackbberry with the Netbeans IDE's using bbant. In my usual fashion these were somewhat complex instructions that caused quite a bit of grief.
There is a better way! Chen came up with it for the 1.4 release, I originally discounted it since I tried something similar which didn't work. I now tried it again and understood that the methodology allows for something much simpler:

Install the desired JDE versions (we recommend 5.0 for touch and 4.2 if you need legacy support, notice that you should install both if you want both!).
Install the Netbeans blackberry plugin from here.
Select the RIM platform using the standard add platform button (the manage emulators button in the platform tree node in the properties dialog). That's it if you just want to write MIDlets!
To write applications (which is where I failed last time) you need to fix the build-impl.xml which incorrectly generates a MIDlet. To prevent your changes from being overwritten you can just paste them into your standard build.xml.
Open your build-impl.xml (within the nb-project dir) search for the target "create-cod" and copy the entire target to your build.xml.
Replace the <arg value="-midlet"> argument with <arg value="-cldc">

That's much simpler...

Besides this I was asked to post about a couple of upcoming events specifically JavaOne Beijing & Brazil both of which seem to contain LWUIT related talks although I'm not sure who will be giving them. In Beijing specifically there are:
Rich Applications and Services for the Mobile Masses (1265)

Introducing Java TV Widget Development (2685)

Writing Stunning Cross-Platform Applications Using LWUIT (1245)

Which are all LWUIT related (the last of which seems to be Chen's J1 session).

If you are a developer in China we would appreciate some application information/screenshots (sent to out lwuit at sun dot com address), there is some push within Oracle for LWUIT in China and our managers have specifically asked for such applications.

LWUIT Resource Editor Tutorial Part 6: Lists & Renderers

2010-12-08T04:07:00.000-08:00

In this part of the tutorial I go over the basic ideas behind lists & cell renderers. Lists in the GUI builder have most of the power that they have within LWUIT proper including renderers and models, with some simplifications in place.

LWUIT Resource Editor Developers Tutorial Part 1

2010-12-06T05:21:00.000-08:00

This is a different kind of tutorial for the resource editor designed for developers who want to integrate their code with the resource editor's output. There will be additional parts for this tutorial as well as additional parts to the standard resource editor tutorial.

LWUIT Resource Editor Tutorial Part 5: Ratios 3

2010-12-01T03:54:00.000-08:00

In this third part of the tutorial I essentially complete the demo (minor tweaks can be made but they should be pretty obvious). I also show off a somewhat modified UI for theme creation in the resource editor that makes it somewhat easier to navigate elaborate themes.
I also demonstrate some of the latest features to drop into the GUI builder such as multi-selection and in place editing.
While this concludes the initial main demo tutorial I still intend to keep up with producing further tutorials for the more advanced functionality as well as for the other parts of the tool such as localization.

LWUIT Resource Editor Tutorial Part 4: Ratios 2

2010-11-21T21:09:00.000-08:00

In this second part of the ratios tutorial I go on with customizing the result to produce something that's closer in resemblance to the final result and pretty much finish the first two forms. The last remaining form is the tabs form in the demo.
Notice that the ratio application UI is designed for the iPhone hence it has no focus behavior or anything of that type. A real world application targeting devices that support none-touch input as well would also add selected styles to the mix.
In part 3 I hope to conclude the demo although I might use the ratio demo some more to demonstrate some features of the resource editor such as localization and some more advanced themeing/animations.

LWUIT Resource Editor Tutorial Part 3: Ratios 1

2010-11-17T03:34:00.000-08:00

In this part of the LWUIT resource editor tutorial I demonstrate how I created the Ratio's demo based on Michael Ruhlman's excellent Ratio iPhone/Android applications (more info at http://ruhlman.com/).
This demo shows how one can take a real world application and replicate its UI/functionality rapidly in LWUIT to get it running on all devices.
This tutorial is divided into several parts due to the video length limitation of Youtube and to make it easier to watch in parts.
I'm working on transcribing the videos since my accent is problematic for many people, it takes me a very long time to transcribe though so if anyone can do this fast it would be helpful (the automatic tools don't understand me either...).

Second Part of The New Resource Editor Tutorial

2010-11-10T04:06:00.000-08:00

So far so good, another part of the resource editor tutorial has made its way up to youtube.... In this part I try to take a step back and cover some basics of what is a theme and how to apply it, I go over some of the basics of what is a selector and how to determine a value for it.

New URL for the LWUIT Forums

2010-11-04T05:06:00.000-07:00

The LWUIT forum was down for a while this week and went up with past links being broken.
All the messages are still there under the newer version of the forums, you can find the new forum here.

New Resource Editor Tutorial Part 1

2010-11-03T03:50:00.000-07:00

I hope to make this a weekly tradition for the next couple of months until we have a respectable set of videos covering all the features of the new resource editor in detail. The first video is just a warmup showing off how quickly one can create a hello world UI with the resource editor.

Tips About Compatibility Issues With My Latest Commits

2010-10-23T03:33:00.000-07:00

I just committed some major refactoring to the LWUIT code base the other day, I changed the way Dialogs work so the style of the Dialog UIID actually surrounds the "dialog" as one would expect... This works really well but is highly incompatible since the change required quite a bit of hacks. I also moved the alignment attribute into the Style class which doesn't seem like something that would break compatibility but it does.

If you are running into problems with your existing code try the following:

You can use the old Dialog logic by invoking Dialog.setDialogTitleCompatibilityMode(true);
This is mostly intended as an intermediate solution until you can fix your theme/code.
If you used Dialog style manipulations by changing the Dialog's content pane this will no longer work as expected! You will need to use the Dialog.setDialogStyle/UIID() methods instead.

If you find that alignment is broken for some use cases its usually triggered by changing the style after setting alignment. The solutions for this are to either define the alignment in the theme or just move the alignment setting code to a point after you change the style e.g.:
cmp.setAlignment(LEFT);
cmp.setUIID("SomethingElse");

Will replace the style component in the component and break its alignment, you need to make sure this doesn't happen.