Last Wednesday I went to the PalmSource Developer Day at LinuxWorld San Francisco to check out PalmSource's progress on their new Linux-based mobile OS. I really should have flown in a day early because there was so much mobile Linux action happening on the expo floor and I barely was able to scratch the surface. Someone summed up this year's conference as being all about "stacks". I'd go one further and say "mobile stacks." PalmSource was sharing a lot of detailed information about their ACCESS Linux Platform and had demo phones and developer tools you could try out; an upstart called à la Mobile was touting a competing Linux platform; and then there were the incumbents, Motorola and Trolltech all jostling for position in the new and (dare I say it?) explosive mobile Linux phone market.
PalmSource was the big news, though. They had their native Linux platform running on real phones and finally starting to look like the modern successor to the Palm OS that many of us have been looking for. They also have their developer tools pretty well put together--enough for Linux and Palm OS hackers to design, code, and debug native Linux apps during three one-hour tutorial sessions using PalmSource provided Ubuntu laptops. I've published the first of three promised articles about my impressions of ALP on PalmInfocenter, but I thought I'd give a more developer-centric run-down here and offer up a Guy Kawasaki-style top ten list. So without further ado, here's my Top 10 Things for Developers to Love About ALP (Besides the Fact That It's Linux):
- ALP is standards-based. PalmSource has learned its lesson from the Palm OS Cobalt debacle, during which time they seemed to believe that everything had to be built from the ground up, in house. Apparently innoculated for NIH Syndrome by Linux, they are now using lots of tools and SDKs that are familiar, proven, open source standards. Some of these deserve their own places in the top ten list. For example...
- ALP is X Windows. Until now we didn't know whether they would put X on a crash diet or try to do the GUI on a direct-to-frame-buffer basis. Ultimately, they went with X and I've heard cheers from many corners about this decision. It makes porting existing Linux applications to ALP much easier and is probably a big chunk of well-tested code that PalmSource doesn't have to maintain by itself. There's probably some hit to performance and memory, but ACCESS considers it's top competitor to be Windows Mobile which has positively huge memory requirements. X will be worth its weight.
- ALP is GTK+. That thing I just said about how easy it is to port a Linux app to ALP? I mean easy as in a simple recompile. Now, granted we're not talking about compiling The Gimp to run on your phone, or many other substantial desktop applications written against the Gnome toolkit. This is a phone with limited memory, a small screen, maybe a touchscreen (but maybe not) in the hand of someone walking around town doing stuff. But in one of the developer sessions we took a stock Linux app called gWorldClock and rebuilt it for ALP without touching a line of code. GTK makes good sense on an embedded Linux system since it's layered and modular, unlike QT, which from what I understand is more monolithic. From a development standpoint, using GTK means you can design your GUIs with Glade, which seems like a nice graphical tool from the short time I've used it (reminds me of Constructor but with layouts). GTK also means you're developing in C instead of C++. I don't know about the rest of you but while I like OOP, C++ doesn't do it for me!
- ALP is legacy Palm OS, too. Well, we already knew that ALP would include built-in emulation of Palm OS Garnet. What we didn't know is how good this emulation will be. We still don't really, but I tried some of my own Palm OS apps in GHost and they ran just fine. Every other Palm developer I've spoken with (four of them) had the same experience (unless their app required Treo-specific libraries from Palm). I mentioned in my PalmInfocenter article that I didn't see a Graffiti input area for handwriting recognition in the simulator, but developer Donald Kirker who saw some Palm apps running on the demo phones assured me that the 240 x 320 screen included a dynamic input area as we've come to expect on Palm devices with rectangular screens. Looking good.
- ALP gets multitasking right. I know some people will differ with me on this one, but many, if not most mobile applications have no business taking up memory in a background thread once you leave them to run another application. ALP being Linux, it enables full multitasking: you can start an MP3 playing, then tell your RSS reader to get the latest blog posts, then check your To Do list while the other tasks continue merrily in the background. You can even pop up a little control panel from the status bar to skip to the next music track while you watch your RSS feeds load in the window behind. But the music player and RSS reader can do this because they were written to do so, not because it's the default behavior like with Symbian or Windows Mobile. The default behavior of a native ALP application is to exit (perhaps saving state to an application prefs database) and to give its memory back for the system to run the applications you care about. PalmSource was wise to leave this decision to the developer, who in turn could offer the choice to the user by popping up a quick dialog before the application closes. Phones are resource constrained devices and running out of memory is one of the most common causes of crashes or other poor behavior.
- ALP is a daemon lover. So, if you choose, your application can go from the active GUI thread into a background thread. Cool. But it's also possible to write apps that run completely headless. Daemons, as they're known in the Linux world. I'm not to sure how this will pan out, but it strikes me as a powerful thing to have services that run silently in the background, fetching live data off a network or GPS and updating a database for instantaneous access by one or more GUI applications. I've written here before about the need for a mobile service-oriented platform that stops developers from having to write the same code over and over. It seems like Linux daemons could be a fertile ground for growing a rich service ecosystem. What about a tiny web server or application server? Sounds crazy at first, but these could open up some creative and powerful new ways to use a wirelessly connected device.
- ALP is themable. It took entering a single tag in a manifest file to turn a drab, gray-looking GTK application into a richly themed one with colors, shapes, fonts, borders and backgrounds that matched all the other native apps running in the simulator. Themes are developed with scalable vector graphics so they can adjust to devices with different screen sizes. Should be fertile ground for user personalization. But the SVGs may be pre-rendered on the device for performance reasons, so don't expect Mac OSX-like dynamic resizing of GUI elements while you move the stylus around.
- Eclipse and Scratchbox are your friends. Readers know I'm fond of Eclipse, but I've really only used it for Java development. I was pleasantly surprised with the C development toolkit that forms the basis of PalmSource's new IDE, though. Users of the Palm OS Developer Suite will find it familiar, too. But what they won't find is the pain that so many experienced when they installed PODS on a Windows machine with another Cygwin installation: PODS screwed it up every time. Not anymore. First of all, if you're developing for ALP you'll be developing on Linux, not Windows, so no more Cygwin. But you'll also be using a cross-compilation tool called Scratchbox that enables you to have one build environment configured for ARM Linux and ALP while your host environment is set up the way you need it for your x86 box. No more interference.
- ALP's got a browser widget. Until now ACCESS has been best known for their powerful, Javascript-enabled, SVG-rendering mobile web browser, NetFront. That browser will now be integrated right into the ALP platform and even available as a widget to include in third party applications. Officially, this is only for internal use by ACCESS in developing their own applications like the standby screen and maybe the email client. But I've been told that a browser control will also be exposed as API at some point. Palm developers have sorely missed something like this.
- ALP has an SQL database engine. SQLite has been improved and becomes the standard for persisting data on ALP. Not only can you query with SQL, but the database even has a POSIX-style file system API that you can use with it. Palm OS developers who have had to roll their own relational database logic will cheer that they now have a fast and powerful RDBMS built right into the platform.
- ACCESS is aggressive. PalmSource, with its PDA pedigree, was a babe in the woods when it came to dealing with mobile phones and network operators. Not ACCESS. They already do business with most of the carriers and ODMs since their browser and other software is very widely deployed. They are also ambitious, publicly stating their expectation to have their software on fully 30% of all mobile handsets within six years. Note, this doesn't necessarily mean they expect ALP to be on all those handsets: ACCESS is counting its browser and other software products, too. But after spending some time speaking with CTO Dr. Tomihisa Kamada, it's clear that ACCESS expects ALP to be a major factor in extending this reach.
- ACCESS is interested in more than just phones. They already have software for automobile telematics and home entertainment devices, and they expect to extend Linux and parts of the ALP SDK into these and other kinds of consumer devices. Dr. Kamada confirmed my suspicions that ACCESS sees mobile phones not just as communication devices, but as remote controls for your home and ways to extend home entertainment systems outside the confines of your home. I like developing for a platform with a big vision behind it.
Ok, I lied. That's twelve things for developers to love about ALP. Naturally, there are some clouds on the horizon, too, including the big question of whether Palm Inc will use ALP on future devices. I'll look at some of those in my next post. But overall, I am pleasantly surprised with the progress PalmSource showed at last week's LinuxWorld and look forward to seeing how this platform evolves between now and when it's released to licensees around the end of the year. When will 3rd party developers be able to download the tools and start developing ALP applications? Officially, "the first half of 2007."
Posted by cervezas at 20:48:06. Filed under: Mobile Linux
Comments
Add Comment