Journey into SuperWaba

Ever wonder what it takes to write programs for your PDA? I did, and so now I am beginning a journey to try my hand at writing something for the PalmOS. SuperWaba, a variation of Java for the PDA, is my language of choice. And I'm a novice, which makes it all the more unpredictable. Hope you'll come along for the ride! Note: You can read multiple posts on one page if you click on an archive link.

Monday, August 30, 2004

Time to Try A New Approach to the Game

Well, last nite I finally got the chance to continue on my SuperWaba journey by trying to turn the program shell with components into a HiLo program. I didn't get it quite working. Very, very close I think, but am getting fatal error. But as I have discovered that code is probably not the best way to run the program anyway, I'll start over rather than try to fix it.

Lesson #1: Keep things "entirely" event-driven.
Using the main game logic as a do loop is not the best way to handle event-driven programming. In fact, I believe it's just plain wrong. For one thing, it messes up the logic for game ending, aborting, restarting etc. Instead, it makes more sense to maintain status of the game at all times, and then determine what to do based on that status and the new even to be handled. Probably should have realized that from the start. Seems so obvious to me now.

Lesson #2: Dialogs and popups and menus are sub-classes of Window, which is a subclass of Container. That means that you really can't do those elements directly from a container unless it is a Window (e.g. a MainWindow). Of course a MainWindow has other problems with popupBlockingModal() as we saw before.
This indicates to me that all the window related elements need to be either be handled from logic in the main window or from logic in the container, but making use of the main window. There are MainWindow.getMainWindow() functions, or something close to that, which makes that window available for use from a container, so I think it might work from code in a container, but not sure yet.

Open Question #1: Where does the event logic handling go?
Guessed Answer: My best guess right now is that it goes where the controls are. If it's a container with screen elements, then that container probabaly needs to handle the response to the element events, passing it on to the window only when it falls outside the realm of what that container does. This would preserve some sense of encapsulation, which is supposed to be important in Java/OO coding, and it seems to make sense.
An alternative might be to pass all events to the main window and handle them there, but that doesn't seem appropriate.

So my next step is to try to rewrite the HiLo game based on these principles and lessons to see if it makes more sense that way. I suppose I should probably be looking at more sample code to get ideas, but to be honest it just seems to take too long to figure out if the program is even relevant to what I'm doing before I even start to understand the code and why it was written that way. So it might be a good thing to do, but for right now while I still feel like I have a viable path to follow I'll continue to reinvent the wheel on my own. Seem more fun and quicker for now.

BTW, I'm adding my email address in the intro now, but replacing @ with "AT" to reduce spam. Please feel free to contact me.

Until next time, take care!


Post a Comment

<< Home