SXSW and Implementing Global Find
First, the big news is that my schedule application for the South by Southwest 2002 conference is now online at http://www.sxsw.com/pda/. This is a standard-mode application built using the Object Library for Palm OS and CodeWarrior for Palm OS V8; yes, I'm eating my own dogfood. I'm going to be posting a few articles inspired by building this application over the next week.
Implementing Global Find
After getting version 1.0 out on Friday, my partner and I realized that we needed to get a find function into the program. For most programs, it is better to hook into the global find feature of Palm OS rather than implementing your own find method. It fits better with the "Zen of Palm", and its one less user interface element you have to implement and document.
PalmSource has a really useful article in their recipes series. This is a good start, and it has some useful code. To implement find, you need to handle two launch codes: sysAppLaunchCmdFind and sysAppLaunchCmdGoTo.
If you're using POL, you need to start by changing your application object. Handling launch codes other than the normal launch requires using the POL::CPalmStApp template class. When you derive from this base, you can override the GotoLaunch and FindLaunch methods to write your handlers for these launch events.
The sysAppLaunchCmdFind code gets sent to your application as a non-global launch code. This means you can't use global variables. If you're using POL, you'll need to limit yourself to the classes implemented in the first library, since that's all that gets put in the first segment.
In the SXSW application, we had nine databases that each held information about the conference. Searching all the events meant going through each of the three events-by-time databases, looking of the info record for each event, then doing string searchs in those info records. When we found a match, we formatted up a string with the event date and title, and we pushed a lot of information back into the find match engine that would help our goto routine actually bring up the right details dialog.
On the GoTo side, it was a bit harder. The bug that caused us to release a 1.1.1 version hours after the 1.1 version was really nasty. When a user taps on a match, different things happen depending on if the application that hosted the match was the current app. If your app is running, it gets sent a sublaunch. If it's not running, the current app is stopped, and your app gets a full launch.
The code I wrote assumed that I was always relaunching, since I'd put the "go to details" logic into the startup code using some global variables. If I tried that with the sublaunch, I ended up creating some objects multiple times and having conflicts due to my view database being opened for read/write twice. I fixed this by having the goto handling code check for the sublaunch. If it saw the sublaunch, it would just take the goto parameters, copy them to the heap, and relaunch my application using a SysUIAppSwitch so it looked like the case where my app wasn't the current one.
More about SXSW Schedule later...
Send feedback to combee@techwood.org
Copyright © 2004 Benjamin L. Combee
Palm OS is a registered trademark of PalmSource, Inc.
Metrowerks and CodeWarrior are registered trademarks of Metrowerks Inc.
The views expressed on this website/weblog are those of mine alone and do not necessarily reflect the views of PalmSource or Metrowerks.

qwertYAK / frobnovich
|