Speed or compatibility. It’s the ultimate compromise faced by software developers looking to create the next killer business application, or even the next hot action game. I faced it every day as an operating system programmer in the early 1990s: Do I utilize the API to retrieve the password the user just typed in, or do I go directly to the screen buffer and grab it myself? One choice ensures compatibility with future versions of the operating system, albeit at the sake of speed. While the other choice speeds things up a bit — a worthy goal with more than 30,000 users signing on in a corporate environment — but means I’ll definitely be changing some code when the next release arrives.
Palm developers face similar tradeoffs, and Palm intends to give them the means to implement the best choice for their application, whether it be increasing speed or ensuring compatibility. With the upcoming release of Palm OS 6, developers will have the ability to produce native ARM-compatible code, or continue to use the Palm Application Compatibility Environment, or PACE, introduced in Palm OS 5 to provide a level of abstraction from system code that ensures backward compatibility and portability over a wide range of Palm Powered devices.
To be fair, Palm OS 5, which brought Palm Powered devices into the world of ARM-based processors, also allowed the ability to bypass the overhead of PACE and write code directly for the processor, using something it calls ARMlets. But ARMlets aren’t easy to code, and PalmSource recommends using them only in “worst case” scenarios, where time-critical portions of an application are experiencing performance problems.
Developers I spoke with at the recent PalmSource Developer Seminar in San Mateo had mixed feelings about Palm OS 6’s native code support.
“We’ll take advantage of [native code] where and when we can,” said Catherine White, president of Llamagraphics, makers of LifeBalance. “We can always use more speed.”
Stuart Malone, Llamagraphics’ chief technology officer, agreed, citing intensive calculations over an entire database as an example of where native code may be useful.
However, one IBM software engineer I spoke with, who’s involved with enabling WebSphere Anywhere on mobile devices, questioned the need for native code. He said that with the 300 and 400 Mhz processors found in today’s handhelds, native code just doesn’t seem to be as important an issue as compatibility or portability. Still, he wondered whether IBM’s decision a couple of years back to go with the Compaq iPAQ Pocket PC for a mobile version of its ViaVoice application might have been different had Palm Powered devices with adequate memory and faster processors, and native code support, been around.
“It takes a lot of horsepower for speech to text,” he said. “Especially if you load a 32 megabyte lexicon that also handles it contextually. Sometimes it helps to write as close to the hardware as possible.”
In fact, both points of view may be correct. In most cases, coding “close to the hardware” is simply not the answer. For most applications, running on as many different devices as possible, and ensuring that it will run on the next release of the OS, is much more important than speed.
Ms. White and Mr. Malone agree. They spent several hours testing LifeBalance in the PalmSource Developer Seminar lab on devices they ordinarily don’t have at their disposal, devices such as Alphasmart’s Dana and Tapwave’s Helix prototype. Their app ran fine.
“Hats off to PalmSource’s development team,” said Ms. White.
Still, Ms. White and Mr. Malone acknowledged that they’ll “go native where appropriate” and make the changes necessary to run on Palm OS 6.
“Palm OS 6 removes a number of barriers,” said Ms. White. ” We’ll definitely be able to take Life Balance to the next level.”