Journey into SuperWaba

SIgning Off For Now

2004-10-16T01:19:00.000-04:00

Well, if anyone has been following this blog, they realize that I've been away for a while. A matter of priorities. This forum is not forgotten, but just neglected.

As a result, I'm going to have to call it a day, but with the possibility that I'll jump back in sometime in the future.

There have been a few circumstances and decisions that have affected my decision.
1) In frustration with the wait for a PalmOS product that I really feel good about buying (and the serious bugs and complaints about the T5), I made the decision to buy a Toshiba e405. I got a reconditioned one for $150. It's not exactly the most full-featured and powerful PPC out there, but it's a chance for me to take a look at this mysterious (to me) PPC world and find out what it's like. In the meantime, PalmSource and PalmOne can hopefully get their act together and I'll be back later. (Assuming I don't become too enamoured with PPC, of course.)
2) I've decided that my "nuts and bolts" techie days are over, except if and when necessary at work, which is rarer and rarer these days for me. As a result, Java/SuperWaba are really not the best languages for me to develop in if I have a simple project. Something like NSBasic probably makes much more sense, if I ever get the time, need or desire to pursue it more. Don't know what's available in the PPC world yet for easy and inexpensive development, but I'm sure I'll figure that out in time.
3) I haven't gotten much feedback, and my site hit monitoring has stopped working. No sense in figuring out another system to measure visits at this point. Don't really have any idea if anyone is even reading this at all, or getting anything out of it.
My hope is that just sitting around in it's current form will be useful to newbies occassionally. For that purpose, I'll leave it up as long as blogger.com accomodates.
4) I've got a lot of time to waste getting acquanted with my new Toshiba after it arrives, so there's no point in trying to program right now.
and Finally
#5) SuperWaba has had a new version released, with more to come including a GUI builder. Nice, I'm sure, but more to learn.

Final conclusion,
Programming on the Palm is a bit of a challenge, especially if you want to do "real" programming. With Basic, it seems pretty reasonable, but any programming takes time. And especially if you are using a GUI or interfacing to just about anything. It can be worth it to some, but not to a dabbler like me until I have a real need for a program that is not available unless I write it. (Even then, I might put a bid out on one of those rent-a-programmer sites.)

I think SuperWaba is definitely worth a look for serious programming if you know Java syntax, and are willing to dig in patiently even when there is basically no support except for the very limited help for newbies in the forum or web site.

NSBasic or C coding probably makes more sense for the serious programmer. And the hobbiest will like something like NSBasic, iziBasic, tiny basic, etc.

One of these days something easy will come out that can handle serious code and performance requirements also.

Thanks to everyone/anyone that actually visited and read this blog. If you do visit and enjoyed it, please do say hi to me at bobr[AT]mobileread.com (convert to a real email address by changing "[AT]" to "@". I used that to avoid some spam.

God bless. Goodbye!

Time to Try A New Approach to the Game

2004-08-30T23:44:00.000-04:00

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!

Off Topic: SuperWaba is on my ToDo List!

2004-08-25T23:16:00.000-04:00

Just a quick update to let anyone following this blog that I still plan to continue. But between being short-staffed at work and having way too much going on outside of work, there just isn't enough time. In fact, as a fan of David Allen's "Geting Things Done" book, I'm going to spend some time getting things back in order, re-evaluating my priorities, and cleaning out everything that's not important which is sucking up all my time.

As a Christian, I want to approach this like every other search for wisdom about a topic in life... I plan to pray about it. I have to confess that I've let my prayer life slip recently. I've let my heart be distracted by everything from programming to work to sports to whatever. At first, that seems to work fine. But as my time with God fades, my tenderness of heart towards God fades, and prayer becomes difficult. It seems like God is so distant. And then I notice that I've lost that sense of being carried thru each day by His help. And, unfortunately for those around me, I don't have as much patience or peacefulness, so I'm pretty sure I'm harder to deal with. So everyone that knows me should encourage me to pray more... even if you don't believe in God! (yes, sorry, the topic of God is going to come up every now and then. can't help it because it does affect everything i do in one way or another. or at least my goal is for it to affect everything i do!)

Anyway, I don't expect SW to drop off my list. I might spend less time on it, but programming in some form is too important to me right now. And SW is the method, for now at least. Of course with the time constraint and the SW difficulties, I may head to NSBasic not too long from now! In fact, I saw a web page the other day with a bunch of Hello World programs for Palm in languages like an on-board C compiler (the name of which I should know but can't remember right now), a version of pascal, HotPaw basic, iziBasic, SuperWaba, etc. It made me think back on that previous posting about why things are so difficult. Some Hello World programs were just a few simple lines. Others, like the onboard C, were really complicated. Granted, they can probably be generated by an IDE wizard, but gee whiz, that's rediculous! One of these days the hardware will be fast enough that typical functions won't have to be optimized very much to get a responsive GUI, and the code can be simplified.

Program Shell for New HiLo Game Version

2004-08-19T21:43:00.000-04:00

Here's the shell of the new version I'm working on. Three classes this time!
Formatting (tabs) is lost when I post so it's a little hard to read. Anyone know how to avoid that?
There is also some remnants left from the first version of HiLo in the guessing logic. It's only there as a start for me when I add guessing functionality. The point of this code is just to get the container stuff working.

==================
import waba.ui.*;
import waba.fx.*;
import waba.util.Random;
import waba.sys.Convert;

public class HiLoGame extends MainWindow {

public static WelcomeWindow welcomeWindow;
public static GameWindow gameWindow;
MessageBox mbAbout;
public static Graphics g;
MenuBar mbar;

public HiLoGame() {
// Do generic housekeeping to get started
highResPrepared = true;
waba.sys.Settings.setPalmOSStyle(true);
g = new Graphics(this);
setDoubleBuffer(true);
// Set up this programs overall window
// Could probably replace with:
// super("HiLo Guessing Game",TAB_ONLY_BORDER);
setBorderStyle(TAB_ONLY_BORDER);
setTitle("HiLo Guessing Game");
// Prepare this for use in the about menu item
mbAbout = new MessageBox("BobSoft",
"This is Bob's HiLo Guessing Game on Palm!|Enjoy..." );
}

public void onStart() {
// gameWindow is the screen where the game is played
gameWindow = new GameWindow();
//Show the welcome window on startup
welcomeWindow = new WelcomeWindow();
swap(welcomeWindow);

// Setup a menubar
String menu[][] =
{
{"File", "NewGame", "*Options","*HiScores","Exit"},
{"Help","About", "*Test"}
};
mbar = new MenuBar(menu);
setMenuBar(mbar);
}

public void onEvent(Event event) {
switch (event.type)
{
case ControlEvent.WINDOW_CLOSED:
String sel = null;
if (event.target == mbar)
switch (mbar.getSelectedMenuItem())
{
case -1: break; // no item selected
case 101: popupModal(mbAbout); break;
case 102: break;
case 001: /*end game*/ //playGame();
setTitle("HiLo Guessing Game");
break;
case 004: exit(0); break; // End Program
}
}
}

public void onPaint(Graphics g) {

}
}
=================

/** Container class to handle the welcome screen
*/

import waba.fx.*;
import waba.sys.*;
import waba.util.*;
import waba.ui.*;

public class WelcomeWindow extends Container {
Button exitBtn, beginBtn;

public WelcomeWindow()
{
setBorderStyle(BORDER_LOWERED);
}

public void onStart()
{
add(new Label("Welcome|to|HiLo Game|by|BobSoft"),CENTER,CENTER);
add(exitBtn = new Button("Exit Program"), RIGHT,BOTTOM-5);
add(beginBtn = new Button("Begin Game"), LEFT,BOTTOM-5);
}

public void onEvent(Event event)
{
if (event.type == ControlEvent.PRESSED)
{
if (event.target == beginBtn)
{
MainWindow.getMainWindow().swap(HiLoGame.gameWindow);
}
else if (event.target == exitBtn)
MainWindow.getMainWindow().exit(0);
}
}
}

===================

/** Container class to handle the game playing screen
*/

import waba.fx.*;
import waba.sys.*;
import waba.util.*;
import waba.ui.*;

public class GameWindow extends Container {
Button exitBtn, beginBtn;
String guessDialogButtons[] = {"Guess", "Abort Game"};
InputDialog getGuess;
int target, guess, guessNbr;
int guessCnt;
String resultText, promptText;
Random randomObject;

public GameWindow()
{
setBorderStyle(BORDER_LOWERED);
randomObject = new Random();
}

public void initNewGame() {
target = randomObject.rand(1,100);
guessCnt = 1;
guess = 0;
promptText = "Enter Guess #"+guessCnt+":";
HiLoGame.g.clearScreen();
};

public void playGame() {
initNewGame();
resultText = "This is your first guess.";
do {
getGuess = new InputDialog(resultText, promptText, "", guessDialogButtons);
//popupBlockingModal(getGuess);
guess = Convert.toInt(getGuess.getValue());
resultText = "Your last guess of ("+guess+") was "+calcGuessResult();
guessCnt++;
promptText = "Enter Guess #"+guessCnt+":";
}
while (getGuess.getPressedButtonIndex()==0);
}

public String calcGuessResult() {
String result;
if (guess > target) result = new String("too high.");
else if (guess < target) result = new String("too low.");
else { result = new String("correct on "+guessCnt+" tries!");
initNewGame(); guessCnt = 0;
promptText = "Starting new game... " + promptText;
}
return result;
}

public void onStart()
{
add(new Label("Play Game Here!"),CENTER,CENTER);
add(exitBtn = new Button("Exit Game"), RIGHT,BOTTOM-5);
add(beginBtn = new Button("Begin Game"), LEFT,BOTTOM-5);
}

public void newGame()
{
//Set everything to newGame status and reset the screen widgets
}

public void onEvent(Event event)
{
if (event.type == ControlEvent.PRESSED)
{
if (event.target == beginBtn)
newGame();
else if (event.target == exitBtn)
MainWindow.getMainWindow().exit(0);
}
}
}

============================

Another Way to Code the HiLo Game

2004-08-19T21:31:00.000-04:00

