Tuesday, September 29, 2009

Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 05 - finished]


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.


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.

Friday, September 25, 2009

Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 04 - reaching the end]


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:
  1. The TextFields shouldn't be this high. I need one character high TextFields.
  2. The style of the form needs adjustment.

The reason for the size of the TextFields in the plain and simpel LWUIT form above is that I used GridLayout to ensure that I had two colums of components, one with the labels and one with the TextFields. LWUIT will ensure that the components are distributed across the complete screen. Please note that the form itself has a BorderLayout and in its center there is a container with a GridLayout.
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.

The cool thing of the Theme Editor is that it has a preview window which shows you exactly how the UI will look given the theme you're creating. It also allows you to provide your own MIDlet, but that didn't work with my test MIDlet, which actually is extremely simpel. I didn't look into the 'why doesn't it work' and the book is not helping at all on this topic. It has some statements, but there's no help in them. Btw, the Theme Editor is in the LWUIT distribution, not in the JavaME SDK 3.0 so don't look for it there. There's also a webstart version on the LWUIT site.
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.


Tuesday, September 22, 2009

Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 03 - first uses]


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.


Monday, September 14, 2009

Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 02 - initial feelings]


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.


Friday, September 11, 2009

Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 01 - context]


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.


Monday, August 31, 2009

Review of "LWUIT 1.1 for Java ME Developers" by Packt Publishing [part 0]


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
  1. A comprehensive book review on LWUIT
  2. 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


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.


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.


Wednesday, August 05, 2009

NetBeans 6.8 M1... first issue right after starting up


Thrilled after installing M1 of NB68 I fired it up and the first dialog was a disappointment. It didn't see that I have a NB67 installation, instead it asked if it was okay to import the settings of my NB65 installation. Bummer.

I reverted back to NB671 and will give NB68M1 a second try later today. Recreating all settings myself and will file a bug on it.


Monday, July 27, 2009

Why Netbeans rules Glassfish... racing got me to this conclusion


Last weekend I ran into this race-condition on the server side of our game IFF (plug: http://www.sticktailgames.com:8080/IFFMobile/). I was stress testing the server and what do you know, all crumbled into a pile of rubbish as soon as, dare I say, more than one person at a time registered for the game. Now I do have made some short-cuts in the server code to circumvent some code because I want to test a lot, and don't want to have to wait if I don't have to. So entering an activation code on your mobile was taken out of the equation. Anyway, the problem is there and since I do expect some time in the future that two or more people register at the same time, I wanted this to be solved.
As it turned out, there was a race-condition; two processes were fighting for the same record in the database and that turned into an inconsistent state of the data. And since inconsistency in the database is worse than a crashing system that at least is consistent so I can start it up again... It turned out that this little piece of concurrency could be turned into a little piece of sequency and all would work out really nice. So how do you control this? I thought about using a queue to list the requests for a unique record in the database. Since the requests would be handled sequentially I would be out of the woods. A message queue is easily created and NB created all code, including the creation of the server resources for my MDB, queue etc.

Proper code generation is sooooo convenient.

But I needed to revert a lot of code this weekend to a state prior to the weekend, and that included my messaging stuff. Turns out, the resources NB generated in Glassfish v2.1 didn't want to move. Every attempt to delete them turned into an error message, stating that the resource could not be deleted as it was used in server server.

From the GF output in NB: Validation error: [ADMVAL1052: Element connector resource 'jms/iffBaseGenerationTopicFactory' can not be deleted because it is referenced from server 'server']

Not from NB nor from Glassfish' own admin console I couldn't delete the created ConnectionFactory. I had to open domains/domain1/config/domain.xml and delete the lines referring to my ConnectionFactory.

Once I found out how to remove the JMS resources I could get back on track. Now I'm back at solving my race-condition. Still thinkering on how to handle this. Probably I need to ensure that there'll be only one connection possible to the queue. So only one MDB can access the queue and handle the message. Any other approaches are appreciated in the comments of this post.


Tuesday, July 21, 2009

JavaME in NB 6.7

NetBeans 6.7 has been out in the wild for a while now and... well and then there's the JavaME stuff, which is kinda important to me since we're developing mobile games (we = Sticktail Games). JavaME SDK 3.0 is finally out the door and pre-packaged with NB 6.7, but still no support on other platforms than Windows. Which until last Christmas wasn't a big deal, but I got a MacBook 13" from misses Santa and would've liked native support for all my tooling... bummer. I'll have to invest in some VirtualBox stuff to get the ME parts running. Any tutorial to get this going is appreciated, but please JavaME SDK 3.0 Team: Get the other platforms done as well. PLEASE.

There's another gripe with the new tooling: I can't open my NB mobility projects in the SDK tooling, since the NB libraries for SVG and others aren't included in it. And there's no easy way to get those libraries in. Major bummer in my opinion, especially since the SDK 3.0 tooling supports for example the WURFL database. Which is nowhere to be found in NB 6.7 although the SDK 3.0 is included and supported as the default emulator, replacing the WTK.

While using the SDK I ran a couple of times in the issue that there wasn't enough memory for my MIDlet suite to be installed, although it installed nicely in the WTK 2.5.2 emulator. And there's no option to increase the size of the emulators heap.

But all in all, the new tooling is superb. Debugging is going a lot smoother now and especially the hot-deploy support is excellent. A real time saver. But ultimately nothing beats testing on an actual device, and the promise of better on-device-debugging support is great. Now we just need to get it working. In a usable fashion. So:

Nokia, Sony-Ericsson, Samsung, LG, HTC and all of you other vendors, please work on this. As long as you're putting in those nasty bugs in your JavaME implementation, we need to test on your devices. I'm okay in getting some different phones to test on, but help me out here as well.


It's been a while, we're now at 6.7


It's been a while since I've been posting about NetBeans, all kinds of reasons, but mainly because I just couldn't give blogging enough priority. But today I've got some spare minutes.

NetBeans has been growing tremendously since the last time I blogged about it, we're now at 6.7.

I think last time I was blogging about NetBeans I was working on a game, for mobiles. I should check my posts... anyway, what I can tell you is that other than previous experiences with new versions of NB, I've been able to open the project in new versions, even daily builds without experiencing major incompatibilities. Once or twice I wasn't able to also open the project in the old version again. This is of course a major achievement but more over, it makes testing NetBeans a better experience.

So what else are some highlights:
- When uninstalling, there now is an option to also uninstall the userdir. Excellent.
- UML support is about to be dropped, at least it's no longer maintained according the WIKI. Boooh
-The GF2.1 installation from previous versions of NB is no longer recognized and you'll be asked to install a new version. When not selecting to do so, NB does see your old installation and it all works. Confusing
- Woodstock is dropped (JSF components that at least look decent) and is (going to be) replaced by IceFaces. Mildly boooh.