The source code is only available via SVN, if
you don't know how to use SVN please research the internet for instructions on that subject.
Binaries are released periodically without a specific schedule and are available as LWUIT drops.
First search the forum
and the issue tracker, if the
answer isn't covered you can post a question to the forum. Make sure to use the CURRENT
SVN only! Questions regarding
drops are problematic since they force us to recall long resolved issues.
If you wish to file an issue/RFE (also required to provide attachements) use the issue tracker, it requires you to be a project member. Make sure to only request observer role! All other role requests are automatically regected!
Before filing an issue make sure you provide code which can be used standalone to reproduce the problem against the current SVN.
See the following question about contribution.
By signing the SCA and emailing a scanned version to lwuit (at) sun.com as explained in the LWUIT-incubator project. Please do not send source code for inclusion in LWUIT without signing this document first.
Terrence Barr answered this in great detail.
See if the performance problem exists in the LWUIT Demo, LWUIT-Makeover etc.
If the use case isn't represented there try to build a use case which represents
the performance issue and investigate.
Both the developer guide and the blog cover the issue of optimizing performance and memory footprint.
Check that your application doesn't hold onto pointers for components, since a component references its parent component holding onto a single button can keep an entire form with all its content in memory... LWUIT allocates and discards frequently to allow for a small memory footprint, this causes the graph of free memory to fluctuate but the alternative of caching would be worse for highly constrained devices. Check out the LWUIT blog for more information on the subject of tracking and identifying memory issues.
You need to disable the scrolling for the form using myForm.setScrollable(false) and you should place the list in a center of a border layout. For deeper understanding of why this is required read the next question about scrolling.
LWUIT features an open interface for scrolling allowing any component to define the way
in which it wishes to scroll. This interface is used by the TextArea and List components
to implement their internal scroll functionality.
LWUIT doesn't scroll containers, instead it provides focus traversal which causes scrolling to the focused component. This is a very powerful approach (and very common on small devices) since it allows easy interaction, however in some circumstances (mostly viewers) LWUIT focus based scrolling doesn't behave as expected. Since the scrolling architecutre is exposed, developers can extend container and override the scrolling/key handling to behave as expected.
Scrolling a single component which is larger than the screen isn't supported by LWUIT containers by default (this is a very difficult edge case for focus based scrolling). Scrolling multiple smaller components is not a problem.
Community member Elliot Long contributed his own solution to "visual scrolling" which allows scrolling without focus. The LWUIT blog covers simple image scrolling and explains the details here.
List is designed for a very large number of element and fast traversal, you can use its cell renderer facility to customize it any way you want as explained here. How the list can scale and grow is explained here and additionally here.
99% of the problems of this type are related to EDT violations. The EDT is the Event Dispatch
Thread which broadcasts all the events in LWUIT, it is also responsible for drawing all elements
on the screen.
The EDT thread is responsible for drawing all screen elements, if it is blocked by a long running operation elements won't update and key/pointer events won't be received. The solution is to use threads for such long running tasks, however interaction with LWUIT can only be performed on the EDT. To return into the EDT you can use Display.callSerially/callSeriallyAndWait, a different option is to use invokeAndBlock.
A typical application always uses at least two threads, lifecycle and the EDT. The lifecycle thread is the callback thread used for the application, e.g. in MIDP the startApp method is invoked from the MIDP thread which is different from the EDT.
There are no guarantees, repaint() should generally work from every thread and show() should as well.
Use a Dialog instance and a version of show which accepts 4 integer values to position the dialog. You can use the set the default dialog position to simplify dialog positioning.
Use MMAPI to create a Player object which you can submit to the MediaComponent class.
Use the M3G API or the SVGImage API to place such elements in the UI.
Everything in LWUIT is fully extensible, you can derive from any component and extend it. It is demonstrated in the developer guide and extensively in the blog.
Animated gifs can be shown in MIDP using the MMAPI and MediaComponent (see the MMAPI question). LWUIT has special support for StaticAnimation which is a LWUIT specific format very similar to the animated gif. Both the resource editor and the ant task accept animated GIF files to create static animations.
The BlackBerry VM has some issues with linking to classes that aren't on the device, a BlackBerry specific version built with the BlackBerry VM is necessary. See the LWUIT-incubator project for a community built port for the BlackBerry.
Use the LWUIT Designer (formerly the resource editor) or Ant task, both are covered in the developer guide.
The difference is mainly in the use case, the ant tool is designed mostly for developer related resources (locales, application images etc..). The LWUIT Designer is desgined for use by graphics desginers.
No, allot of the information no longer exists within the resource file such as
the actual name of the bitmap fonts etc.
However, we are considering a future modification to the resource file format that will allow such functionality.
Compatibility mode allows LWUIT styles to function in a way similar to the
first revisions of LWUIT where one style mapped to one component instance.
Newer versions of LWUIT allow 2 or more styles per component and deprecate
the usage of the selection attributes (bgSelectionColor, fgSelectionColor) in
favor of a separate style to indicate selection state.
Existing code that manipulates styles using the getStyle()/setStyle() methods might not function in the same way. For further details please read: http://lwuit.blogspot.com/2009/03/breaking-to-make-things-better.html.