After running into the problems with popupBlockingModal() in the main window constructor and main window onStart() method, I started looking further into the alternate way of handling screen contents.

The basic idea (see the sample code for ContainerSwitch included with the SuperWaba download) is that you can extend the Container class with your class that sort of reflects one screen of activity and controls for your program.

Think of the hilo game. You might have a welcome screen and a main activity screen. You can code this as one class for each screen, where the classes extend Container. Then you can swap back and forth from the MainWindow to make whichever container class current and visible. Actually, visible is different than current, but if you use the Window.swap() method, the window you swap into place becomes visible automatically.

Note also that you can always reference the MainWindow with the static method:
MainWindow.getMainWindow()

In my code, I have three classes. I chose not to try to let the main program class contain any screen contents. Those were all done via separate classes that are extentions of Container. This is slightly different from the ContainerSwitch sample code which puts controls on the main window and swaps other containers in and out from there. I suppose I could have done something like that and saved a Class, but for now I wanted to do what was easier for me to keep in my head.

I've also used public static members for the main window class. If you are an expert in Java and SuperWaba, I'm sure my code makes it really obvious that I'm not comfortable with scope and encapsulation yet, especially in this new sort of GUI/event world I'm exploring. But hopefully that will become clearer to me and cleaner in the code as time passes.

As long posts gave me a problem before, I'll use a separate post for the code I've got so far with containers representing screens. There's absolutely no functioning guessing code for the guts of the game, but that shouldn't be too hard to add after the fact.

See ya!

Code for a simple HiLo Game in SuperWaba

2004-08-15T20:18:00.000-04:00

Here's the promised code. Seems that Blogger doesn't either doesn't like to publish from the FireFox browser, or the original post was too long with the code included.
Sorry about the formatting.... it just doesn't seem to keep track of the indents once it gets published.

===============================
import waba.ui.*;
import waba.fx.*;
import waba.util.Random;
import waba.sys.Convert;

public class HiLoGame extends MainWindow {

MenuBar mbar;
String menu[][] = {
{"File", "NewGame", "*Options","*HiScores","Exit"},
{"Help","About", "*Test"}
};
String guessDialogButtons[] = {"Guess", "Abort Game"};
MessageBox mbAbout;
InputDialog getGuess;
Graphics g;
int target, guess, guessNbr;
int guessCnt;
String resultText, promptText;
Random randomObject;

public HiLoGame() {
highResPrepared = true;
randomObject = new Random();
g = new Graphics(this);
setDoubleBuffer(true);
setBorderStyle(TAB_ONLY_BORDER);
setTitle("HiLo Guessing Game");
mbar = new MenuBar(menu);
setMenuBar(mbar);
mbAbout = new MessageBox("BobSoft",
"Welcome to Bob's HiLo Guessing Game on Palm!|Enjoy..." ); }

public void playGame() {
initNewGame();
resultText = "This is your first guess.";
do {
getGuess = new InputDialog(resultText, promptText, "", guessDialogButtons);
popupBlockingModal(getGuess);
guess = Convert.toInt(getGuess.getValue());
resultText = "Your last guess of ("+guess+") was "+calcGuessResult();
guessCnt++;
promptText = "Enter Guess #"+guessCnt+":";
}
while (getGuess.getPressedButtonIndex()==0);
}

public String calcGuessResult() {
String result;
if (guess > target) result = new String("too high.");
else if (guess < target) result = new String("too low.");
else { result = new String("correct on "+guessCnt+" tries!");
initNewGame(); guessCnt = 0;
promptText = "Starting new game... " + promptText;
}
return result;
}

public void initNewGame() {
target = randomObject.rand(1,100);
guessCnt = 1;
guess = 0;
promptText = "Enter Guess #"+guessCnt+":";
g.clearScreen();
};

public void onStart() {
}

public void onEvent(Event event) {
switch (event.type)
{
case ControlEvent.WINDOW_CLOSED:
String sel = null;
if (event.target == mbar)
switch (mbar.getSelectedMenuItem())
{
case -1: break; // no item selected
case 101: popupModal(mbAbout); break;
case 102: break;
case 001: /*end game*/ playGame();
setTitle("HiLo Guessing Game");
break;
case 004: exit(0); break; // End Program
}
}
}

public void onPaint(Graphics g) {

}

}

===============================

First Simple SuperWaba Program Complete!!!!

2004-08-15T19:31:00.005-04:00

YIPPEE!!!!!!

It's been a long, long road. But finally a success. It's not much to look at, but it is a real live SuperWaba program that does something more than say "HELLO WORLD!"

Below you will find the code for a simple HiLo game along the lines of the description in the previous post. None of the bells and whistles are implemented. I don't honestly know if I'll take this any further, but for today I'm happy.

TRANSLATION: "I'm tired, and the next steps look just as hard as the previous steps, and I'm uncertain about continued success. But I'm too hooked on the adventure to stop now."

I'm a little embarrased because the code is not exactly simple and organized. But I'm also proud of it because of the simple fact that it works, and it took some work to get there. What you see is more remnants of false starts than a creation done with a single effort. In other words, it's the code equivalent of a screen door thats held together with more duck tape than screen material.

And bottom line is that I feel now like I have finished my original mission for this blog... to write a simple program in SuperWaba, and capture the journey so that others can follow with the advantage of my trials and tribulations. This blog may be wordy, but I sure wish that I had had something like this available when I started out!

LESSONS AND TRICKS: Any success like this leaves behind it a trail of lessons. Here's a few that are still fresh in my mind...
1) As noted before, you can't use a popupBlockingModal to display a MessageBox or InputDialog from the main window constructor. That is because the event handler has not been set up yet, so the program just hangs. There is a workaround posted on the FAQs, but I didn't understand how to use it, and it even seems to refer to classes that don't exist. My workaround was to move the game play code that needs popupBlockingModal into the even handler for menu items. In other words, you start a game only from a menu item. That guarantees that the event handler has already been set up.
2) There's a lot of goofy code. E.g. The whole initialization of a new game is a bit bogus and confusing because it can happen in multiple places in different manners, but it works. And the counter handling is a bit goofy also.
3) When a game finished the title bar completely disappears, so it is added again after completing a game. You can abort a game by pressing that button.
4) Custom buttons can be chosen in InputDialog by adding a String array with all the button labels in it as a 4th parameter in the constructor. When looking for the results you use getPressedButtonIndex() and compare it to the button number starting with 0. The edit text entered is found with getValue().
5) You need to use the Convert class to do basic type conversions. For example, when converting from String to int, I had to use Convert.toInt(String) instead of the Java function Integer.parseInt(String).
6) SuperWaba is NOT Java. It didn't really sink into my head how much SuperWaba is not Java until I wrote this code. It really isn't Java. There are some similarities, and the syntax is the same, but all the libraries are different. You have to learn them just like you had to learn Java libraries. And with SuperWaba there's more issues because it's more limited and because you're programming for a very limited device. This is certainly a limitation, but hey it's an open source language that is just getting started. I suspect that if it flourishes, we may find it to become more and more powerful and robust.
7) Programming isn't a whole lot easier with SuperWaba than it was with assembly coding with my Z80, or doing BASIC or Pascal. Well, yes, it is a bit nicer. But only a bit. I'm not sure whether it's because I'm not used to GUI programming or because I haven't really done real programming in so long, or because I'm just not spending the time it deserves because I'm so busy. But it's really a pain to make things work right now! Like I said before, things do get easier when you do them often and are familiar with how to go about it. Then you can concentrate more on what you are trying to accomplish rather than the elementary stuff. I still hear that call of NSBasic ringing in my ear. But hey, I already spent some big bucks on the SuperWaba tutorials (which seem more like manuals to me) so maybe I'll stick with it for a while as time allows. If I get really frustrated, I'll see if the alternative is better or worse!

Take care.
Below are some additional ideas on what a HiLo Game could include, and on my next blog post the code for my first simple program. I wanted to include it here, but seems I'm out of blog space. Hope that means this post is too long and not that the entire blog is full. That would be crazy to have happened so fast.
And as always, for those trying to learn SuperWaba, good luck!

Further ideas on HiLo gaming:
* I'm thinking now of more things that you could do with hilo guessing games. Like make it 2-d or 3-d and try to corral various animated items that prefer to escape. Once you start looking at that, it could expand into various terrains, and all kinds of special devices to gain advantage either on the hunter or the escapee side of things. AI is another possiblity instead of the target being completely random. And multiple targets could figure in. I'm sure I can come up with many more ideas than I'm willing to program!

A Couple of SuperWaba "Gotchas"

2004-08-14T22:15:00.000-04:00

As promised, here is some further information about some of the problems I ran into when trying to code a HiLo Guessing game.

1) Like with every new language learned, I'm spending a lot of time trying to "get my bearings" and figure out what pieces available, what are needed and what goes where, etc.
2) The popupBlockingModal() command, used to display a message box or input dialog cannot be used in the main constructor or the onStart() method of the Main Window. The workaround is probably clear to a Java-whiz, or to a pro with SuperWaba, but to me it is going to take a little more study to understand how to make it work.

The approach I decided on for my first attempt at a simple HiLo game was to put things like "New Game" in the menu, and the constructor would hold most of the generic setup, and a playGame() method would intialize the game members (variables), which are basically all going to be static. That means that regardless of where they are referred to within this single class program, they are the same variable. It is implemented that way by defining the static variable in the class definition before the contructor method. Then, I think, even if a new object is created and assigned to that static variable from inside of a method, the object value of the variable is available anywhere in any method of the class. (Note: Upon reflection, static variables were not needed, just the location of the variable definitions outside the methods of the class, so it's accessible anywhere inside the object. Doesn't really matter for this app, I think, whether they are static or not.)

My plan was to handle the main game activity by a series of InputDialog boxes. A new one pops up every time a guess is entered. It contains text that indicates what the last guess was, how many guesses have been made, and whether the last guess was too high, too low or correct.

The user then has the choice to enter a new guess or abort the game. If the guess was correct, a new secret number is selected and the first guess is requested. If the user is done, he just the abort button.

