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.
Wednesday, August 31, 2011
Wednesday, August 24, 2011
Resource Editor Mac Integration
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.
Monday, August 22, 2011
Fixing Netbeans RIM Integration On Windows 7 And Vista
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).
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).
Thursday, August 11, 2011
Java Spotlight Podcast Interview With Chen Fishbein on LWUIT 1.5
LWUIT 1.5 Released (finally!)
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
Tuesday, August 9, 2011
Parsing In LWUIT & LWUIT4IO
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.
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.
Monday, August 1, 2011
Drag And Drop Support In LWUIT
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.
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.
Subscribe to:
Posts (Atom)