- Smart User Interface Technology for Everyone
- Portability and Broad Device Support
- Small Footprint API
- Web Support
- Themes
- ... and so on, and so on...
An existence of LWUIT conflicts with a Java slogan "Write once, Run everywhere"! Why Java ME developers need to use LWUIT instead of using raw UI API? It looks like LWUIT goes the same way Swing did against native AWT.
However, in case of Swing there was possible to have a few LAF implementations that make Swing app look natively under host OS. So, app user couldn't see difference. It is not a case for LWUIT. They even do not declare it as a goal. With LWUIT Java ME apps will be like colorful fish in the aquarium...
I'd better insist developers to use native UI API and develop techniques to make apps look better and consistent with native headset UI and theme.
LWUIT does support a pluggable look and feel and installing a native theme/plaf by the platform native implementation when available. Older J2ME devices just don't provide access to the native look and feel so that feature wasn't highlighted but it does work on blackberry, Android etc.
ReplyDeleteLWUIT also supports embedding arbitrary native components into the UI on platforms that support it (Android, RIM etc.).
Native widget libraries always fail on the portability/performance front and this is doubly so in mobile where the platforms are so ridiculously different from one another.
We have learned the lessons of Swing well:
http://www.lwuit.com/2011/11/how-lwuit-is-different-better-from.html