Monday, September 27, 2010
See If You Can Spot LWUIT In The Blackberry Keynote...
Tuesday, September 14, 2010
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.
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.
Thursday, September 9, 2010
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.
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.
Tuesday, September 7, 2010
Terrence Conducting a LWUIT Webinar
Terrence will conduct a LWUIT webinar on September 16th, for more details go to Terrence's blog.
Wednesday, September 1, 2010
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.
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.
Subscribe to:
Posts (Atom)