Sunday, May 29, 2011
Preview Of The New LWUIT Friends t-Zone Demo
This demo is coming soon, full source code and everything. It doesn't really have much source code since the whole thing was created in the GUI builder with very little code. I hope to also create a tutorial showing off exactly how this demo was made.
BTW If you have a stack overflow account please go to this question and vote up my answer, its amazing how the worst possible LWUIT screenshots could be picked off this blog... Frankly its also a bit of my fault since finding proper screenshots of newer applications (not videos) is a bit hard. I should get on to that.
Wednesday, May 25, 2011
Clicking Within A Cell Renderer
One of the things people looked for quite often in Lists was the ability to click on a specific element within a ListCellRenderer to get an event specific to that element. E.g. a list with X's drawn on the side to remove the element.
In the past we contended that since the list is stateless its impossible for us to provide such information and recommended people use a Container with items. We now have a solution which works only for touch devices, this feature allows adding a listener to a component within the renderer which will now trigger an event if the component is touched.
Notice that the component will not contain the right data since the list selection indicates the actual selection, however if you add a listener to a button containing the X you should get an action event on that button before the list action event. This will allow you to toggle a flag indicating that the X was pressed and not a different portion of the renderer.
This isn't ideal but since the list is stateless this is the best we could come up with.
Assuming you used the GUI builder & GenericListCellRenderer you can use the method GenericListCellRenderer.extractLastClickedComponent() in the action listener for the list to get the button that was pressed to generate this event or null if no button was pressed.
I apologize for the lack of videos recently, we are working very hard towards a LWUIT release in June (hopefully, bureaucracy is always our foe) so I don't have quite the same amount of cycles to dedicate for proper blogging. I'll try to get something decent going soon.
In the past we contended that since the list is stateless its impossible for us to provide such information and recommended people use a Container with items. We now have a solution which works only for touch devices, this feature allows adding a listener to a component within the renderer which will now trigger an event if the component is touched.
Notice that the component will not contain the right data since the list selection indicates the actual selection, however if you add a listener to a button containing the X you should get an action event on that button before the list action event. This will allow you to toggle a flag indicating that the X was pressed and not a different portion of the renderer.
This isn't ideal but since the list is stateless this is the best we could come up with.
Assuming you used the GUI builder & GenericListCellRenderer you can use the method GenericListCellRenderer.extractLastClickedComponent() in the action listener for the list to get the button that was pressed to generate this event or null if no button was pressed.
I apologize for the lack of videos recently, we are working very hard towards a LWUIT release in June (hopefully, bureaucracy is always our foe) so I don't have quite the same amount of cycles to dedicate for proper blogging. I'll try to get something decent going soon.
Wednesday, May 18, 2011
Logging & Caching In LWUIT4IO
We've been quite busy with holidays and Chen going off to JavaOne in India so I didn't have as much time to blog as I normally do or prepare the videos I should be working on. Hopefully I'll recover some time soon and be able to get back to my normal pace.
In recent LWUIT SVN's I deprecated and effectively removed the venerable log class. The main motivation behind that is the fact that logging didn't go through the platform code and never made sense in LWUIT. It was hardcoded for MIDP and had many issues.
That class is replaced by an almost identical class within LWUIT4IO which has similar functionality with a few cool new features. First, it can run on all platforms including Java SE, RIM, MIDP and even Thorsten's new Android port of LWUIT4IO.
Then it has one more "killer feature", it can track file IO seamlessly!
Unlike J2SE, most mobile platforms are really sensitive regarding forgotten streams and its essential to close every stream you open. The problem is that its often really hard to keep track in a large application that deals with many dynamic files constantly. However, since all LWUIT4IO streams are buffered it can easily tell when a stream is opened/closed or double closed. This gets logged automatically if you invoke Log.getInstance().trackFileSystem() which will cause entries to appear in your log containing the URL opened/closed and the number of open streams. This feature helped me in tracking some pretty hairy bugs.
Another feature in LWUIT4IO to which I didn't give enough spotlight is the cache map, its effectively a lean hashtable which stores its data using weak/soft references (depending on the platform) and falls back to storage when not enough memory is available. Its a great way to cache data without going overboard.
One of the cool things about it is the fact that we use it seamlessly for our storage abstraction (which hides RMS or equivalent services) in effect providing faster access to RMS storage which is often slow on devices.
While writing on that subject it dawned on me that I never blogged about our "seamless" serialization support in LWUIT4IO. The Storage class and util class contain methods for reading/writing of objects. All the basic JavaME data types should be supported including: primitive arrays, Strings, Object arrays, Hashtable's and vectors. Arbitrary objects can be stored by implementing com.sun.lwuit.io.Externalizable. This allows easy/efficient persistence and networking between applications.
Give these features a try and let us know how they work for you.
As a side note: due to recent issues with the forum/mailing list that unfortunately remain unresolved to this moment I decided to start answering issues in stack overflow which has a great LWUIT section.
In recent LWUIT SVN's I deprecated and effectively removed the venerable log class. The main motivation behind that is the fact that logging didn't go through the platform code and never made sense in LWUIT. It was hardcoded for MIDP and had many issues.
That class is replaced by an almost identical class within LWUIT4IO which has similar functionality with a few cool new features. First, it can run on all platforms including Java SE, RIM, MIDP and even Thorsten's new Android port of LWUIT4IO.
Then it has one more "killer feature", it can track file IO seamlessly!
Unlike J2SE, most mobile platforms are really sensitive regarding forgotten streams and its essential to close every stream you open. The problem is that its often really hard to keep track in a large application that deals with many dynamic files constantly. However, since all LWUIT4IO streams are buffered it can easily tell when a stream is opened/closed or double closed. This gets logged automatically if you invoke Log.getInstance().trackFileSystem() which will cause entries to appear in your log containing the URL opened/closed and the number of open streams. This feature helped me in tracking some pretty hairy bugs.
Another feature in LWUIT4IO to which I didn't give enough spotlight is the cache map, its effectively a lean hashtable which stores its data using weak/soft references (depending on the platform) and falls back to storage when not enough memory is available. Its a great way to cache data without going overboard.
One of the cool things about it is the fact that we use it seamlessly for our storage abstraction (which hides RMS or equivalent services) in effect providing faster access to RMS storage which is often slow on devices.
While writing on that subject it dawned on me that I never blogged about our "seamless" serialization support in LWUIT4IO. The Storage class and util class contain methods for reading/writing of objects. All the basic JavaME data types should be supported including: primitive arrays, Strings, Object arrays, Hashtable's and vectors. Arbitrary objects can be stored by implementing com.sun.lwuit.io.Externalizable. This allows easy/efficient persistence and networking between applications.
Give these features a try and let us know how they work for you.
As a side note: due to recent issues with the forum/mailing list that unfortunately remain unresolved to this moment I decided to start answering issues in stack overflow which has a great LWUIT section.
Saturday, May 7, 2011
Terrences Cool Meet Me For Dinner Demo
Terrence has just released the sources for his cool "Meet Me For Dinner" JavaOne demo. The demo shows off some pretty cool effects and social web/location interaction.
Check out his post for more information.
Wednesday, May 4, 2011
Play It Again LWUIT
The next version of LWUIT will completely replace the way to interact with media and supersede it with our own API's. When we initially introduced LWUIT's MediaComponent, MIDP was the major target for LWUIT and blackberry support was on top of MIDP.
Since then we had Thorsten porting LWUIT to RIM/Android and introduced ports to TV, Java SE etc. MMAPI isn't available on all of those platforms.
This called for a rethinking of our approach to media and so we introduced VideoComponent which uses the peer component architecture to embed a video into LWUIT. Unlike the older MediaComponent code there is no need for MMAPI know how or any information on the underlying playback. Just use a URL or stream+mime type to playback any video file.
Audio is integrated even deeper right into the Display class with methods to create an audio stream and play it. The main feature here is automatic resource cleanup which is a frequent problem with audio files (neglecting to close an audio resource properly is a big portability issue). LWUIT automatically closes resources as necessary in a way that is completely seamless for the developer, again with no need to know anything about MMAPI or the platform native implementation.
Since then we had Thorsten porting LWUIT to RIM/Android and introduced ports to TV, Java SE etc. MMAPI isn't available on all of those platforms.
This called for a rethinking of our approach to media and so we introduced VideoComponent which uses the peer component architecture to embed a video into LWUIT. Unlike the older MediaComponent code there is no need for MMAPI know how or any information on the underlying playback. Just use a URL or stream+mime type to playback any video file.
Audio is integrated even deeper right into the Display class with methods to create an audio stream and play it. The main feature here is automatic resource cleanup which is a frequent problem with audio files (neglecting to close an audio resource properly is a big portability issue). LWUIT automatically closes resources as necessary in a way that is completely seamless for the developer, again with no need to know anything about MMAPI or the platform native implementation.
Subscribe to:
Posts (Atom)