Note: This technique of handling game endings is one way to make a simple game addictive. If the next game is already started up, it "invites" you to continue one more time rather than abort. It's especially enticing if there is some sort of cumulative scoring that includes multiple games. I noticed this first when playing a solitaire game that's set up this way. It was hard to put down. Eventually, after leaving permanent marks on my touch screen and wasting way too many hours playing, I was forced to remove it from my Palm!

BTW, I have all kinds of ideas for future versions if I don't get fed up with SuperWaba first. For example:
*) Allow guessing with alphanumeric guesses and using lexicographical ordering
*) Allow guessing numbers in different bases, such as hexadecimal
*) Allow random movement of the secret target between each guess, and with specified ranges and probabilities.
*) A progress bar that graphically indicates the min/max values, and the remaining hi-lo range of possible target values based on previous guesses and potential movement of the target.

I think this makes for an interesting programming exercise that would include some graphics, but isn't really going to require too much out of me.

An aside: To be honest, all the overhead required to do simple things is making me a little less thrilled with SuperWaba as a hobby language. I'm sure it's speed and power is an advantage relative to alternatives like NSBasic, but as someone with little spare time, it just doesn't seem like the best choice for me right now. In High School, this would have been the ultimate joy, especially compared to the languages and computer hardware that was available to me at the time. But in those days I had the luxury of devoting a lot of time on these things. Currently, I have to be careful with my time, and am already using too much of it on this! But like I keep saying, time will tell. Sometimes things that sound hard at first turn out to be pretty simple once you learn what you're doing. Especially if you are using something all the time.

Have I mentioned recently that I really appreciate Daniel Tauschke's MobileCreator IDE? It's great! While it may make sense to switch to the open source Eclipse IDE (it's well-known in the Java world also, so it might be something with more general application), I really like the integration and simplicity that MobileCreator provides. And I appreciate his making it available in a free starter version appropriate for hobbiests. If I were to ever get serious with SuperWaba, I'd have to consider his professional version very seriously just because I like his product and would like to support his work. And some really exciting news... he is apparently going to be adding a GUI builder into either his IDE or Eclipse. That's based on a newsgroup posting and not official yet, but I'm sure looking forward to seeing what he has coming!

So, anyway, now that you know my plan, let me briefly indicate the struggles so far. Number 1 is just as to be expected. New language, new issues, hard to tell how to go about doing some simple things. And often even after making these things work, it's hard to remember exactly what was involved because I got to the solution in such a roundabout and incremental way through trial and error.

Number 2 refers to something that is posted under the SuperWaba Wiki FAQs...
=====================
Question

Why does using popupBlockingModal() to show a MessageBox? in onStart() hang?

The window that you are trying to pop the MessageBox? up on top of is not ready yet.

To get round this, use a Container to hold the code that wishes to do a popupBlockingModal, and do Window.getTopMost().popupBlockingWindow() from within it. This will work in the onStart() method of the Container because you create the main Window before the Container is initialised. This is an example of the use of Swap to load a container from a main Window class:

   public void onStart() {

     /* Now we get our client rect, excluding the border and the title */

     Rect r = getClientRect();

     /* Prepare the splash screen. */

     splash=new SplashScreen();   // A Container

     splash.setRect(r);

     /* Swap in the SplashScreen module. */

     swap(splash);



  }

=====================

I'm not exactly sure how I'm going to make this work yet, so there's some more experimentation and learning to do. That one-hour iziBasic program I wrote keeps running though my mind... it was so easy!

Hope to have some answers next time, or at least a workaround.
Until then, if you are trying SuperWaba yourself, good luck.
And if you're a SuperWaba expert, how about some help in the comment section?!

As my some of my online associates say... Cheers!

Ed: Is So Much Programming Complexity Necessary?

2004-08-14T10:17:00.000-04:00

Well, it's time for an update. Unfortunately, it's not going to be the update I hoped for.
Granted, I haven't had a lot of time to spend on this. But, still, I thought I was going to proudly announce this week that I have written a simple HiLo guessing game on my Palm in SuperWaba. Instead I'm writing this additional editorial, and the next post will describe some of my issues.

In less than an hour, and right on my Palm device, I was able to write something of about the same complexity as a HiLo game in iziBasic, and using part of the GUI interface to do it (as opposed to doing it as a command line program).

One conclusion... something like NSBasic must be much easier than what I'm trying to do with SuperWaba. And with NSBasic, it would be a commercial product so I could get support. When I come up with all kinds of problems with SuperWaba, there's really not a lot I can do. I am reluctant to post to the bulletin board unless I've really worked on it and it's a "significant" and well-thought out question. They seem a bit stuffy on the whole. Probably because everyone is treating it like "serious" business and they don't have time for beginners. I think they need to consider a seperate group for beginners. I know it can lead to a lot of stupid questions, some of which will still get ignored. But at least it would provide a place for someone like me to have a shot at making things work without too much frustration, because others that have been through it before can help out. And, btw, if you take a look at support prices, you'll find that it's not exactly the sort of thing a hobbiest can afford.

One more negative feature of SuperWaba is that the GUI seems to be generally a little messy in appearance. I haven't looked at all the sample programs, and there are some elements of the GUI that do seem to look pretty nice. But my first impressions are that programs tend to look, well, really ugly.

So why do I want to continue this journey if it seems like the hard way? Well, for one thing, I want to get "over the hump" so I know how to do it even if I don't continue. For another thing, I like Java. I'm starting to wonder more every day why that's true, but there's something "clean" or "pure" about Java code compared to variations of C, Basic, Pascal, etc. What I'm starting to get tired of in Java is nagging SW difficulties in getting started, and the enormous overhead and complexity to do simple things.

Before I go on, let me indicate that I'm not so naive as to think programming is simple and it's only the technology that makes it hard. No. In fact I know that even defining the requirements is a tremendously challenging exercise. And I also have dug in to "hard" and "complex" items in coding. Including writing cross-assemblers, writing machine language code without an assembler, writing routines in Pascal on one of the early Macs to handle abstract algebraic manipuations of things you only see in advanced graduate mathematics. Etc. Etc. I know that things sometimes take work.

So what do I mean by this? Well, consider what it takes just to have a program shell that can be used to handle opening a main window, a menu bar and process events. I don't mean actually putting all the items in the menu and populating the window and capturing and handling all the specific events. I just mean the shell that has a place to do that stuff. Kind of like a scaffolding for your code. In my mind, it's not all that much more advanced than my old machine language and Fortran coding days. The syntax is simpler and the editors are better, and we now have an incredible advance with OO, but some things still seem to work in similar ways.

Now, granted, an IDE can do some of the work for you with wizards and tools. And if you are the organized type, you can even create a library of program shells. (If you are less organized, like me, you just keep a folder with some examples you previously worked with, and you do surgery on them until they look like what you are trying to do.)

But what a nuisance to keep having to place code in multiple places to add a menu item. Or to do a standard pop-up window. Or just about everything you do in Java! (Not too unlike most languages, I'm forced to admit.)

Is the technology of software development and programming languages/environments so immature that we haven't been able to handle something simpler? Or are the tool developers so used to doing this that they don't see it as something worth eliminating?

I saw a new technology the other day that started with an "A" I believe. It was a new way of creating software, supposedly. But you know how big claims are put on incremental technologies. Someone takes a very simple idea and all of a sudden they believe they have changed the fundamental nature of programming.

Well, as best I can tell, this technology, as it is currently implemented, is really a wrapper around every method in Java. As a result, it gives the coder the ability to change specs in those wrappers to do interesting things. For example, if you want to audit the flow of the program you can just change the wrapper once and it affects everything. Now you can see that with a little thought, there are other things that can be managed in more global way by handling it at the point of entry/exit from other code.

That's what comes to mind when I think of how you have to define a variable, create an object, look for certain events, etc. etc when adding a simple control to a Java program. You are doing a very specific thing with your program in terms of requrements and functionality, but Java forces the coder to artificially patch code into multiple places in the program. Yes, it gives a sense of flexibility -- you can create just about anything it seems like -- but what about the 80/20 rule. If you look at programs, I bet that the typical features of 80% of Java programs have very similar kinds of code and requirements. Shouldn't that be handled better?

Two approaches seem to have made some headway in this area. One is code generators that use UML class diagrams to get the code started. But realistically, I'm not sure how much time this saves. Another, which is much more effective, is the GUI builders in IDEs. But isn't it kind of rediculous to have all that translation work going on in the IDE? Why not let the programming language support the typical kinds of things a GUI builder has to handle. No, I don't mean the layout part. That's natural to keep that distinct from the language (I think). But what about all the other specifications. Once the GUI builder gets the layout, look at the messy code that has to be scattered all over once it's translated.

That's not very efficient in my mind, and it seems like there's a big gap between programming languages and the actual things we are usually trying to get programs to do. Languages should support the basic things better, and it shouldn't have to spread code all over to implement ONE concept. Why is the IDE doing all the work to simplify programming. Java took some small steps, and people jumped on board even though there wasn't really much help from IDEs in the early days for programmers in Java. Now the IDEs are catching up. If Fortran and COBOL were like Vodka, then maybe it's time to move from Java to Coke and find a simple way to program that can handle both the scattered code required now and helpful sometimes maybe for flexibility, and also handle translation of real requirements for simple functionality into ONE single change to the program! Back to the GUI thing... why is it so cryptic to do event handling? It's way too much work for simple tasks. Even adding a menu item and setting up a place to handle it. Experienced programmers probably don't care because the IDE does it or because they can do it in their sleep. But if you add up all the work and mind processing cycles spent on that same kind of artificial work across the whole development process, isn't that crazy? Kind of like how it makes you wonder why refactoring, as in changing a method name, has to be such a chore. Whether done by hand or by a tool, there's a lot of work and things to keep track of. Is it hard because it's just a hard concept, or because we haven't figured out how to reflect the simplicity in a development language and environment?

Okay, that's as far as I'm going to go with that. But to summarize... I don't think the simple programming tasks common to most programs should be so difficult and require code to be touched in so many places for a simple program element. But until I am a better programmer, and can come up with some answers, I guess it's just another complaint.

I'd also say, I'm losing my appreciation for SuperWaba in the sense it seems like it may not be a great choice for a hobbiest due to some of the complexity and issues and lack of support options. But I will press on and study some more examples and try some more smaller pieces of sample code and try to get things working. I may change my mind after I know more about this whole thing.

But in the back of my mind right now, I'm thinking... Just work on this enough to feel like you can do some basic stuff and write a hilo guessing game, and then try something a little more fun like NSBasic. Only time will tell!

OffTopic: iziBasic

2004-08-07T16:35:00.000-04:00

I was a bit frustrated the other day at the amount of time it's taking me to get going with SuperWaba. I'm making progress, so it's okay, but it seems like a lot of work just to get going.

As a diversion, since I have written console-style BASIC programs in the past, I thought I'd give iziBasic a try. I read through the simple manual and wrote a simple Hello World program that loops a few times and prints out "Hello World", then waits for you to tap a button to end. What is here in this post is an adaption of some info I posted previously to a 1src.com developers forum. (A nice Palm site to visit!)

All this took me about an hour to prepare and about 20 mins to write that first program and get it running (which I did while waiting at a doctor's office!) Couldn't have done that with SuperWaba. One of the reasons I could do that was iziBasic is an on-board compiler, and I had the manual and sample code on there for reference as well as the editor and compiler for the actual programming. You just edit a memo document or an uncompressed/unencrypted DOC file, and then you can compile and run the program. Works great!

A few things to note though:
1) It's much more simple and limited that SuperWaba, so it may be easy to get started, but you just can't do as much.
2) The free version is nice, but has some small limitations. First it uses a standard about screen saying it's written in iziBasic. Second, a few instructions are not available. I don't know which ones. The good thing is that it should give you time to make a real good trial before you have to pay. But if it works out that you'll use it, I hope you'll register and contribute to support the author.
3) The math parser is limited, so it does operations left to right instead of by arithmetic priority.
4) The language is simple and is a one-pass compiler, so there are some limitations as expected.

