I've been watching this thread with great interest, as my app has much the same issue as Dane's. Not even sure where to start...
> From: John Marshall [mailto:[EMAIL PROTECTED]] > consider a half-edited record not to be committed. [...] > If they do a sync when there's such a half-edited record, > it won't be synced: you probably want to put a note in the log Alas, for at least some enterprise-class applications [1] this is simply not acceptable. The user *must* somehow be informed that their record won't sync *before* they attempt to sync, and they almost certainly have no intention of synching until their record is ready. I'd be laughed out of any design meeting here for proposing any variant of the "don't sync it and only tell the user afterwards" model. There's a Zen of Palm but there's also a certain Zen of the enterprise software as a whole [2,3] that must be respected as well. Consider a scenario. User is on a sales call and enters a $1M+ quote into his handheld sales app. User wants to sync it ASAP to the corporate enterprise database (for safety, recognition, whatever). User can even do so wirelessly. User forgets to tap Save (which normally does the validation) but just switches directly to the launcher (which also normally saves) and launches sync. But user forgot to enter a critical field, say customer phone number. Record is *silently* tossed in the "don't sync" database. Sync may take a few minutes (depending on bandwidth and data volume) but at the end, the $1M+ quote has not been uploaded to the corporate system. Does the user notice the note in the log saying so? Maybe, maybe not. Either way, again this simply would not fly with the customers for my app. And yes this is a realistic scenario, if the app is from a company that knows a thing or two about mobile sales force automation already [4]. At the very least, I must at least *inform* the user that something is amiss when they try to exit. Maybe not trap them in the app permanently, but at least pop up an alert saying "Phone number is missing, this record will not be synchronized until you fix it, OK?" That would be the minimal acceptable amount of notification. How? Best way I know is to trap appStopEvent and pop up the alert. Maybe give them an option to stay in the app or to continue the exit. But of course now we're back to the original question of whether trapping appStop is "legal". And as far as I can tell, it does work quite safely, technically speaking. > I read this sentence as "An application MUST respond thus; > otherwise the system's behaviour is undefined" I read it the same way as the rules of "you should use only documented APIs" and "you should have a menu bar" and "you should support Find" where the real answer is "but you can deviate if you have compelling reasons and know what you are doing." AFAIK the issue of quashing appStop is entirely in the realm of user interface design rather than one of actually breaking anything. -slj- ----- [1] http://www.siebel.com/products/sales/siebel_mobile/palm.shtm [2] http://www.siebel.com/siebel7 [3] http://www.siebel.com/products/sales/index.shtm [4] http://www.siebel.com/about/index.shtm -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
