Aaron Ardiri wrote...
> if they just write the peers in the library, it is up to the
> developers NOT to use the pdf.* librarys in their code.
> if they write AWT code.. it is the same everywhere.
> - they dont need to provide all AWT.. just the stuff that is
> available.
This highlights the most significant problem with the AWT approach,
especially on smaller devices with PDA-centric interfaces. We wrote a thin
client remote AWT system (a la Citrix) for Palm and CE. We had to develop
gadget type components to fill in significant missing pieces on both
platforms and the AWT obviously does not have components that take advantage
of PalmOS inputs like the square radio buttons, which have some drawbacks
when used with larger labels. Obviously, we did not implement the entire
AWT, but we reproduced a significant portion of it. You end up with the
least common denominator, an inconsistent Java application and you don't
take advantage of native idioms. If you only implement "...just the stuff
that is available," then you can't provide compatibility across platforms.
When it comes down to it, PalmOS UI elements, just like elements on any
other platform, are pictures. The Lightweight approach is actually better on
smaller devices, because you only have to port the drawing code and the UI
component use that to draw themselves. You still don't get to use the input
idioms specific to a single platform, but you get consistent java
applications and you are no longer working toward the least common
denominator.
TJMOICBW,
Dan
