Max/Aaron, Thanks for the comments. More details below.
> The backend relays totally on the Palm app to do the validation? This is bad. > Because it can still creates problems when you have a bug in your app. It > doesn't matter what correct values the user input. I'll take my chances. The backend is _very_ brittle and it is much easier (and more cost effective for the customer) for me to fix small inconsistencies on the Palm side than to have big iron DBAs code up new data validation routines on the server side. "Client-side validation of data is bad because you might have a bug" seems a little bit of a ridiculous claim . . If you are dumping data into ancient DBs, you need to make sure your data is correct before you ship it off. In this case, other validations aren't really an option, and in the general case are an opportunity to introduce more bugs. What if your server-side validation has errors too? Client-side validation is fine. Just make sure your code is solid :) > <snip> > > you can get around this by good design. I'm not going to argue good vs. bad design :) Part of coding is the fact one has to work within the constraints of the people paying the bill :) And I've provided more details to hopefully show you why ignoring appStopEvent seems necessary. The real issue here is: when the user is editing a record, if they try to switch out of the app, the app needs to validate the data, and not allow the user to exit the app if the data is invalid. The two ways I can think to do this are 1) to trap appStopEvent, validate the data, and if it is invalid, not allow the user to leave the app or 2) just don't allow the user to exit while editing records. In both situations, I would be ignoring appStopEvent and my question about the impacts of passing on appStopEvent still stands. Believe me, I've thought of both your options already, and they don't work in this case :P More details below. > > why dont you store the active state of the data entry and when you > re-enter the application put the user back where they were with the > data they had? > 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. > > if you have a beam receive.. it'll jump out to the launcher > when done > [ie: appStopEvent].. if you want to do it this way, you'll have to > disable beam receives... Actually, you don't have to disable beaming. Beam receive works fine. The incoming app is saved. The only difference is the app doesn't switch to the launcher. I coded it up and checked :> > too much depends on appStopEvent :) its best not to mess with it :P > design around it. I agree. I'm trying to understand the impacts of ignorning appStopEvent given my requirements so I can _design_ the best solution :) Cheers, -DGA -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
