If I understand it correctly, you need to make sure any record that user changes has to be validated and synced to the backend server. You have had the conclusion that you have to trap the appStop event. Fine, however there are other bigger problems with your application:
1. The record is synced to the server => Not in real time 2. It is not acceptable to discard a record that has been changed on device. All changes must be saved and validated. Now imagine these when there are data modified on the device but before sync: 1. The user dropped the device dead. 2. Static zapped the device. 3. The device is stolen. 4. Battery is drained compeletely. 4. Other causes that render the data on device unrecoverable. What can you do with these? The data is lost and IT IS UNACCEPTABLE to the customer. Your application has bigger design flaw. It is like you are totally ignoring a bullet hole in your tire and trying to fix only some tiny cracks. For critical data, you need real time processing. Max --- "Avilla, Dane" <[EMAIL PROTECTED]> wrote: > > I actually have this implemented (so the app returns to the previous edit > state), but the customer didn't want it that way. I agree that this isn't > the "Zen of Palm" way of doing things, but there are several requirements > that dictate this course of action. > > Here's the reason: sets of records are assigned to a particular user. The > record sets can be reassigned to a new user at the server, so on any > particular sync, a user could find himself with another set of records, with > the old set removed. So any record that the user is in the process of > editing could disappear during the next sync > _and_the_edits_would_not_be_saved_. This is unacceptable for the customer. > > Because the record could disappear during any sync, changes that the user > could have made to an existing record must be validated before leaving the > app. > > So then with your suggestion using the temp database, the following scenario > is possible: > > - User syncs recordset to device > - User modifies a record which creates a temporary record in a temp > database, and the temp record is actually modified by the user. > - User leaves the application to "lookup a phone#" while editing, so temp > record has modified data which is invalidated. (If I validate on > appStopEvent, I have to be able to ignore appStopEvent if the data is > invalid). Original record is still unmodified. > - Now, if the user syncs before reentering the app to complete the edits > (which will validate the data and write the modified data in the temp db to > the original record), and the system administrator has changed the user's > recordset, the next time the user starts the app, they will not be able to > complete editing the record, because the record will no longer be on the > device. The modifications to that record would essentially be lost, and > this is unacceptable to the customer. The information in the records is > very critical (of course) and all changes must be saved and validated. > > . . . so we are back to needing to trap appStopEvent. __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
