Hi,
Yesterday I finished my 'assignment' on the UI of our game IFF. I completed the the registration form and added a form including tabs for maintaining other relevant user data. I then incorporated it all in the game itself. Unfortunately, the book ("LWUIT 1.1 for Java ME Developers") doesn't really elaborate on this topic. It doesn't tell you in so many words how to combine your LWUIT based parts and your old fashioned LCDUI based parts into one MIDlet.
Since we're working with SVG in the actual game and we use LWUIT for the various forms this is relevant. But it all worked out nicely. Replacing our SVG based forms with the LWUIT version was almost without problems. We had an issue with the Display class, but the info in the book was sufficient to fix it. As it turned out, initializing LWUIT's Display in the startApp of the MIDlet was sufficient to get it all working. Probably more so because I created a separate source file containing all code for the LWUIT Form. Hence LWUIT didn't interfere with the rest of the code.
There's a lot more on LWUIT than meets the eye, but I'm actually quite confident that the book can and will help out. But that sounds like an overall summery, something I was planning to write up in a week or two, after I get back from a weeks vacation at the Red Sea, Egypt.
As we will be leaving on Thursday, I've got a few days left to get it all together and have the game available on the website. Which is currently optimized for a 240x320 screen.
Iwan
PS: IFF is tested on a Nokia N85 and an N95. I'm going to test it on a SE W595 as well and a Nokia 6300 is in the pipeline as well. If you have a recent model phone, mid or high-end, you're invited to join our beta test.
Tuesday, September 29, 2009
Friday, September 25, 2009
Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 04 - reaching the end]
Hi,As you could read in the 3rd part of my reviewon "LWUIT 1.1 for Java ME Developers", creating the actual form and putting functionality in it is actually very simple. The book helped me a lot, but mainly because I already new what I wanted, I know some Swing and a reference guide is good enough in those cases. After a bit of effort I ended up with the screen at the right. It looks like a real form, and it behaves as a real form. But you have to be from the sixties to appreciate this kind of GUI, in this day and age you want to see something more appealing.
Look at the previous post and you know where I wanted to end up. The SVG version of the form looks a lot better and more importantly it is in the line of our game IFF's look and feel.
There are 2 main points to be addressed in this perspective:
- The TextFields shouldn't be this high. I need one character high TextFields.
- The style of the form needs adjustment.
So I needed a different layout and the only really other candidate for this type of UI is the GroupLayout. I'd been playing with Matisse in the past (NetBeans' WYSIWYG tool to create Swing UI's) so I knew what was possible. It is also one of the more complicated layouts in LWUIT. But this is where the book shines. The book goes into fair detail on the topic of layouts and very much on the GroupLayout. This is also one of the few occasions I thought that the amount of code in the book was just right. Not too much and not too little. Excellent, because GroupLayout requires a certain kind of thinking which differs from any of the other LWUIT supported layout. It took me about 15 minutes to go through the book's text on the layout and another 5 minutes to create the screen you see above to the left.
Please note, the book doesn't state it, but you should draw your form on a piece of paper before anything else and then draw around your components the groups (Vertical and Horizontal, read the book or the online Developer's Guide and you'll understand) before attempting to code the beast. Unfortunately, Matisse can be used to create the form, but that hasn't been released by the NetBeans team. After posting this I'm going to vote for the related issue 144743 in IssueZilla. Please also vote for it.
Styling is done using either by setting the style of components on the form using code. And the book covers this quite extensively. Actually, I started off by using this mechanism of changing the appearance of the UI. But a more elegantly way of achieving the same is using 'themes'. Themes are sets of definitions of a UI's appearance much like a CSS. LWUIT allows for creating themes in code, but there is also a Theme Editor available. Both ways of creating a theme are very well documented in the book, although I have to say that the Theme Editor is pretty much self-explanatory.
As you can see above, to the left, the UI looks pretty much like the SVG version shown in the previous post, but it's not quite the same. Again the TextFields are a bit different. There's a reason for this, and I found this obviously, considering the image on the right. No help from the book, the Developer Guide or the LWUIT JavaDocs. The problem was in the proportional bitmap font I used in the left image. The problem was corrected by using a system font. I haven't found a way to right-allign the labels. Still to be done, sometime soon.
Iwan
Tuesday, September 22, 2009
Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 03 - first uses]
i,
So the last few days I have been struggling, not with LWUIT but with my health. But I made some progress.
As I stated last time, I think the book "LWUIT 1.1 for Java ME Developers" is more of a reference than a tutorial and while working on the screens for our game, I found that this is true. I still need to download all source-code from the Packt Publishing site, but I think it is safe to say that I won't learn programming using LWUIT with this book.
The route I took is that I have the design of the screens I want to redo in LWUIT available as SVG screens (see for yourself at the left). Like I said before, the support for these SVG forms on my N95 and my N85 is disappointing to say the least, so we chose to use LWUIT instead.
I recreated the form in LWUIT as well as the code behind it, so the components on the form are bound to some attributes in the form. That all worked very nicely. (see at the right)
The book was very helpful in this perspective. It showed me very clearly how to create a form, use different layouts and how to add components to the form. The book doesn't degrade itself to a printout of the JavaDoc, it actually provides a very good mix of API and context.
But you should be aware that unless you know what you want and how it should look like, there's not really a point in opening the book.
As you can tell from the screenshots in this post, the screens have the same fields, but the design is completely different. Fortunately the book has quite a bit on the topic of themes and resources. That's my next mission; Figure out how I can make them look a like, meaning the LWUIT screen to look like the SVG screen. Expect to read about this in the next post.
Iwan
So the last few days I have been struggling, not with LWUIT but with my health. But I made some progress.
As I stated last time, I think the book "LWUIT 1.1 for Java ME Developers" is more of a reference than a tutorial and while working on the screens for our game, I found that this is true. I still need to download all source-code from the Packt Publishing site, but I think it is safe to say that I won't learn programming using LWUIT with this book.The route I took is that I have the design of the screens I want to redo in LWUIT available as SVG screens (see for yourself at the left). Like I said before, the support for these SVG forms on my N95 and my N85 is disappointing to say the least, so we chose to use LWUIT instead.
I recreated the form in LWUIT as well as the code behind it, so the components on the form are bound to some attributes in the form. That all worked very nicely. (see at the right)
The book was very helpful in this perspective. It showed me very clearly how to create a form, use different layouts and how to add components to the form. The book doesn't degrade itself to a printout of the JavaDoc, it actually provides a very good mix of API and context.
But you should be aware that unless you know what you want and how it should look like, there's not really a point in opening the book.
As you can tell from the screenshots in this post, the screens have the same fields, but the design is completely different. Fortunately the book has quite a bit on the topic of themes and resources. That's my next mission; Figure out how I can make them look a like, meaning the LWUIT screen to look like the SVG screen. Expect to read about this in the next post.
Iwan
Monday, September 14, 2009
Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 02 - initial feelings]
Hi,
Last week I posted about the context of my review, I want to use the book "LWUIT 1.1 for Java ME Developers" on a real project in which I start of using LWUIT without know it at all, and see if the book helps me in achieving my goal(s). While doing so I'll be posting my findings as a series of posts resulting in the complete review.
Well my first impression of the book once I opened the box it came in was: "Hmmm, one of those computer books". Which it is of course, so no judging there. Although I find the yellow flower on the cover thought provoking. Why did they choose a yellow flower? If you know the answer, let me know. I haven't gone into the book to find out why.
First of all, the book is on LWUIT 1.1, I'll be using LWUIT 1.2. I want to post about the differences sometime soon, but this is relevant information for you as a reader. Where I think the book is outdated, I'll let you know.
The Table of Contents is straight to the point, it is complete and there is only one. I don't like books where they have a TOC that only covers the high-level chapters and then one that covers all chapters, sections, paragraphs and what not. Waste of paper and my time. Here they've used fonts and styles to make clear what the main sections are and what the subsections are. After reading through the TOC I got the feeling that I'm dealing with a Reference Guide instead of a book to learn LWUIT.
The Preface is doing what it is supposed to do, provide you with all kinds of information not related to the topic of the book, but still you need it while 'using' the book. And here it becomes apparent that I'm dealing with a reference guide. Not a book for the real fresh fish in the LWUIT pond. No problem, I've got Google in my toolbox.
It is also stated that I need the Sprint Wireless Toolkit, which is derived from I believe the Sun WTK, and customized and all by Sprint. Since I'm using the JavaME SDK 3.0 for my LWUIT development or NetBeans 68 (dev builds currently) I might run into somethings here. But maybe not. Since Sprint is an US based mobile provider, I assume that those who're looking to deploy in the US are familiar with the SDK, the rest of the world is probably more WTK (or JavaME SDK) oriented or looking into SDK's by the phone manufacturers/
I've decided not to install the Sprint Wireless Toolkit and will let you know what you can expect when you also follow that route.
So here's how I proceed: I'll find a decent tutorial to get the hang of LWUIT and get it to run in NB and the JavaME SDK by Sun. Then I'll design my screens and will then get back to the book to implement them. Meanwhile I will be reading the book and adjust my plan if I think that makes more sense.
Iwan
Well my first impression of the book once I opened the box it came in was: "Hmmm, one of those computer books". Which it is of course, so no judging there. Although I find the yellow flower on the cover thought provoking. Why did they choose a yellow flower? If you know the answer, let me know. I haven't gone into the book to find out why.
First of all, the book is on LWUIT 1.1, I'll be using LWUIT 1.2. I want to post about the differences sometime soon, but this is relevant information for you as a reader. Where I think the book is outdated, I'll let you know.
The Table of Contents is straight to the point, it is complete and there is only one. I don't like books where they have a TOC that only covers the high-level chapters and then one that covers all chapters, sections, paragraphs and what not. Waste of paper and my time. Here they've used fonts and styles to make clear what the main sections are and what the subsections are. After reading through the TOC I got the feeling that I'm dealing with a Reference Guide instead of a book to learn LWUIT.
The Preface is doing what it is supposed to do, provide you with all kinds of information not related to the topic of the book, but still you need it while 'using' the book. And here it becomes apparent that I'm dealing with a reference guide. Not a book for the real fresh fish in the LWUIT pond. No problem, I've got Google in my toolbox.
It is also stated that I need the Sprint Wireless Toolkit, which is derived from I believe the Sun WTK, and customized and all by Sprint. Since I'm using the JavaME SDK 3.0 for my LWUIT development or NetBeans 68 (dev builds currently) I might run into somethings here. But maybe not. Since Sprint is an US based mobile provider, I assume that those who're looking to deploy in the US are familiar with the SDK, the rest of the world is probably more WTK (or JavaME SDK) oriented or looking into SDK's by the phone manufacturers/
I've decided not to install the Sprint Wireless Toolkit and will let you know what you can expect when you also follow that route.
So here's how I proceed: I'll find a decent tutorial to get the hang of LWUIT and get it to run in NB and the JavaME SDK by Sun. Then I'll design my screens and will then get back to the book to implement them. Meanwhile I will be reading the book and adjust my plan if I think that makes more sense.
Iwan
Friday, September 11, 2009
Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 01 - context]
Hi,
Yesterday I got my review copy of Packt Publishing's book on "LWUIT 1.1 for Java ME Developers" and as promised before I'll post a review as I am reading and more accurately experiencing the book.
I'm currently working together with friends of mine on a free multi-player online realtime strategy game for mobiles. It's called IFF: Identification Friend or Foe and we're in a private beta stage. The reason why we're in private beta is that our sign-up screens in the client aren't working... on all phones. Our major concern while working on the game was related to screen resolution, since all manufacturers of phones have their own specific set of supported resolutions scaling is an important aspect of our GUI. Obviously the choice fell on SVG (Scalable Vector Graphics).
NetBeans has excellent support for SVG and really helps in designing SVG based UI's including forms. So we went working on it and within a few hours we had our prototype of the registration form, to be used in for signing up. All worked fine until we deployed the client to our Nokia phones. The SVG forms don't do well on an N95 or an N85. The actual game UI does excellent on these models but no chance for the forms. So I went installing various Nokia emulators on my Vista box and started debugging. As it turned out, the SVG support on Nokia devices is not to be used for forms, period.
Here comes LWUIT to the rescue... and together with it JavaME SDK 3.0. Marcel and I thought for a moment to do the UI ourselves, but after about 20 seconds we were convinced that it would turn out to be a LWUIT-like framework, so LWUIT it would be.
Around the same time I was approached by Packt Publishing asking if I was interested to review their book on LWUIT 1.1. So we waited to work on the forms in LWUIT until the book arrived and yesterday it did.
What you'll read in these series are my impressions on the book, the quality of the information in it, the usefulness of the book for somebody who knows Swing but not LWUIT and how the book relates to LWUIT 1.2, since that is what I will be using.
Iwan
I'm currently working together with friends of mine on a free multi-player online realtime strategy game for mobiles. It's called IFF: Identification Friend or Foe and we're in a private beta stage. The reason why we're in private beta is that our sign-up screens in the client aren't working... on all phones. Our major concern while working on the game was related to screen resolution, since all manufacturers of phones have their own specific set of supported resolutions scaling is an important aspect of our GUI. Obviously the choice fell on SVG (Scalable Vector Graphics).
NetBeans has excellent support for SVG and really helps in designing SVG based UI's including forms. So we went working on it and within a few hours we had our prototype of the registration form, to be used in for signing up. All worked fine until we deployed the client to our Nokia phones. The SVG forms don't do well on an N95 or an N85. The actual game UI does excellent on these models but no chance for the forms. So I went installing various Nokia emulators on my Vista box and started debugging. As it turned out, the SVG support on Nokia devices is not to be used for forms, period.
Here comes LWUIT to the rescue... and together with it JavaME SDK 3.0. Marcel and I thought for a moment to do the UI ourselves, but after about 20 seconds we were convinced that it would turn out to be a LWUIT-like framework, so LWUIT it would be.
Around the same time I was approached by Packt Publishing asking if I was interested to review their book on LWUIT 1.1. So we waited to work on the forms in LWUIT until the book arrived and yesterday it did.
What you'll read in these series are my impressions on the book, the quality of the information in it, the usefulness of the book for somebody who knows Swing but not LWUIT and how the book relates to LWUIT 1.2, since that is what I will be using.
Iwan
Monday, August 31, 2009
Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 0]
Hi,
Last week I received and answered an email from Packt Publishing. They wanted to know if I was interested to review their book on LWUIT called "LWUIT 1.1 for Java ME Developers". And I said yes, so the book is on its way to me.
Now the interesting part is that we, Marcel and myself, just recently decided to do all the dialogs in our game IFF using LWUIT instead of SVG. Most important reason is that we just can't get dialogs (forms) to work correctly on our N-Series phones. The cursor in edit fields doesn't move correctly, editing only works by switching to the ugly normal text-area input of MIDP.
Although the actual game graphics will remain in SVG, the dialogs (forms) will all be in LWUIT.
Marcel already followed the tutorial on the LWUIT site and is the expert between the two of us, I'm the novice. So I'll be looking at the book from that point of view. Without having written a single character of code that is supposed to use LWUIT I will start on the book and see if it helps me accomplish the tasks at hand... which will result in a series of blog posts.
Hopefully in the end you'll have
Now the interesting part is that we, Marcel and myself, just recently decided to do all the dialogs in our game IFF using LWUIT instead of SVG. Most important reason is that we just can't get dialogs (forms) to work correctly on our N-Series phones. The cursor in edit fields doesn't move correctly, editing only works by switching to the ugly normal text-area input of MIDP.
Although the actual game graphics will remain in SVG, the dialogs (forms) will all be in LWUIT.
Marcel already followed the tutorial on the LWUIT site and is the expert between the two of us, I'm the novice. So I'll be looking at the book from that point of view. Without having written a single character of code that is supposed to use LWUIT I will start on the book and see if it helps me accomplish the tasks at hand... which will result in a series of blog posts.
Hopefully in the end you'll have
- A comprehensive book review on LWUIT
- A more complete version of IFF, which is now in beta if you're interested.
A little annoyance that's groing bigger by the day
Hi,
Promise: Right after publishing this post, I'll file an issue!
So I have setup NB such that the import section and all JavaDoc is collapsed by default when opening a file. Why? Because it clutters my screen and I don't find it helpful to see all that code and documentation.
Since the IDE is doing such a great job in managing my imports and the code-completion shows all JavaDoc when I need it, I don't find it beneficiary to have it in plain sight when I don't need it.
But here's the catch. NB doesn't update the 'focus' of a file when I open it. What I mean is that when I CTRL-Click something in an editor and the source file is not yet opened, NB will open the file, jump to the correct location, make sure that the location is in the visible area on screen and then collapse all editor folds... moving the location of screen. And I need to scroll window to show what I want to see.
This is on NB 6.7.x on Vista at least. Latest updates of the JDK installed of course.
Update: It is filed as issue 171149.
Iwan
Promise: Right after publishing this post, I'll file an issue!
So I have setup NB such that the import section and all JavaDoc is collapsed by default when opening a file. Why? Because it clutters my screen and I don't find it helpful to see all that code and documentation.
Since the IDE is doing such a great job in managing my imports and the code-completion shows all JavaDoc when I need it, I don't find it beneficiary to have it in plain sight when I don't need it.
But here's the catch. NB doesn't update the 'focus' of a file when I open it. What I mean is that when I CTRL-Click something in an editor and the source file is not yet opened, NB will open the file, jump to the correct location, make sure that the location is in the visible area on screen and then collapse all editor folds... moving the location of screen. And I need to scroll window to show what I want to see.
This is on NB 6.7.x on Vista at least. Latest updates of the JDK installed of course.
Update: It is filed as issue 171149.
Iwan
Wednesday, August 19, 2009
Why Netbeans rules Glassfish... racing got me to this conclusion (part 2)
Well, last time I used this title I got some useful comments. Meanwhile I fixed my problems and in fact it was a race condition that I couldn't fix by using locks.
The problem I was facing had to do with the fact that I have a graph of objects that I maintain in a database. Adding a new object to the graph, means that certain objects would point to it as being a new neighbor. Which objects in the graph would get a new neighbor is determined by an algorithm that ensures that this process is 'fair' to the other objects in the graph.
When two or more objects are added more or less simultaneously to the graph, my algorithm would do the same thing and select the same objects that would receive a neighbor. One might argue that the system on this topic is truly stateless.
Anyway, I tried to fix my algorithm to not always pick the same neighbors, that didn't work. I tried to change my datamodel such that the system would be a little more lightweight, that obviously didn't work either. I tried to work with locks which ensured consistency in my model, but still no scalability on this end. I did some tweaking with transaction-scope and that fixed some issues. But finally I realized that I needed the EJB 3.1 Singleton which is not available in 3.0 so I mimicked part of its functionality by introducing a synchronized block on the smallest piece of code that suffered from the concurrency. This together with a smaller transaction scope fixed the problem.
But since that doesn't give me that warm and fuzzy feeling. Especially not since I know there's a solution in EJB 3.1, I'm now considering moving to GF 3 and use EJB 3.1 features. Of course all thru NetBeans' support for GF3 and EJB 3.1.
I'll keep you posted.
Iwan
The problem I was facing had to do with the fact that I have a graph of objects that I maintain in a database. Adding a new object to the graph, means that certain objects would point to it as being a new neighbor. Which objects in the graph would get a new neighbor is determined by an algorithm that ensures that this process is 'fair' to the other objects in the graph.
When two or more objects are added more or less simultaneously to the graph, my algorithm would do the same thing and select the same objects that would receive a neighbor. One might argue that the system on this topic is truly stateless.
Anyway, I tried to fix my algorithm to not always pick the same neighbors, that didn't work. I tried to change my datamodel such that the system would be a little more lightweight, that obviously didn't work either. I tried to work with locks which ensured consistency in my model, but still no scalability on this end. I did some tweaking with transaction-scope and that fixed some issues. But finally I realized that I needed the EJB 3.1 Singleton which is not available in 3.0 so I mimicked part of its functionality by introducing a synchronized block on the smallest piece of code that suffered from the concurrency. This together with a smaller transaction scope fixed the problem.
But since that doesn't give me that warm and fuzzy feeling. Especially not since I know there's a solution in EJB 3.1, I'm now considering moving to GF 3 and use EJB 3.1 features. Of course all thru NetBeans' support for GF3 and EJB 3.1.
I'll keep you posted.
Iwan
Subscribe to:
Posts (Atom)