Once in a lifetime

The Developer's Conference 2008 was great !
The organizers have received very good feedback !
Congratulations !

A once in a lifetime photo:

me (diamond-powder), Ed Burns (JSF 2.0), Reza Rahman (EJB 3.1 / Java EE 6).

I have to save it for my grandchilds.

Beer at the end of day two:
Burr Sutter (Red Hat), Melissa and Yara (Globalcode), Edgar Silva (Red Hat), and me (diamond-powder)

First-class networking:

Rodrigo (GUJavaSC), Ed Burns (JSF 2.0), Wagner Santos (diamond-powder / netfeijao)

the developer's conferece 2008

During July 25 and 26 I'll be at the developer's conference - a Java Conference organized by Globalcode, in São Paulo - Brazil.

This year the conference gathers three international speakers:

• Reza Rahman, EJB 3.1 expert group
• Ed Burns, JSF 2.0 spec leader
• Burr Sutter, SOA expert from JBoss

I'll speak on July 25 about Architectures of Persistence Layers in Java EE projects.
Sure, I'll be pleased to talk about diamond-powder with any one interested.

We have logo !

Moving backwards

The aim of diamond powder is to provide a simple way to construct data collectors inside JavaME MIDlets. The framework is based on LCDUI and RMS APIs, and do not demand any MIDP 2.0 feature.

Therefore, version 0.4 contains several refactors to adhere to CLCD-1.0 / MIDP-1.0 platform.
(Of course, it stills MIDP-2.0 compatible)

The add-cmd-diamond-powder sample project has been configured with CLCD-1.0 / MIDP-1.0 platform.

Multiple Choices

In our last example (too-many-choices) the MIDlet displays as last screen a ChoiceGroup that allows multiple selection:





This is possible due to the following schema configuration:


schema.put("field.facilities", "choicegroup;;allFacilities;multiple");


And the choicegroup is connected to the following listmodel:

schema.put("listmodel.allFacilities",
"1;Air Pump;2;Oil Change;7;Car Wash;4;Snack Bar;6;Convenience Store;12;Repair Shop");


Two noteworthy related features:

• A listmodel has a good reason for a requiring numerical ids for each displayable choice: it saves RMS - when a Collector is submited to a StorageManager, only the ids from selecteted choices are stored, as primitive shorts.

• The filter componentes are able to deal with choicegroups whatever is their selection modes: exclusive or multiple.

Plus, one noteworthy non-related feature:

• The last page doesn't have a help definition - in this case Diamond Powder manages to remove the Help Command from screen.
  

we've got some reinforcements

Wagner Santos, a former atendee of my Java classes, has been doing a great job in brazilian NetBeans community, and now Diamond Powder is pleased have him as a collaborator.
He is in charge of developing a Diamond Powder schema generation NetBeans plug-in.
Be very welcomed Wagner !

Too many choices

We all know, many Java ME devices impose several restrictions in terms of user interface. The screen are small, the non-Qwerty keyboards are clumsy if you're not a SMS addicted.
It's not hard to figure out: the less you demand user typing, the more successful your mobile application is prone to be.
Well planed LCDUI ChoiceGroups are valuable to keep user away from typing.
When modeling a Data Collector inside a MIDlet I often find at least one big ChoiceGroup with too many elements to display. Indeed it can save user typing, however it poses another problem:the scrolling will be annoying with more than 15 ChoiceGroup elements.
It takes a turn for worse if your ChoiceGroup is huge: While acceptable in emulators at development time, a huge list can break your MIDlet once deployed to a real device. My Sony Ericsson K300i does not tolerate more than 256 ChoiceGroup elements.

Can Diamond Powder address this issue ?
Keep reading...

Everybody is used to fill suggestion boxes in Desktop or Web 2.0 applications. It handles big or huge lists of choices, and restrain it to small lists of choices.
If you have already tried Diamond Powder choicegroups and listmodels (see previous posts), you're exactly one line of schema configuration from building a kind of LCDUI suggestion box.

The too-many-choices sample brings a huge list of gas station brands: there are over 700 elements. It works with diamond-powder-0.3.jar (or newer).
We use the concept of Filter to shrink such a huge list of options. Take a look:



The field brandFilter is your (brand) new friend:

schema.put("field.brandFilter", "filter;brands filter;gasStationBrand;sorted");

• filter: is the field type (actually it is rendered as a TextField)
• 'brands filter': is the filter label
• gasStationBrand: a choicegroup, that´s going to be 'filtered'
  
• sorted: a flag telling our filter that the choicegroup elements are alphabetically sorted - it speeds up processing. The other values allowed here are 'unsorted' (the self-explanatory default), and 'initials'. During your experiences, try 'initials', and watch the difference.
  

The choicegroup gasStationBrand has a never seen before property:

schema.put("field.gasStationBrand", "choicegroup;brand;allBrands;exclusive;true");

• true: It means that a choicegroup is completely ruled by a filter, from the very beginning - in this case, an empty filter will prevent from showing choicegroup elements (and prevent you MIDlet from crash in real world if your choicegroup is huge). Try 'false' (the default) and watch the difference.
  

Finally, listmodel allBrands carries too many gas station brands.