The Project

In order to learn a new platform, I always like to have a project to build.  Looking around, I didn’t find any iPhone DAAP clients for servers like the Firefly Media Server.  I’ve been trying to build a DAAP client as my learning experience.  I have a good chunk of the navigation working at this point.

DAAP Player

The iPhone Core Data support is amazingly powerful, providing a good chunk of the underlying data source support for table views like those in the client.

DAAP Albums

There is still much to be done, but the iPhone SDK has provided a large amount of functionality for a very small price.  As always, I continue to be impressed with the power packed into modern handsets.

Circus VIC-20

Looking back at this article publication, there are a couple of things that make it particularly interesting to me 20+ years later.

• My original program was written on the Commodore VIC-20 (5K of user memory!) and was rewritten for all of the other computers for the publication.  This happened behind the scenes and I was unaware until publication.  Not surprising, they also rewrote all of my descriptive text.
• This game was a clone of a game that was available in arcades and pizza places around that same time.  Had I done this in present day, this game would very likely not have been published due to copyright or other legal issues.

20+ years later, I’m still a computer programmer (software engineer?).  While I program less than I used to, it is cool that my hobby so many years ago has been able to be both a hobby and a source of income for so many years.

• Motorola
• Nokia
• SonyEricsson
• Research in Motion
• Several individual contributors

This new MTJ release has been included in the first service release of the Eclipse Pulsar project.  In addition, the Pulsar QuickInstall now includes an SDK from SonyEricsson.

As Christian pointed out via his email, now would be an excellent time to consider getting involved in the Eclipse MTJ project.  Even something as simple as being involved on the mailing list can help us out.  If you are a mobile developer using Eclipse Mobile Tools for Java, consider contributing a patch to provide a cool new feature or to fix the bug that annoys you the most.  Not a developer, but still want to contribute?  We can always use help with documentation and project marketing.  Pitch in and lend a hand!

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.

• The TmL project contains components that are useful on many mobile platforms, not just Linux. As the primary contributor to TmL up to this point, Motorola desires to expand the scope of the project to support other mobile platforms.
• The MTJ project contains some components that could be valuable to all mobile developers, not just those who use Java ME.
• Code for Eclipse Pulsar was placed in the MTJ repository due to timing issues. Since the Pulsar developers also work on MTJ, it seemed a reasonable location. There is a need for a more suitable and permanent location for this work.
• A new project, focused on the needs of all mobile developers has momentum, as previously seen from the excitement around Pulsar. By removing the artificial barriers of “Linux” and “Java”, we hope to provide a home for all Eclipse mobile developers.

It is easy to understand Motorola’s motivations in making this move, given their transition to the Linux-based Android operating system for many of their upcoming devices.  With that said, I do believe that this move is truly beneficial to the mobile development community.  While developers have to deal with the plethora of mobile device platforms and the associated fragmentation, consumers really only care about the results of development.  The more that the tools can help developers bridge the gaps between the various platforms, the easier it will be to get applications into consumer’s hand no matter what their device.

In many ways, this is a natural extension to my original goals of making EclipseME support all JavaME devices no matter which vendor provided those devices.  Of course, JavaME’s role in mobile devices has diminished significantly in recent years, so it makes a lot of sense to broaden the scope to other platforms.  For more information, take a look at the presentation or drop by one of the project mailing lists.

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.