A couple of great sample SW programs!

Well, I've only had a couple of hours to spend on this recently, but it has turned out very profitable! I did a little reading of the GUI tutorial and it gave me a little information, but not much perspective.

I knew that wasn't really going to get me to the point I could write some programs, so I continued the hunt by looking for a sample program that I might be able to understand. Bingo!

Here are two great ones: Unit Converter and Mastermind, both by Martin Maier. And both have source code available on the Superwaba.org site (you will be redirected, but that will get you there). Look for sample applications. There's a pretty long list, so you might find some other great ones also, but this is a nice start.

Unit converter is just one class. I suspect that sort of thing is pretty common with SuperWaba. Most simple programs are probably going to be an odd mix of procedural coding and OO language. But on the PDA, you really want to keep the class count down to save memory, and probably the interface and activities of an app will usually be pretty simple. In other words, you probably don't start coding most small SuperWaba apps by using Rational Rose to create all the UML diagrams. Of course, I might be wrong, especially for larger programs, because I'm just basing this on a feel from two tiny programs.

The MasterMind program does a lot of graphics stuff for the board and peg/hole locations. It handles color and black and white PDAs, and even compensates with a scaleFactor of 1 or 2 for hires/normal res screens. I don't really expect to worry about all that with what I'm doing for fun, but it's good to see one way it can be handled.

I don't know if Martin is a typical coder with great style or not, but he sure has helped me to see how SuperWaba programs can work. Here's a few highlights that may help you read through the Unit Converter code...

* You always start a program in a class that extends MainWindow. There are several main pieces that make up the program.

The static class stuff is first. It contains things like the string arrays with menu options, some base members/variables, and the fixed specifics that control the conversion stuff. This area is for things that don't require object instances and are global in nature for that class. I'm not too sure yet how best to distinguish in the "grey" areas between static and instance variables, but I'm sure that will come with practice. It was usually pretty obvious when I was doing the old persistence coding in ages past, but I don't even remember what sort of criteria I used back then. At any rate, you can look at the listing and get an idea of what Martin puts there.

Next is the default constructor for that main program class which is called first by the VM when the program starts. You can set up all your main window parameters and features like the menu bar and frame type and choose PalmOS style (as opposed to PPC style). He also prepares a couple of messageBox items for use later. DoubleBuffer true is, I think, a setting that provides additional screen buffering to smooth out the display so it doesn't flicker.

Then comes the onStart method. This is called after the main constructor. Apparently it matters what goes in the constructor vs the onStart method when running as an applet, but that really isn't a concern for me. This is the likely location for all the controls to be set up on the window. The tutorial seems to be an ideal reference for the GUI controls, but I can't say for sure because I'm just getting started. To be honest, the GUI tutorial really looks more like a manual to me, but that's probably a good thing.

Note that methods starting with "on" are methods that serve a standard function for the object, but are intended to be overwritten by the programmer. In the onStart, it contains stuff that happens at the start of the program after the main program window constructor.

In MasterMind, a graphics object is created because all the drawing happens by calling methods in a graphics object. Seems to be tied to the window that it's drawing in, but I'm not sure about all that. If you are drawing within an onPaint method (which is where you put instructions for repainting a window), you will have a graphics object already because it is being passed as an argument to onPaint. If you are drawing (e.g. lines or shapes) outside of onPaint, you'll need to create a new graphics instance.

onStart seems to put everything on the Unit Converter screen, and is actually pretty easy to follow, I think, for anyone who has written code in any 3G language like C, Fortran, Basic, Java, etc. (I guess that's 3G. I think case tools were supposed to be 4G, but that never really eliminated regular programming, so I'm not really sure what the G's stand for now. Maybe IDEs are like 4G?? Maybe someone out there can clarify for me.)

The last important section is the event handling piece in the onEvent method. (If you're new to Java, methods are like procedures or functions that are associated with the class, and contained/defined in the class along with the variables.)

You can see that he names the controls by starting with an abbreviation for the type of control and then a descriptive name. E.g. lblResultValue is a label that has the result value text label in it. And lbDestination is the destination list box control. Etc.

You interact with these controls by calling methods on them (by putting a period after the name, and then the method call with parameters.)

The events are event objects. When an event happens, the VM calls the onEvent method, passing an event object that contains all the info about the event, and you provide the code for onEvent to figure out what to do based on what happened.

You can look again at the code and see that if something was PRESSED, it is handled based on the case. If it was a press of the calculate button (determined by the control indicated by event.target), it does the calculation and shows the result. If it was the drop down box for a new choice of datatype, then it resets the listbox to have the appropriate values for that kind of data. If it was the list box on the left (source) side, or the list box on the right (destination) side, it resets the label below to match that unit of measure.

The only thing that doesn't make a lot of sense to me is the last part with the menu. It falls under an event.type == ControlEvent.WINDOW_CLOSED. I would have thought that window closed means end the program, so I don't know why menu choices fall under there. They seem like they should exist a level up with the other stuff. But for some reason they are handled under "window closed" event types. Maybe that's just a SW thing that you take as an assumption? Or maybe it's a Java thing? I just don't know, but I imagine I'll find out in time. It's most probably in the GUI tutorial somewhere.

So that's our update for tonight. Took almost as long to write it as to review the code!
I'd tell you what's next, but I have to think about it first. Might be a while because I have a lot going on, but don't worry... I'll be back fairly soon. Thanks for reading!

P.S. I'd love a comment if anyone finds this interesting, or has any tips for me!