But the great thing is that it's easy, you can program on-board, it can be either console-based or use some simple GUI, and it compiles into a .prc program. I think this might be a good choice for the novice programmer trying to get started programming on a Palm PDA.

One more note. You have to name the source file appropriately for the compiler to find it. It can either be a memo or an uncompressed/unencrypted DOC file, but it MUST end with .ibas or it won't realize it's there. That's not in the documentation so it's a bit confusing.

All in all, this looks pretty promising.

Some new information:
* The parsing is very simple-minded, so you need to put line breaks at exactly the right place.
* You also need to assign values to variables a lot. For example, you can't do "IF a> b-c THEN..." Instead you have to set d=b-c and then to "IF a>d THEN...". Another example is that you can't do "A=MESSAGEBOX("This is the message.",1). Instead you have to do B$ = "This is the message." and then A=MESSAGEBOX(B$,1). In other words, many parameters must just be the variable, not a literal or a calculation.
* Variable names for strings and numbers are one letter only (so there are only 26 of each, and you cannot use multiple letter names. This means you have to write a list of variable names and their meaning to keep track. That's not very easy to do when you're programming on-board the Palm. This limitation is the only really serious one I see in iziBasic.) And there is only one array for strings and one for numbers. The first 26 values of the index in an array correspond to the variables A$-Z$ or A-Z, so if you want a bigger array, you put a DIM statement at the beginning of the program, and use the values bigger than 26. Yuk!

This is not enough for me to say iziBasic is no good. Actually it is pretty good except for the variable name limitations. It's an on-board BASIC, it does simple GUI, and it compiles to a runtime program file. For that maybe I'm willing to put up with some minor limitations in the parser.

If you are using iziBasic, let me know what you think, and what you're using it for!

A couple of great sample SW programs!

2004-08-03T21:47:00.000-04:00

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!

ED: Motion may slow down

2004-07-29T21:47:00.001-04:00

Oh no! I lost my blog again because when I published, I got a server error and then refresh and back didn't recover my typing. Memo to self: Save the blog contents before publishing!

Well in short summary form, here's what I said...

I'm tight on time, but mostly you are seeing the updates slow down because it's tough going. I'm having trouble getting my bearings. So far it's been pretty clear what to do or at least what to figure out. Now I'm floundering a bit. I either need to better understand the tutorial, or take a detour to write some Java as a refresher, or maybe find some relevant and simple SW sample programs to study.

If anyone has some nice simple sample programs with source, please let me know about hat in the comments for this post! I haven't really looked all that hard yet, though, so hopefully there's some good stuff on the superwaba site.

So be patient with me as I work on finding my way out of this "lost" state I'm in! Rest assured, I haven't given up, I'm just slow!

ED: Next Steps are Tough!

2004-07-29T21:47:00.000-04:00

Well, you haven't seen as many updates from me recently. Wondering why?
A couple of really simple reasons:
1) I'm very busy.
2) The next step seems to be very hard for me to get a handle on.

Mostly #2. So when I figure some of this out, you get the benefits!

I could handle the stuff I've done so far relatively quickly because I kind of knew where I was headed, or there was great documentation. But the next steps seem to be quite a challenge because I need to somehow get my bearings. How do I go from the sample SW shell program from MobileCreator to a "real" app with guts? How does the whole GUI interface and event stuff work?

To me, these things don't seem to be real trivial to pick up. I have a lack of Java knowledge. It is not easy reading to get that info out of the tutorial (but I have to admit I haven't really sat down with some time to figure it out from the tutorials). If a little more effort with the SuperWaba manual doesn't get me anywhere, I'll jump into some of the sample programs and try to find something simple enough to understand. All else fails, I'll take a sabbatical from SW and write some simple things in Java just to get my bearings before I dive back into SW.

So be assured I haven't quit. It just may be slow going for a little while.

Will It Be Pretty? NO!

2004-07-25T08:05:00.000-04:00

The next step has been somewhat vexing for me, because there's a big chasm between where I am and where I want to go.

You see, I'm not sure what program is my end goal. I have lots of options, but need to know more before I pick.

I could start compiling and fiddling with more of the demo programs. Or I could go through the tutorials. Or to shore up a bit more with Java, I could go back to my Beginning Java book first. What to do?

Well, while I sort that out in my mind (my schedule's been busy so haven't had any time for my hard-core learning time), I thought I'd post another thought about the look and feel.

As I pondered my end result I realized that I also have to make some decisions about what the end product is going to look like. I don't like the appearance of many of the superwaba programs I've seen. They're, well, just kind of ugly. But others seem nice, so I know it must be a matter of how you write the code.

I don't really want to write an ugly app. But when the rubber hits the road, I have to be practical. I'm not a gui designer. I've seen posts on the newsgroup that tend to give me the impression that fancy gui stuff (like underlining certain elements) is pretty complicated. And I find it's generally true for all software tools that you find the going much easier if you use it the way it was designed to be used and for the mainstream features only. If you start to push the envelope it can be exciting if you know what you are doing, but pretty darned annoying if you are a novice without much time to problem solve.

So there it is.... the answer to "Will it be pretty" is NO! I've reconciled myself to the fact that I have limited time and limited knowledge, so for now I'm going to make any apps I write pretty barebone, both in style and probably in functionality. If I decide to publish a program to the world later, I'll worry about pretty at that point.

Sort of as a corollary, I seem to get the impression that one of the great challenges of programming for Palm is making it work on the wide range of devices available. SuperWaba should help a bit with that, but I'm sure it's still an issue. For now I will be content to just program for my T|E simulator and/or my SJ33.

Ahhhhhhhhhhhhhhh........... I feel much better. It was hard for me to settle for bare bones like this, but now that I've faced the facts, I think it's lifted a great burden off my back, and I'm excited about moving forward again.

ED: Tutorial Purchase Adventure

2004-07-17T10:46:00.000-04:00

I did it. I placed an order for SuperWaba tutorials. They are supposed to be available immediately after a credit card purchase. Why did I ever think it would be that easy????

I only got one email from the order processing company that said the order was received. I was promised another soon that would indicate the order was processed (or not if there was a problem). Another email never arrived. And when I sent a follow-up email as suggested if anything went wrong, I expected at least an automated response to assure me I would be taken care of. No response.

All kinds of thoughts race through my mind.... Is it a scam? Did I make any typos? What chance do I have of getting my money back? How much hassle is this going to be?

One of the bad omens right from the start was a bold and flashing text (yes flashing! I kid you not!) at the beginning of the order process warning me that I might lose my money if I type in the wrong email address. If I hadn't wanted so much to get the tutorials, I would have probabaly backed out of the whole thing right there! Maybe I should have?

