See If You Can Spot LWUIT In The Blackberry Keynote...

LWUIT on Blackberry is apparently a keynote quality port ;-)

LWUIT At JavaOne 2010

If you are going to JavaOne this year there are quite a few LWUIT related sessions/BoF's you should probably add to your schedule.
The first is Chen and my traditional JavaOne session, unfortunately I won't be able to attend this year due to family issues and Ariel Levin will replace me in this session (for those who don't know Ariel, he has a long and glorious history with Java ME and is a pretty entertaining/knowledgeable speaker). Chen who is "the father of LWUIT" needs no further introduction... The session ID is S313185 "Writing Stunning Cross-Platform Applications Using LWUIT".

Terrence also needs no introduction either to readers of this blog, his session S314178 "Beyond Smartphones: Rich Applications and Services for the Mobile Masses" promises to be very interesting and packed with visual delight. From the demo I saw recently it seems he has the code nailed down and its sure to be an interesting session!

Alon will give a BoF on more practical day to day LWUIT development from the trenches in S314033 "LWUIT Cheat Sheet: How to Optimize Your LWUIT-Based Java ME Applications". LWUIT essentially started as a library for a Java application built within Sun's operator group, this application has passed many incarnations and the team moved back and forth in different directions. However, all things considered this is the longest running LWUIT application project in existence simply because our guys were there on the ground floor before LWUIT existed. Alon's team is building one of the best looking LWUIT applications we've seen and unlike most 3rd party applications, since they have full time access to our team they are using the latest and greatest cutting edge stuff in LWUIT.

Those of you looking to expand your horizons into LWUIT on TV would find a couple of sessions on the matter very interesting, the first S313442 " Developing Java TV Applications with LWUIT for DTVi-J (Ginga-J) Brazil" is lead by Tamir a core member of the LWUIT team who spent most of his time running the TV effort in our group. Ofir sadly couldn't come either due to scheduling conflicts, regardless Tamir is a great and thorough speaker. Understanding exactly the differences between TV and current LWUIT development is very important if you have thoughts on entering this space.

Last but not least is another TV related session with Ariel, Ziv and Bill all of whom very seasoned speakers who in session S313627 "Introducing Java TV Widget Development " would cover LWUIT as well. It should be very interesting as well.

Peer Into The Future Of LWUIT

In my latest commit to LWUIT's trunk I added one of the major features intended for the next version of LWUIT: PeerComponent support. Peer components are essentially native components, e.g. a "fake" LWUIT component which represents the true underlying phone platform native component. This functionality is implementation specific and only works on RIM right now (we have a POC on AWT as well), it will not work for MIDP 2.x which doesn't allow arbitrary component placement.
Generally when we call LWUIT a lightweight framework we are borrowing the concept from Swing which treats all components implemented in pure java as lightweight (or peerless components) and all native OS components (such as AWT components) as heavyweight (or peer components).

In LWUIT we could not integrate with heavyweight/native components so we took advantage of that and generally took over the entire screen. Which is normally a huge advantage for LWUIT since it allowed us to implement lots of cool special effects very easily and streamline our implementation/porting efforts.

However as we ventured to platforms other than MIDP and even within some MIDP special cases (such as the MediaComponent) we wanted to allow implementation specific enhancements that provide some advantages only the native platform can offer. E.g. text input usually works best on the native front since it has access to localization/dictionary information that we are not privilege to.

In my latest commit I opened up a feature allowing implementation authors to expose access to the native component model and allow embedding such components in LWUIT. E.g. within the new blackberry implementation you can now do something like this:
ButtonField nativeRIMButton = new ButtonField("Hello");
PeerComponent peer = PeerComponent.create(nativeRIMButton);
lwuitContainer.add(peer);


While the example above might not be so useful for a button it would definitely ease integration with platform specific features and 3rd party widgets. However, this feature comes with MANY limitations and issues...
Peer components are rendered by the native platform hence the LWUIT drawing might have some issues with them. Currently under blackberry all peers are always rendered on top of everything hence no z-ordering or glasspane effects.
In the case of dialogs/menus etc. the peer components would disappear in the current implementation. I hope to improve this logic but its quite probable that glass panes/z-ordering will never work for peer components on RIM since the RIM API is very thread sensitive and won't allow us to perform the drawing on the LWUIT thread without risking major deadlocks.


As part of this change I deprecated the MediaComponent completely and replaced it with the more elaborate VideoComponent which in itself is a subclass of PeerComponent. The video component tries to hide the MMAPI implementation details further to allow different media API's in underlying native platforms e.g. JMF on TV.


