ZBerry Game Play

Please take this for what it is worth… a silly little hobby project of mine that may or may not continue.  If you really like this, feel free to comment.  If you find bugs, source code patches are welcome, but complaints are not.  My hope is that is that it is worth more than its price (FREE) but given that I’m making nothing from this I hope that everyone can understand there is absolutely no support implied or available.

If you have Snow Leopard on your system, please do not install the patched version of PPPD.

I will keep the replacement package available for those like myself that are still running Leopard on their systems.  In addition, there is a version built for Tiger.

Before Facebook Installation

This shows the menu in this application before installing the Facebook application.  After installation, you can see that the Facebook application has added a new menu item to this application.

After Facebook Installation

This is a pretty nice feature of the API.  Although I don’t have actual code to show for this, my assumption is that this is provided by using:

• ApplicationMenuItem
• ApplicationMenuItemRepository
  • MENUITEM_MESSAGE_LIST

API’s like this allow for incredible integration with the rest of the applications on the device, opening up many very interesting opportunities.

As a developer, I’m much more disappointed developing using the BlackBerry native API than I expected I would be when I started playing with my little ZBerry project.  Marcus Watkins offers excellent insight into the world of BlackBerry development, which I won’t try to rehash here.  The part that I find incredibly frustrating is the lack of decent reusable user interface controls.  As Marcus details in his blog post, the provided UI functionality has the bland look and feel of the base operating system.  Even more frustrating to me is how little flexibility there is even within the standard controls.  For instance, I wanted to provide the user the ability to customize the font used in the text display.  Using the standard functionality yields the following dialog.

Initial Fonts Dialog

Wow, look at the size of that dialog relative to the screen.  All of that wasted space.  So much space could be saved if:

• The extra space between the label and field contents wasn’t there.
• The OK/Cancel buttons were laid out horizontally instead of vertically.

What’s worse is that the, while the change listener support attached to those fields is capable of updating the story font on the fly, the user can hardly see the text.  Thinking there had to be a way to control things a little bit better, I tried to turn off the label text.  If I could lay out the two fields side-by-side, it might be better.  Unfortunately, there appears to be no way to do that.  Setting it to blanks yields a dialog that is even a bigger waste of space.

Font Dialog Attempt #2

Given that there is vertical and horizontal layout field management, why must the label and text field be tied together like this?  I’m sure some of it boils down to legacy hardware support for things like the trackwheel.  But it would be nice to be able to selectively break free of those restrictions.

While the API would certainly allow me to build a version of these controls from scratch, that seems a silly thing to have to do.  Doing so implies the need to account for the various input options (trackwheel, trackball, keyboard, etc), do all of the rendering and focus management that these controls are already handling.  Admittedly, this is still an issue of “look and feel”, but it is disappointing to see something so simple be neglected.

With that said, the text input and output controls are pretty impressive, saving effort on that side of the implementation.  I guess it should come as no surprise that the strongest parts of the BlackBerry API revolve around features such as email that have been in the platform for a very long time.

ZBerry Library Selection

I need to add some suspend/resume support before this thing becomes really very usable on a phone, but some progress anyway…

protected void paint(Graphics graphics) {
// Stash the current colors and invert them for the
// background fill
int currentBgColor = graphics.getBackgroundColor();
int currentFgColor = graphics.getColor();
int w = getWidth();
int h = getHeight();

graphics.setColor(currentFgColor);
graphics.fillRect(0, 0, w, h);

graphics.setColor(currentBgColor);
graphics.setBackgroundColor(currentFgColor);

// Draw the pieces of text
int midHeight = h / 2;
int midWidth = w / 2;
buffer = new StringBuffer();
buffer.setLength(0);
buffer.append(“Moves: “).append(moves);
graphics.drawText(
buffer, 0, buffer.length(), w, midHeight, Graphics.VCENTER | Graphics.RIGHT, w);

buffer.setLength(0);
buffer.append(“Score: “).append(score);
graphics.drawText(
buffer, 0, buffer.length(), midWidth, midHeight, Graphics.VCENTER | Graphics.HCENTER, w);

graphics.drawText(statusText, 0, midHeight, Graphics.VCENTER | Graphics.LEFT);
}

I had expected three pieces of text, aligned right, left and center.  Instead, I ended up with:

Broken Text Alignment

The Graphics#drawText methods look similar to:

public int drawText(StringBuffer text,
int offset,
int len,
int x,
int y,
int flags,
int width)

The trick with this API has to do with that last parameter.  The width parameter is used to define a bounding box.  The x and y parameters define the top-left corner of that bounding box.  Horizontal alignment flags (HCENTER and RIGHT) do the alignment relative to the bounding box defined by (x, y, x + width, y + height).  To get the same behavior I had expected, I needed to set the bounding box to include the complete width and then specify those alignment flags.  The correct code now looks more like the following:


protected void paint(Graphics graphics) {
// Stash the current colors and invert them for the
// background fill
int currentBgColor = graphics.getBackgroundColor();
int currentFgColor = graphics.getColor();
int w = getWidth();
int h = getHeight();

graphics.drawText(
statusText,
padding,
midHeight,
Graphics.VCENTER | Graphics.LEFT);
}

graphics.setColor(currentFgColor);
graphics.fillRect(0, 0, w, h);

graphics.setColor(currentBgColor);
graphics.setBackgroundColor(currentFgColor);

// Draw the pieces of text
int midHeight = h / 2;
int paddedWidth = w – (2 * padding);

buffer = new StringBuffer();
buffer.setLength(0);
buffer.append(“Moves: “).append(moves);
graphics.drawText(
buffer,
0,
buffer.length(),
padding,
midHeight,
Graphics.VCENTER | Graphics.RIGHT,
paddedWidth);

buffer.setLength(0);
buffer.append(“Score: “).append(score);
graphics.drawText(
buffer,
0,
buffer.length(),
padding,
midHeight,
Graphics.VCENTER | Graphics.HCENTER,
paddedWidth);

}

This results in expected text layout:

Correct Text Alignment

A few years ago, I created a JavaME MIDP Z-Machine interpreter called ZeeME.  This was an interesting little project at the time to learn my way around programming for these small devices, but actually using it was painful at best.  Typing natural text using triple-tap just wasn’t enjoyable.  With a QWERTY keyboard on my BlackBerry Bold, it seemed like this might be a good time to resurrect this project yet again.

I’ve made some progress in building this out, but there is still a very long way to go.  Here’s a snapshot of the emulator running the game “Minizork”.

Watch here for more to come…