In an enterprise setting, it's often desirable to control the use of the device quite rigidly. At my company (and many others), Palms are used as portable computers rather than PDAs, per se, and Palm's design guidelines simply aren't appropriate for us.
Beaming and alarms may or may not be a problem, depending on the other uses the device is put to. You're right though; without creating your own ROM, it's pretty difficult (read 'impossible') to prevent a knowledgeable user from exiting an application. The best one can do is to prevent clumsy or malicious-but-unformed users from breaking out. As you said, the reset button is the ultimate weakness; presumably, every 'dedicated' app has code to restart itself after a soft reset (as ours does). Hard resets are another matter. My company uses SPT1x40 in our distribution centers, and Symbol helped us out here by making the hard reset so difficult to accomplish that even I have difficulty with it sometimes (which should not be construed as a compliment to Symbol, by the way). Regards, Jeremy Neal Kelly Software Engineer Peapod "Mark A. Peters" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Aren't there also other ways an app can be quit? I'm thinking of the > arrival of data via beaming or bluetooth, and the triggering of an alarm > yielding a dialog that allows switching to some other app. > > Perhaps things like this come down to an app stop event showing up in the > app's event queue, and so ignoring those will plug the hole. > > And of course, a reset will quit an app no matter what. > > In any case, isn't it considered bad design for a Palm app to prevent a user > from quitting? I suppose a device dedicated to running one app is an > exception. > > Mark Peters -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