I'll try to give more examples and details in my next blog post.

Terrence Conducting a LWUIT Webinar

Terrence will conduct a LWUIT webinar on September 16th, for more details go to Terrence's blog.

Feedback On The Release/Features Of LWUIT 1.4

We are looking for feedback on release 1.4 of LWUIT for internal promotion within Oracle, we might try to form a more organized survey for a later date but right now we want to get general abstract impressions.
Have you updated to 1.4, if not when do you plan to do this? What features of 1.4 do you like? Which features are you using? Where do you see LWUIT going for the next version? What would you like to see in LWUIT?
Feel free to rant and provide abstract thoughts/context.

Thanks.

Opening A New Tab In LWUIT

Late last week Chen finally committed one of our long outstanding promises to the LWUIT community, a rewrite of the aging TabbedPane. When we initially released LWUIT 1.0, the tabbed pane was one of the more complex components since it depended on several different LWUIT components to provide its functionality and was limited by missing features in LWUIT.
When the tabbed pane was written there was only one style per component, there was no Border object, no z-ordering. Eventually we chose an architecture for the TabbedPane that revolved around a list component coupled with a container and rather elaborate border drawing. The biggest drawback was the tedious customization process requiring manually deriving the look and feel to customize the renderer logic of the tabs.

The final push we needed to "just do it" was from Thorsten who took my swipe demo code and just turned it into a more real world demo using actual components... Very cool stuff. This inspired Chen to truly revolutionize the component and create a completely new touch optimized tabbed pane implementation that still works with the regular keyboard although differently (you now have to press fire to actually switch a tab).

Since the changes are so huge we decided to create a whole new drop in component called Tabs which is a drop in replacement for TabbedPane (just change all references to Tabs). For the next version of LWUIT we will probably remove TabbedPane entirely and have now deprecated its usage.

In the video you can see a very simple demo, the component supports allot of functionality that isn't demoed such as hidden tabs (for just a gesture based UI), full customization of the tabs etc. To make this demo I just changed the tabbed pane references in the LWUIT demo to Tabs.

Basic Usage of LWUIT4IO

Last week I wrote about LWUIT4IO but didn't really explain how to utilize it properly and what makes it completely different from just using the GCF (Generic Connection Framework: Connector.open etc.).

Normally in MIDP you would just connect to the internet using Connector.open(String, ?) and get a connection object or a stream. The process seems simple enough but there are lots of hidden caveats in this process. For instance you would need to handle errors in case they happen (and they often do on a mobile device), in which case you need to show an error dialog (which is usually very uniform for all the connections you have in your application.
You also need to conduct the networking in a separate thread that is neither the LWUIT nor the default MIDP thread since these threads will block the UI from updating. After finishing every operation or in case of an exception it is critical in MIDP to cleanup all the connections/streams appropriately. Developers often forget to do this because the GC often removes that need, but with the GCF it is often critical to invoke close() otherwise native resources won't be freed and might cause issues on some devices (very common issue in feature phones).

LWUIT4IO tries to solve all of these by hiding the entire process of networking behind a component API, e.g. to connect to a URL and fetch its content in LWUIT4IO one could do just:
NetworkManager.getInstance().addToQueue(myRequest);

You do first need to initialize LWUIT4IO by invoking (similar to the need of invoking Display.init once):
NetworkManager.getInstance().start();

The request object is a callback class that includes the URL/arguments and request method (get/post). The network thread will perform the connection and invoke the proper callback methods within the request object e.g.:
ConnectionRequest myRequest = new ConnectionRequest();
myRequest.setUrl("http://mysite.com/");
myRequest.addArg("arg", "value");
addResponseListener(new ActionListener() {
public void actionEvent(ActionEvent ev) {
NetworkEvent n = (NetworkEvent)ev;

// gets the data from the server as a byte array...
byte[] data = (byte[])n.getMetaData();
}
});

Alternatively one can override the code to read/write the request values e.g.:
ConnectionRequest myRequest = new ConnectionRequest() {
protected void readResponse(InputStream input) throws IOException {
// read from the input stream...
}
};

Besides the advantages of the more generic code, the true advantages you gain in using this approach is quite remarkable:

• You don't need to write threading code - LWUIT callbacks (e.g. actionPerformed) are on the LWUIT EDT seamlessly. Everything else automatically goes to the network thread...
  
• Exceptions are caught and handled without any need to do anything.
• You don't need to close streams or connections ever!
• All streams are buffered so you don't need to worry abound efficiency of reading from a data input stream.
• You can utilize inheritance and reuse code far more extensively
• Cookies, redirects work pretty much like you would expect without any additional code.