UPDATE: That was "yesterday". Today I went digging. I sent another follow-up email. Nothing happened. So I went to the processing main url at regsoft.com to see if I could find out anything, and get an idea of how worried I should be. Fortunately, it looked like a legitimate web site. I dug some more and found they have some customer support contact options (which I've listed below in case anyone else has problems -- the information was NOT given anywhere in the ordering or follow-up process, so unless you dug into regsoft.com you would not find it).

After about 15mins of hold while listening to what sounded like a low-quality 1 min song loop, I got a human voice. What a grand relief! He got hold of his supervisor, who determined that my email address had been flagged as suspicious. I guess when an order is suspicious, it gets ignored? At any rate, they released it manually, it seems to have gone through because I have a confirmation email now.

A check on the superwaba.org site shows that I have rights to download. I transferred them onto my PC and I'm good to go. What's in them? The UI tutorial has a 61pp .pdf document plus a bunch of sample code.

Time to start digging in a bit more. See you next time!

==============================
Please note that this information is off the regsoft page, so I can only say that it's apparently valid as of today... July 17, 2004.

How can I reach RegSoft.com?You can reach RegSoft.com in a number of convenient ways:

E-mail: By far the fastest and best way to contact us. We read our e-mail on a very active basis. Kindly send comments to our representative at sales@RegSoft.com.
Phone: You may reach us by phone at in the United States at 1-877-RegSoft.com, 1-877-734-7638 or at 1-770-319-2718.
FAX: 1-770-497-9234
Mail: You may also reach us by sending a letter to: RegSoft.com Inc.9625 West 76th Street, Suite 150 Eden PrairieMN 55344

HelloWorld2

2004-07-17T10:35:00.000-04:00

Today is a brief and simple post to describe a "real" Hello World application. It prints a message inside the main window. That's it.

The code was taken from the wabasoft.com article about how to write a simple program.

Continuing with my favorite software at the moment, I used MobileCreator to create a new project. First time I got repeated errors because I chose to not let the project wizard create a main window class automatically for me. As a result I was unable to add a class later. The easy workaround until I figure out what's really going on, was to create the project again, and let it create a main window class for me.

I called it HelloWorld2, and used the following code...

import waba.ui.*;
import waba.fx.*;

public class HelloWorld2 extends MainWindow {

        public void onPaint(Graphics g) {
           g.setColor(0,0,0);
           g.drawText("Hello SuperWaba World!",0,0);
        }

}

Notice that I've made another discovery... how to format code in this blog! Turns out that I have to paste it into MS Word first. Then cut and paste into the blog. Don't ask me what changes, but it seems to work!

I ran it with the "green flag" button, and it ran in the applet first time no problem! I changed the dropdown box to use the Palm TE simulator. Works like a charm in the simulator also!!

This whole experiment and blog entry probably took me about 10mins total. Life is good!

I haven't decided what comes next, but have ordered the tutorials for SuperWaba. Will make a decision based on what those look like.

ED: No Longer Feeling Outcast!!!

2004-07-16T23:08:00.000-04:00

Happy news to report today! That Palm community spirit is alive and well in my eyes in SuperWaba land. David B has responded to my post and encouraged me with his kind words. Hallelujah!

You may say, why do you care so much about a stupid post? Was the information that important to you. Do you really care if anyone responds?

Well, yes, it is important to me. The greatest motivation I have with Palm devices is not the PalmOS itself (though I am a big fan). It is the heart and soul of the Palm community of developers. I have witnessed the warm and generous nature of a few of the developers, plus some of the others in the Palm community. It may not be important to some, but I am saddened by the loss of kindness in this world at times. Call me wishful, but I like to think people can
be kind to one another, and not be entirely self-centered. And that means being kind to not just those that can do something for you, or that you highly respect, but being nice even to people like me that probably sound like goofballs because I don't really know what I'm talking about..... yet!

I had an interesting conversation the other day with a friend about a small midwestern town in the US. She was visiting relatives there with her husband, and she was amazed by their friendliness and kindness. They were so nice that it was intimidating at first, and a bit unnerving. But once they realized the people were just being nice it was greatly refreshing and reminded her of how, in comparison, most people are so much less kind and friendly.

I see a little bit of that goodness in the Palm community and it's a big part of why I am excited to be a part of it. It's really not very likely, but maybe one day I can even contribute some useful code. For now, I maybe can encourage a few people in other ways like the Palm and PDA forums. Over and over I see people motivated to help one another. That shift away from
selfishness is refreshing. People are born with the capacity for great amounts of goodness, and it's wonderful to see a bit of that come out.

Okay, I'm off my soapbox again for today. Next up is some more SuperWaba HelloWorld.

Update (7/27/04): Interesting thing... I looked back at the newsgroup for my post to see if anyone else had seen it and responded. Not only were there no more responses, but it was missing completely! I guess someone watches over the list and "cleans up." Hmmm...

First SuperWaba Program (Shell)

2004-07-15T17:52:00.000-04:00

Today, I am thrilled to be writing about actually programming something trivial and running it on my SJ33 Palm Clie. We'll also run in on a TE emulator. But not on a Sony emulator because of Sony's lack of ongoing support for the Clie line.
What we will run is really just a program shell that is created by MobileCreator when you start a project, so it's not like I'm really writing any lines of code yet. Still, I'm very happy to get one step closer!
First things first. I've installed MobileCreator with the Palm emulator (not really needed anymore because I'm going to simulate the TE instead), the Palm simulator set up for a TE, and the Sun SDK.
So far things are pretty straightforward, but let me describe a couple of the settings. I intended to put some screenshots here, but turns out that's only easy if I'm updating the blog with FTP, or if the pictures are already online somewhere. Neither is the case for me at this point, so intead of screenshots, here's a description of some of the key settings I've chosen...

(Under Project... Settings... )

At Exegen Tab... I've checked "Start Exegen"
At Warp Tab... I've checked "Start Warp" and "Recurse Subdirectories"
At JDK Tab... Use java.exe
At Paths....
    SuperWaba path = C:\Java\SuperWabaSDK    JDK path = C:\j2sdk1.4.2_04    Emulator = C:\Java\POSE\Emulator.exe
    Simulator = C:\Program Files\TESimulator\PalmSim.exe
    Applet = Well, this doesn't really matter because I can't get it to work right. Instead I'm using the simulator.

We're almost ready after the simulator is setup. As I indicated, the TE simulator is a best case alternative for either an AppletViewer or a Palm Emulator for SJ33. Neither of those seem to work, in the sense that I can't get the applet viewer to use my fonts and the SuperWaba newsgroup community considered my case unworthwhile or uninteresting. And the SJ33 roms are not available because Sony has cut off support to the Clie line. Did I mention yet how disappointed I am in Sony?

Okay. As far as setting up the simulator, you get it from the Palmsource developers web site just like the emulator. I guessed at a few parameters to set. After you launch the simulator, you have to do the startup preferences routing and then you can right click and set 32 meg RAM and increase the dynamic heap memory to 2048 KB. You may have to do preferences one more time. I then installed the SuperWaba palm files for OS5, and the LSW/MSW/HSW font files for SuperWaba. At that point I did Storage... Save to save my profile.

Now it's supposed to keep all the session info in the palmsim.ini file that's in the same directory as PalmSim.exe. It will then launch next time in the same condition it did the first time. Well that wasn't happening for me and every time I launched the simulator application I had to redo preferences and load the .ssf settings file I had saved the previous time. I called mine storage_snapshot.ssf.

Well, even worse, MobileCreator is supposed to be able to launch the simulator as part of the compile and run process so that with one click of the mouse in MobileCreator you can compile and run on the simulator. Pretty nifty! If only I could get it to work. I won't go into all the details of the round about way that I came up with an answer (partly because I don't remember the details, and partly I'm embarrassed to tell you all the rabbit trails I went down to try to do a "workaround" before I found out how simple it is!)

The simple answer is that you just need to make sure that you have the following lines in your palmsim.ini file... (but use your own settings filename, of course)
LastStorageSnapshot=C:\Program Files\TESimulator\storage_snapshot.ssf
StorageSnapshotFile=C:\Program Files\TESimulator\storage_snapshot.ssf

Now everything works like a charm. Open up MobileCreator and create a new project. The program looks like this (sorry again about the formatting -- I need to find a solution for that in this blog pretty soon!):

import waba.ui.*;
import waba.fx.*;
public class HelloWorld extends MainWindow {
Font font = new Font("Tiny", Font.BOLD, 10);
String menu[][] = {
{"Options","Cut","Copy","Paste"},
{"About HelloWorld","Info"}        };
public HelloWorld() {
highResPrepared = true;
setDoubleBuffer(true);
setBorderStyle(TAB_ONLY_BORDER);
setTitle("HelloWorld");
setMenuBar(new MenuBar(menu));
}
public void onStart() {
}
public void onEvent(Event event) {
highResPrepared = true;
}
public void onPaint(Graphics g) {
}
}

Some of the hires and font stuff may differ from what you get if you are giving it a try. I was doing a lot of playing around with the font related stuff to make it look right on my Sony. Don't know yet what is important and what is extraneous. And I also added some text that looks like HelloWorld just to make it feel more like a HelloWorld-like program.

Set the drop down box to Palm Simulator and click the green flag toolbar button for save, compile and run. There it is!!!! You also get the .prc and .pdb files to install on your Palm if you checked the Start exegen and Start Warp boxes in project settings. Install them just like any other programs on your Palm, and you can see the results work there also!

That's actually pretty neat! We haven't really coded anything, but as you can tell, we've made a lot of progress. Still some big unanswered questions...
*) How does all this hi-res stuff and font-selection stuff work?
And the main point of this whole exercise, which is
*) How do I code to this Java-like API to write a real program?

Okay, so what's next? We have a program shell, but it's really not a HelloWorld program. There is a WabaSoft document that tells all about writing a simple program. I hope to get a real working HelloWorld program based on that document's information.

