Why C++?

As you might know, most palm development (and most palm developers for that matter) only use C for their projects. We have chosen to use C++ for all our projects for the following reasons:

C++ allows us to use a modular design and implementation process.
- We can build, test and gain approval on the application in small independent chunks, and cleanly wire those chunks together.
We use an iterative, rapid application development (RAD) process to design your application with you.
- This allows you to review your application build process along the way, and make changes without those changes impacting the entire application.
It allows us to use multiple application features in combination to achieve solutions that would otherwise have required extra, separate features.
We have built (and extensively tested) a library of common UI classes that allow us to rapidly build an application in half the time of traditional C development.
- This class library has been used on multiple commercial and shareware projects, and has been automatically tested by a process called "Gremlins" to more than 1,000,000 user events.

What all of this means to you in a practical sense is that our development cycle is shorter and the resulting code is smaller, which means a more robust application for less money. If you would like to discuss this in more detail, please If you are not sure why this is important, or gives you a better application, contact us and we will be happy to discuss and explain the benefits of Object Oriented programming.

Isn't C++ fat and slow?

It can be if careful attention is not paid to the design of the fundamental object classes. Many C++ foundations are meant to run on multiple platforms, and they suffer one of two fates:

They try to support every feature of each operating system, and they become huge because of all the redundant features that require unique solutions.
They only support a small subset of common features across the platforms. This means there is limited functionality available.

In addition, many frameworks attempt to solve application functionality with shared libraries of routines. Because these routines must work on multiple types of devices, they cannot use any of the native support built into the device. This is why many applications that run on Windows have a different look and feel (maybe different buttons, or scrollbars that look different). This can be a major problem for users, as the application looses some of it's intuitiveness.

So what makes your library better?

Our application framework only runs on the Palm OS. We have designed it support all functionality of the Palm OS, but only the Palm OS functionality. It is very small and lightweight, because there is no extraneous device support required.

And it is lightening fast, because we use the native API calls built in to every palm device for screen drawing, database access, and every other palm function. But we have extended those built in functions to provide additional functionality, and to generally make the device easier to write programs for.

Why don't you use something like AppForge?

We have extensively evaluated AppForge to see if it could be used for our products, and in our opinion, AppForge does not produce high quality Palm OS applications. Consider the following comparison of our C++ toolkit vs. AppForge, done of a basic single form sample application:

	C++ Toolkit	AppForge
Size of Executable	15K	347K
Speed to execute 10,000 Gremlins	3 min 21 sec	10 min 24 sec
Fully tested product	Yes	No

AppForge is a tool that allows you to write Palm applications in Visual Basic. It's benefits are Basic is an easy language to learn, but once you have mastered C++, it is as easy to use as Basic. AppForge's drawbacks are that it creates very LARGE application files. 347K is a significant amount when you consider many palms only have 1000K of program storage. Another drawback is the speed. It is more than 3 times slower than a comparable C++ application. This results in sluggish behavior to the user, and can really cause problems if your application needs to do any data manipulation or long calculations.

The more concerning problem with AppForge is that you cannot run it on the palm provided development and debugging tool called Emulator. This is a PC or Mac hosted environment that allows developers to test their applications, and it does alot of error checking (things like accessing memory that you don't own) that the actual devices don't do. The idea is developers use this tool to ensure that their applications are bug free, and will not crash on future palm devices. Whenever you attempt to run any AppForge application on the Emulator, you are presented with the following message:

This indicates two fundamental problems, the first the application will break in a future version of the Palm OS, requiring your application to be updated and redistributed to your users. The second, and more serious problem is that AppForge, Inc. has obviously not thoroughly tested their development products on the emulator. This is absolutely required if you want to ensure a bug free implementation. It is the only way to verify you have no sinister memory leaks in your application.

OK, well how about JAVA?

Although JAVA has some promise on the palm and other small platforms, it is still not there yet. Java suffers some of the same size and speed problems as AppForge, a small sample application was 394K and was noticeably slow to respond to user input.

Java on the Palm also suffers an identity crisis. Applications built on the current release of the Java CLDC for Palm noticeably do not look like palm applications. Their treatment of windows, dialogs, buttons and other user interface items clearly indicate they are NOT using the built in palm UI widgets.

Info on this comes directly from the documentation that SUN provides: "Note that CLDC is intended to serve as the “lowest common denominator” building block for various kinds of resource-constrained, Java Powered™ devices. As such, CLDC is not a complete, self-sufficient solution, but it needs to be complemented by profiles...GUI libraries that are not officially supported by Sun. The official GUI libraries for Java 2 Micro Edition are currently being defined through Java Community Process (JCP)."

These libraries are TBD. Until there is a more complete Java implementation for the Palm OS, we do not recommend it for production level applications.

If you would like to discuss these or other topics with us, please contact us.