Later possibilities....
* Do the scribble program from that same document.
* Compile and run some example programs from SuperWaba.org
* Start writing examples of some basic GUI
* Try the GUIbuilder. (It's written in SuperWaba, and is supposed to allow you to do GUI design right on your Palm. At least that's my impression, so it's worth a look.)
* Maybe buy and work through the tutorials. I have to admit the cold reception from the SuperWaba newsgroup makes me perfectly content to delay that decision until I'm more comfortable that SuperWaba will work for me. And obviously, you feel more interested in helping out a community if they don't reject you! But despite the feeling of mistreatment, I really like what they're doing, and I'm pretty sure they aren't in it for the money but out of good will and genuine interest in PDAs. So I guess for now, SuperWaba is still on my "good things in this world" list. I may change my mind later, but always best to give the benefit of the doubt. Unfortunately, I suspect that without community support, I'm sunk for any serious endeavor, so after playing around with SuperWaba enough to feel like I've learned some basics, I may jump to NSBasic or another commercial product. Or if the road gets tough with SuperWaba, I may just throw it back in the pond and go fishing elsewhere. Lots to ponder, but it's still early, so there's plenty of time to ponder those sorts of things. As I said before, so far so good!

Just for your reference, here's the settings I have in my palmsim.ini file. Note that there are some secureit references in there also. That's a great tip for you also that I found by experiment. Have you got a security/encryption program like SecureIt that holds passwords and such, but doesn't have a desktop version? Well, suppose you drop your Palm into the river? How are you going to get to that essential information? You certainly don't want human readable backups laying around just in case, and they wouldn't be up-to-date anyway. Well, you could buy another Palm device. OR.... if you have a simulator set up, you can use the simulator. Install the program and the associated files with the data and voila! You can run the program on your simulator on a PC!

Okay, back to SuperWaba. Here's the contents of my .ini file for the simulator. See you next time!

=============================
[Settings]
ROM=C:\Program Files\TESimulator\EFIGSP\TungstenE_EFIGSP.rom
RAM=32768
DYN=2048
Sound=0
StorageProtection=1
Zoom=1
BitDepth=8
DebugThroughTCP=1
AlwaysOnTop=0
UseHostBatteryInfo=1
WindowOriginX=597
WindowOriginY=57
RedirectNetLibCalls=0
AllowedScreenDepths=32907
LastSilkScreen=
AppCreator=
CradlePort=
CradlePortType=
Standard RS-232InfraredPort=
InfraredPortType=
68KDebuggerPort=localhost:2000
68KDebuggerPortType=TCP/IP
AdditionalPorts=
TraceTarget=tcp:localhost:25998
GremlinsFromValue=0
GremlinsToValue=0
GremlinsSwitchAfter=0
GremlinsSwitchAfterValue=0
GremlinsStopAfter=0
GremlinsStopAfterValue=0
GremlinsSelectedApps=
GremlinsFirstApp=
GremlinsAllowScreenUpdates=1
GremlinsWindowOriginX=0
GremlinsWindowOriginY=0
LogErrorMessages=0
DirectScreenAccess=0
ExtendedMemoryChecks=1
LastStorageSnapshot=C:\Program Files\TESimulator\storage_snapshot.ssf
StorageSnapshotFile=C:\Program Files\TESimulator\storage_snapshot.ssf
LowDensityMode=0
MRU_PRC[0]=C:\Program Files\TESimulator\AutoRun\Secure_It_Templates.PDB
MRU_PRC[1]=C:\Program Files\TESimulator\AutoRun\Secure_It_Secrets.PDB
MRU_PRC[2]=C:\Program Files\TESimulator\AutoRun\Secure_It.PRC
MRU_PRC[3]=C:\Program Files\TESimulator\AutoRun\HelloWorld.pdb
MRU_PRC[4]=C:\Program Files\TESimulator\AutoRun\HelloWorld.prc
MRU_PRC[5]=C:\Java\SuperWabaSDK\lib\LSW.pdb
MRU_PRC[6]=C:\Java\SuperWabaSDK\lib\HSW.pdb
MRU_PRC[7]=C:\Java\SuperWabaSDK\lib\MSW.pdb
MRU_PRC[8]=C:\Java\SuperWabaSDK\lib\xplat\SuperWaba.pdb
=============================

ED: Success! (There's Always A Workaround)

2004-07-12T23:17:00.000-04:00

YIPEE! While I may have hit a couple roadblocks due to Sony and a lack of response from the SuperWaba community, I think I'm going to be okay with a workaround. And tomorrow night I'll sleep, sleep, sleep because I sure didn't leave much time to do that tonight! It feels a little like I'm in college again.

Quick Recap of the Situation
------------------------------
I was having troubles making things work with my Sony Clie and SuperWaba. I could run code on my SJ33 directly, but couldn't test it in an alternate location (applet viewer or emulator). That's important to me because I can't be making backups every time I want to try my code. But the PDA is my only PDA so I don't dare running "novice" code without backing up first.

The better solution is to test the code on the PC. So I tried to upload my ROM using the emulator. It didn't work and I couldn't figure out a remedy. Next I tried to download the SJ33 ROM from Sony and found that new registrations are no longer accepted, so I can't get the ROM there. (BTW, I was pleased to see that quite a few of the top Palm news sites picked up on the story really quickly. There was information on Palm Addict, OneSource, and Palm Infocenter already at last check.)

So I'm left with the Applet viewer, but I couldn't run SuperWaba code using the Applet viewer and make it look like the SJ33. The problem was that there was no way to use the font I needed to make it look "pretty." I posted a question to the SuperWaba newsgroup and was basically given the 'ole "talk to the hand" response. By this time I had another plan of attack.

Alternate Plan
--------------
I figured I could switch to the Palm Simulator (for OS5+) and code for the Tungsten E, rather than trying use the POSE emulator (for <=OS4). Actually, that is now looking like a good choice. I looked at some T|E sales on Ebay, but they were all around $150 and up. I was hoping for $100 and down, but that was not in the cards. But I think coding for the T|E simulator in support of my SJ33 may work out about the same as having a Clie emulator because of SuperWabas portability, and the screen similarities. Can't really tell yet, but so far so good.

I did install the T|E Simulator. And after some fiddling (the trick turned out to be that I had to tweak the simulator .ini file to use the last saved settings/configuration. Once I did that things worked like a charm and I could write the code in MobileCreator and push a single button to compile, create the Palm install files and run in the simulator. Pretty slick. Daniel Tauschke, the creator of MobileCreator, is my hero today. Thanks Daniel!

Some Thoughts And Next Up
--------------------------
I'm actually rather pleased so far with SuperWaba despite being snubbed by the SuperWaba community at large. And that's certainly much better than what I think about Sony right now!

This may become a theme... "Oh No!" followed by "There's gotta be a workaround" followed by "Aha!" followed by "So far so good!" and another "Oh No!"

Details about this step (getting a trivial SuperWaba program to work on the simulator and my SJ33) will come next as soon as I have time to gather my thoughts and write down what I did.

Hopefully, by suffering through this learning process, I can make it a bit easier for other novices to get past the "getting started" difficulties that we all face. Better to let me struggle and pass on the information than have thousands (well, maybe hundreds?, er.. maybe dozens?, okay maybe one more!) of us suffer the same problems independently. At least that's my theory. If anyone is getting anything out of this, whether information or simply amusement, I'd love to hear your comments!

Thanks for reading!

ED: Oh no... I'm a SuperWaba Outcast!

2004-07-12T17:36:00.000-04:00

Well, I'm starting to feel like an outcast already. I've posted my Clie-specific SJ33 issues on the SuperWaba newsgroup. I don't wnat to jump to conclusions, but I'm getting the feel that the grand and friendly community spirit doesn't seem to exist in the Superwaba world like it does for the Palm community in general. My post to the SuperWaba newsgroup (assuming I posted it correctly) has attracted no comment. I would have appreciated even a rebuke for posting badly! Indtead my poor post just sits there ignored like the whimpy looking kid on the playground while teams are being picked for football. Maybe my post makes me look like a leper, and I just don't know enough yet to realize it.

But when I take a look at reality for the moment, SuperWaba is the only "real" game in town (so far), and I have this unexplainable desire to torment myself with Java, so I have decided to continue onward. And despite feeling a bit unwelcome, I can't believe that the SuperWaba commuity is full of unkind and uninterested individuals. Maybe they just don't care about novices. Maybe my posting was considered off-topic (I wish someone would just say so.) Or maybe my post was just not interesting or politically correct. I guess I might never find out.

At any rate, and as best I can tell, that leaves me with just a few choices:
* Switch midstream to a more "Mainstream" development environment like NS Basic or CodeWarrior C.
* Replace my Clie with something Palm like a Tungsten E. (I can see the dollars flowing out of my pocket from this experiment already.... T|E, accessories, storage card, software, tutorials for SuperWaba, professional version of MobileCreator, etc) This "free" SuperWaba thing is not turning out to be so "free" for me!
* Take my Palm and go home because no one wants to play with me. Well, I'm a bit offended, but I'm not quite that goofy. My desire to program hasn't changed. I just need a new approach.
* Do my development on my Clie directly and forget about Applet classes and POSE emulators. The problem with this is that it's my only PDA, and I can't risk data loss. My "life" is on that thing. So I have to make complete backups every time I want to run my rookie code, which as far as I know, may be a Palm wrecking ball.
* Develop for a Palm simulator configured for a HiRes (320x320) Palm OS5 device like the T|E. Then convert the app to work on the Clie afterwards when I know better what I'm doing. The only problem with this is that I really enjoy having my PDA showing the results of the code, and there's no guarantees I can convert for Clie afterwards anyway.

Well, I'm going to explore how expensive the T|E route would be tonite. But what makes more sense is to program for the T|E simulator, so that's my plan. Then it should, hopefully, be an easy port to a newer Palm when I buy my next model. Apparently SuperWaba and Sony don't play well together. Kinda like the SuperWaba community and me, I guess!

Anyone out there feeling sorry for me yet???!!!! Well, don't bother. I'll find a way to make this work. It's just a silly program, how hard can it be?

ED: Complaint about Sony

2004-07-11T00:50:00.000-04:00

This is an interim post editorial (ED). There will probably be a bunch of these coming up.

EDitorial posts are going to be like an editorial comment, rather than a step in learning to code. But it may give you insight occassionally to something I'm thinking about, or some of the problems I'm working on in advance of the next blog posts.

Today I am writing this blog entry because I'm a bit exasperated. I just tried to upload my ROM to the Palm POSE emulator. It didn't work, so I figured I'd Google for "Sony POSE" to find alternate ways to get the ROM. It led me to the Sony developers site. So far so good.

But when I tried to download the ROM (for the SJ33 machine I own, no less) it required a registration/login. Okay, I don't mind too much. I've been doing a lot of registrations and downloads since I started this project and one more is no big deal. Well the page for registrations indicates (on http://www.cliedeveloper.com/develop_info/index.html) the following:

================================
Dear Developers,

As a follow up to Sony's recent decision to reassess the direction of the conventional PDA market, it has closed the CLIÉ Developer Support Site registration system to new members. Existing registered developers may continue to use the tools and services on the CLIÉ Developer Support Site at this time subject to the Membership and License Agreements contained therein.

Sincerely,
The CLIÉ Developer Support Desk
================================

This is a frustrating development. I guess I'll just keep using the Palm IIIc device, which I think is close to mine. Hopefully the fonts will work out okay. Or maybe I'll try to find something with a closer match on the screen. I just have this sinking feeling it won't really work because Sony HiRes OS4.1 seems to be a special animal all it's own when it comes to fonts and display.

If I don't find a way to get hold of the SJ33 ROM image (even better with a debug version) then I suppose the best solution is to buy a Palm device, and just write code for the emulator until I get one. Bummer.

One thing's for sure. I realize now that you have to be a little bit crazy to want to inflict all this on yourself just to write a silly little program... so call me crazy!

Java HelloWorld

2004-07-10T13:24:00.000-04:00

Getting Started with SuperWaba – Java HelloWorld

Now I’m pretty sure that this entry is going to be frustrating for some. Why you ask? Because maybe you are chomping at the bit to write something on your Palm PDA, or read about me doing that, and here I am telling you that we’re going to take a step away from PDAs and SuperWaba to focus on Java! Yes, we probably could jump right into a Palm app on the handheld without too much difficulty. But the whole thing is still pretty intimidating to me so you’ll just have to bear with me as I do this step by step.

My goal this time is simply to (1) get some familiarity with Java and (2) write and compile a Java HelloWorld program on the desktop (WinXP).

I figured that if I couldn’t do something simple in Java, I would be totally lost when it came to trying out something in SuperWaba on the Palm. That is probably a realistic assessment. For some of you, if you’re new to all this and are following along doing your own thing with me, this step may take a bit of time. And writing a HelloWorld program may not be enough to feel a base level of comfort with Java. So you might want to go a bit farther with Java than I plan to do right now. At the same time I hear SuperWaba calling my name, so I do want to get to that soon.

Even though I call myself a novice, I do have a little non-GUI Java programming under my belt from the past work, and have both taken classes and done some work with OO design. That means I don't know much, but even to get going I needed this quick refresher now about the most basic of basics. And hopefully, that will jog my memory about some of the other basic level stuff I used to know. Since it won't take much to get me lost, I’ll dive into my Java Beginners book often.

I originally learned some Java from being put on the hot seat at work, plus a little from a book called Beginning Java (JDK1.1) by Ivor Horton. I like that book because it is simple and it doesn’t spend a lot of time on goofy stuff that doesn’t seem useful for basic desktop application programming. I also am pretty sure there’s an updated book now for Java2.

Now that’s something else I should explain in simple terms. Java versions went something like 1.0, 1.1, 1.2, 1.3, 1.4, and currently as of this writing I think 1.5 is in beta. Things changed pretty significantly going from 1.0 and 1.1 forward into 1.2 and onward. As a result, people seem to refer to 1.2, 1.3, 1.4 etc collectively as Java2. Go figure! The bottom line is that while you probably want to consider a book that uses 1.4, you especially want to make sure it’s at least Java Second Edition, or Java2 or whatever it’s called. I.e. Make sure it covers 1.2 or higher.

And if you’re looking for a good Java book, you probably don’t want to pick a book that talks about Java frameworks like Struts, or distributed objects and stuff like RMI or CORBA. (I understand that’s already like a legacy technology now anyway!?) You don’t need all that enterprise stuff now. You just need to know about the basic Java language, some simple thoughts on OO design, and how to deal with conditional logic, variables, classes and objects, inheritance, interfaces, methods, file manipulation, threads, AWT/Swing, etc. Here’s where I could probably point you better if I knew where we were headed (i.e. if I already knew Java and/or SuperWaba). But you’re along for the ride with a novice, so you’ll just have to take what I can offer.

After a lot of reading at the bookstore, the book I decided on was perfect for me as a refresher. And looks to be easy to read, covers topics I’m interested in, and is really down to earth and practical. It’s Murach’s Beginning Java2 by Andrea Steelman. (And I just noticed the similarity in titles… both books I liked are called "Beginning Java" so I must like that name for Java books!) I also have my eye on Java in a Nutshell by O’Reilly Press. But I didn’t get one because I have a Java 1.1 version, which may hold me until I find out more about SuperWaba and what I might need.

Okay, let’s get down to the nitty gritty and get that HelloWorld application running. The first thing you need to decide is what editor or IDE to use. (As I noted before, and IDE is just an integrated development environment to make it easier to code.) I decided to do HelloWorld in three places just for the heck of it. In notepad, TextPad, and JBuilder. (More registrations and downloads!!!!! I sure hope you have a broadband connection if you’re doing this with me. I can’t imagine doing all this downloading without one.)

But for our purposes here, we’ll just do it in notepad to stay generic. It will be more than enough to get the point across.

There are several things you need to do to get ready to edit and compile the code. And all of this will be in any book you have chosen on beginning Java.
1) Pick and create a directory on your PC to store your code in. I recommend something like C:\MyJavaCode because it’s simple and easy to access even from a command prompt. Plus, you may want to have directories under that for each project/application.
2) Set the path variable in Windows to include the java compiler. It’s called javac.exe and it’s one of the files that gets installed with the Java SDK. This path statement tells Windows where to look for files to execute, so when you call the java compiler, it knows where to find it. You will need to add to the path variable the name of the directory with javac.exe in it.
3) Set the classpath variable in Windows. This is another environment variable for Windows, kind of like Path, but this one is especially for Java. The idea is that Java code is grouped into Packages that contain classes. The classes are text files that define the program and contain the code, including it’s variables and program instructions. Java is different than a language like Cobol in that it isn’t all lumped into one big file. It’s made up of a bunch of classes, and each class is defined in a separate text file.

The packages and subpackages are set up like, and correspond to, directories and subdirectories. In fact, all the code files (classes) that make up a program are grouped into directories with names equal to their package names. The classpath statement tells Java where all the “top-level” package directories are. For what we’re doing, we might not ever have to create our own packages, so you can think of the classpath as pointing to the directory with your code.

Because we’re going to use a command line compiler, and call it from the same location as the code files, all you need to add to the classpath variable is “.” To represent the current directory.

If all this is confusing to you, get yourself that beginning Java book. It’s really not that hard, and those books can explain it a whole lot better than me.

Now that we’ve installed the Java SDK, and set the path and classpath variables, we are finally ready to write and execute a HelloWorld program.

Here’s the code I’m going to use. It will go in the text file C:\MyJavaCode\HelloWorld.java which has to match in name to the class name defined in the code we put inside that file.

public class HelloWorld{
public static void main( String[] args){
System.out.println(“Hello to the World from the SuperWaba blog!”);
}
}

Note that this blog may not show the indents properly. Each of the first three lines gets a different level of indent. The first "}" should be under the start of "public static...", and the second "}" is back at the left margin. Maybe later I'll figure out better how to control the formatting on this blog, but I'm in a hurry to finish this post right now.

To compile this code (from a command line on WinXP and from the same directory as the HelloWorld.java file with the program in it), you just type >javac HelloWorld.java (the ">" is the command line prompt, so don't type it in) and hopefully you get no errors, or at least they are easy to fix.

To run the program, you then type >java HelloWorld and the message should appear on the console.

That’s all there is to it, and that’s all for this time. Next time we look at SuperWaba and make a stab at HelloWorld on my SJ33!

Starting With SuperWaba

2004-07-05T18:30:00.000-04:00

Today, I’m going to describe an overview of what I’ve discovered so far relative to SuperWaba. I knew right off the bat that there were some things I probably needed to get familiar with to program using SuperWaba: Java, SuperWaba, Waba, Palm Programming, and some associated tools or scripts.

A search on the web for SuperWaba led me to the main site, with all kinds of information. You can use either www.superwaba.org, or the site you are directed to, which is www.superwaba.com.br . There’s a wealth of information there. You can register and download the SuperWaba software. And if you look around, you’ll see links to articles and other items of interest.

(You had better just get used to the idea of some web registrations because you’ll need to do at least three of them just to get going. Plus a lot of downloading, so you’ll need either a lot of patience or access to a broadband connection.)

Anyway, I downloaded superwaba. I also registered for and downloaded the Sun Java SDK (the standard SDK edition, not J2EE, and not just the Java Runtime Edition).

And the best decision of all was to download an IDE that is built just for SuperWaba. It’s the Tauschke MobileCreator, and the personal edition is free at http://www.tauschke.com/ after you register. Basically, it doesn’t have debugger support or package support in the free edition. Both are important in big projects, but seem to me to be no big deal for the kind of thing I would be creating. There are also free alternatives if you want to use another IDE, but that’s getting ahead of myself. The neat thing about MobileCreator is that the whole process of compiling into palm installable files and testing it out on an emulator is so simple and automated that it happens with the push of a button. Once I know how that all works under the covers, I might not care so much if I have to do it on my own, but since it’s all a mystery at the moment I’m really happy to see it happen “automagically”.

Incidently, an IDE is an Integrated Development Environment, which is a fancy way to say it’s software that provides a nice way to write and keep track of code. Usually it provides features to help with things like compiling, testing, syntax, version control, etc.

So let me make a quick pitch for MobileCreator now. We should let the developers know that we novice programmers and hobbyists are appreciative that they have made this IDE available for personal use. Sure, there are some other Java IDEs that could be used with SuperWaba, and they have free versions. And certainly the MobileCreator developers will make some money by getting people hooked on a free version to upgrade later into a paid version. But let’s give credit where credit is due. By providing this for free personal use, the developer has done a great service to the Palm community, and I for one am thankful. It’s just one example of how Palm developers are the “good guys.”

Now everything thing I’m describing here is based on the “you’re not going to try to sell your software” assumption. I don’t understand all the licensing yet, but the basic idea seems to be use it for personal and/or non-profit purposes and you’re okay as long as you include the right information and credits when you distribute. If I start thinking about publishing software useful to the world, then I’ll have to learn more about licensing. But for now, I think it’s pretty safe to say that you can use it for your own personal use without any problems.

For those of you that have another favorite Java IDE like JBuilder or Eclipse, for example, you can use it with SuperWaba. There is even a free basic version of JBuilder available. Eclipse is GPL (free), has a plug in for SuperWaba, and I think it has a debugger and package support. Other possibilities are things like TextPad. Newsgroups are full of info on how to do that, but until I give it a serious try it’s out of scope for this blog. And, besides, the whole compile and build process with things like ANT, Warp, Exegen, Jump and Matchbox are kind of intimidating to me at the moment. But with MobileCreator it’s pretty much automatic. And you can even use the same code to generate for Pocket PC in case you’ve “gone over to the dark side” as they say in Palm circles.

So let’s get back to what we have to do.
--> Download and install SuperWaba
--> Download and install the Sun SDK
--> Download and install the Palm Emulator or Simulator, and
--> Download and install MobileCreator.

If I remember right, the path I took was to download all four, but for some reason I decided to install SuperWaba first and MobileCreator next. It probably looked so good I wanted to see if it was self-sufficient before I went any farther. And I believe the installation setup program instructed me to do the SDK and Emulator downloads as part of the install process! Funny thing... Most software install instructions and information for the user seem somewhat misleading or ambiguous to the uninformed user. Somehow the MobileCreator designers were able to break that pattern and write excellent instructions. They were brief and informative, and I was comfortable the whole way through. Very impressive.

To download the Palm Emulator, you need to register at http://www.palmsource.com/developers/ The Palm Emulator is what I chose because I have a Sony Clie SJ33 running OS4.1. Apparently the Palm devices running on the older architecture and processors use an emulator. In addition, you’ll need to download a ROM that has the guts of the machine you are emulating. Plus you can add a skin if you like to make it look pretty.

If you are trying to develop for Cobalt (OS6), I don’t know if any of this SuperWaba stuff works yet. I’d guess “no”, but I’m just not sure. I do think it can handle OS5 though. The difference is that, for testing, instead of using an emulator (POSE = Palm OS Emulator, I think), you choose the Palm Simulator at the Palm developer site. They have more details there if you dig around, but I think I’ve captured the basic idea. I also went for a ROM with debug built in. I think that means that it can tell you if you are using “bad” code. I.e. code that is lacking in compatibility with various devices or future versions of the OS.

The hardest part of getting all this software is really just figuring out which file to download, and knowing what part is for what. It’s pretty straightforward, especially for MobileCreator and the Java SDK (as long as you remember that the JRE Java Runtime Edition is not enough all by itself, and J2EE enterprise edition is too much.) Here is a link to load that core Java SDK: http://java.sun.com/j2se/corejava/index.jsp (as opposed to the Desktop Java which is the JRE only).

Now, if you have installed SuperWaba, MobileCreator, the Sun Java SDK, and a simulator or emulator, you are all set to move forward.

Next… Java HelloWorld

Introduction II

2004-07-05T17:52:00.000-04:00

Today I want to share a few more details of the plan. As I learn, it will grow and evolve, but you’ve got to start somewhere. So here’s what it’s all about, in bullet form:

1. THE GOAL is to learn to code on my Palm device. Not to be an expert, but just to be able to do the things that a beginner can do. Then if I need something goofy like a utility for my PDA that calculates the number of curved vowel letters in a paragraph, I can write it myself.

2. My experience will be SHARED THROUGH BLOGGING, right here. I’m thinking that there are a lot of people curious about the same things I’m about to discover. And I would consider this whole thing a success if just one other person is inspired to give it a try because of this blog. In fact, I’ll be satisfied even if just one person enjoys following along with my adventures out of curiosity.

Because I’m learning as I go, and I’m not an expert programmer, this won’t be like a tutorial. Don’t expect a well thought out description of the best way to do things. Don’t even expect all the information to be comprehensive or even be completely correct. I’m just sharing my take on things. If you are aiming to become the next great programmer, read this for fun, but go find an expert to learn how to program the right way.

3. This blog won’t have EVERY SINGLE DETAIL documented, but it will have enough to help a lot if you’re someone that is trying to do the same things that I am. And there are a lot of wonderful sources of information that I will point you to along the way.

4. As I alluded to before, I’m a busy person, so entries MAY BE SPORADIC. Don’t expect a daily blog and a toll-free support line! I’d love to get some blog comments with your thoughts and feedback. Hearing from people that have an interest will be my biggest incentive to blog. If no one contacts me, I may just continue "bloglessly".

5. I’m NOT A PROFESSIONAL WRITER. That pretty much says it all, but note one more thing. I’m pretty nervous about sharing all this publicly. Who knows where it will lead, and how stupid I will sound, how easily I'll get stuck. All my ignorance is going to be out in the open for all to see. I say that because a thousand times I’ll probably remind you I’m doing this FOR FUN, and I’m not an expert.

6. How about the end game? Well, I hope to at least continue this blog UNTIL I’VE WRITTEN A SIMPLE APPLICATION, that has some usefulness to someone. Then if I still have the motivation, and the program turns out to be of general interest, maybe I’ll even continue to blog some of the issues involved in publishing it. For example, the licensing and packaging involved with publishing a program at PalmGear or FreewarePalm or whatever ends up making sense.

7. I will be on the lookout for the appropriate software to use in SuperWaba development. There are utilities and programs that are helpful in addition to SuperWaba itself, and I intend to make use of them if they will make life easier. Once I get a feel for what I’ve gotten myself into, I’ll try to start with something like a HELLOWORLD PROGRAM. First in straight Java on the desktop. (Baby steps.) Then on my PDA with SuperWaba. That will be time for a mini-celebration!

8. I’ll focus on A FEW SIMPLE PROGRAMS FOR PRACTICE while I try to get familiar with what’s easy and hard in SuperWaba, learn some basic skills, and get a feel for what the Palm environment means to a developer. And as I do that, hopefully some idea for a simple but useful application will pop into my head. (Or into my blog response comments if you want to help out with ideas for me to consider!)

9. THERE’S NO GUARANTEE OF SUCCESS. This is a fact of life. While I am certain that I could do this if I was willing to work hard enough at it, we are talking about something I’m doing for fun on the side in my “spare” time. If the fun ends, then the project ends. If it turns out to be too hard, I will be ready and willing to admit defeat. But, gee whiz, how hard can it be!!! :)

Well, that’s plenty enough information to give you an idea of where I’m going and what it’s all about. As I learn more about what’s involved in writing code, and start to get ideas for an application it will become much clearer. Remember, it’s not going to look formal, and I’ll probably make a lot of mistakes. If you are an experienced coder, you’ll probably get a good chuckle at many of the choices I make and things I write. But, hey, that’s just part of the fun!

Finally, let me thank all the people that have made this possible with the Waba and SuperWaba projects and creators of some of the other great tools and utilities that I will surely end up using. I intend to do nothing but support their causes and show my appreciation for their work (even if I do some complaining about the shortcomings).

I’d really love to hear someday from those folks responsible for the SuperWaba and related open source projects. I’m especially interested in what motivated them to do all that work. Was it just something they love to do? Was it to help all of us out? Was it because they wanted to see all the great things other people could do if they gave them a platform to use?

If more than a handful of people discover this blog, I’ll also gladly use this forum to help the owners of these great projects in simple ways to get the word out about the good things they have going on. And if, in my ignorance, I either publish incorrect information or suggest anything that causes trouble of any sort, please let me know so I can make an appropriate correction.

Next blog entry… Starting with SuperWaba

Introduction I

2004-07-05T12:12:00.000-04:00

SO WHAT'S THIS ALL ABOUT?

My name is Bob, and I’m a Palm enthusiast who wants to learn to write programs for my PDA. I use my Palm every day and am a fan of the great software out there at reasonable prices. I’ve come to appreciate some of the great developers we have in the PalmOS world, and I want to learn a little more what it's all about.

I’m not really a programmer, though. I think that’s what will make this interesting to other readers who sort of know how to code, but not really. Maybe you have written some old BASIC text output programs in high school. Or maybe you took a few programming classes in college. But you haven’t really done anything significant. Maybe you feel that OO, GUI and event driven programming and design sounds simple when you read about it, but not so easy when you try it. And it sounds even worse to try it on a PDA.

Well, I'm going to give it a try. But before I begin, I feel obligated to set the scene by giving you a little information about my background relative to programming. Bear with me for just a moment.

I admit first of all that I'm not a total and complete novice to programming. But I sort of am a newbie in a way. You see I’m the not-so-unusual mix of “used to be a coder” and “can barely write a HelloWorld program”. I wrote a lot of text-based BASIC code in college. I wrote little things like a system utility for my TRS-80 Model I to make the cursor blink.

I did some more interesting things like some simple game programming with assembler for Z80 and learned the basics of Lisp, Ada, Pascal, Modula 2, Cobol, Fortran, etc etc. I entered computer programming contests in high school that required me to turn in boxes of punch cards!! In two breakneck days, I once wrote a cross assembler for my Radio Shack pocket computer. (Which had a querty keyboard, a form of Basic and undocumented access to machine code, but it had only a simple one-line LCD display of about 30 scrolling characters. Imagine that!!!)

I work in IT, but not as a programmer. Along those lines, I wrote some Java "persistence" code (the layer of code that handles database access) for a project back in the Java 1.1 days, so I used to know a little about a subset of Java. But every attempt I made at a real GUI app turned out pretty messy and went nowhere. GUI design with Visual Basic in MS Access seemed really easy, so I gave that a try. But once I got started, it just didn’t seem worth the effort because it seemed too hard and uninteresting to justify the time required.

Okay, enough fessing up. You know my background now. I’ve dabbled a lot. I even did some interesting things for fun before GUI and OO were popular. But the times have passed me by, I want to get my foot back in. My PDA is just the motivation I needed. It's something I use every day.

That motivation is increased by the existence of SuperWaba. It seems to have become pretty popular, is well thought of, and I just love the whole concept of great software provided free by the software development community for the community.

The goal is to get up to speed on the basics. I won’t worry about distributed computing and fancy Java frameworks and app servers. I just want to learn to write a real program so I can do simple stuff on my Palm. Maybe I’ll even be able to give something back to this Palm community that’s provided all that cool software I use. And in the process, I get to program and play with my PDA, so I figure I’ll enjoy the journey. My biggest hurdle might not even be learning what to do. It might be the challenge of remembering that there are much more important things going on in my life, like the people I care most about, so the time I spend on this effort must be limited.

If you’ve actually read this far, you’re definitely my target audience, because the average person would have already said “Boring!....”

But you’re obviously not the average person. You’re either curious about what’s going to happen or you also feel those same longings to program on your PDA. Maybe you even want to follow along and do a little Palm programming yourself. Who knows?... Maybe this exercise will inspire you to be one more freeware coder for the Palm community.

Next Time: INTRODUCTION II (Some more information about where this is going)