If what you're concerned about primarily is saving
the government's database from crashing ... well,
first I'd revise the program that doesn't handle
the missing field ... but second, I'd write a
custom conduit that refuses to sync records that
are missing "required" fields.
On the handheld side, you don't have to prevent
them from going to calc -- you just have to prevent
them from syncing records w/o zip codes.
Some applications remember which form they were
in before the switch. Don't go back to the "main"
screen, go back to the record screen that was
in progress at the time of the switch to "calc".
The second piece would be to keep two databases,
"scratch" and "main". Until the record satisfies
all criteria (e.g. must have zip code), it stays
in the scratch db. If you implement the "return
to record form until done" described above, this
db will only ever have one record in it -- the
one currently being entered. If you aren't
restrictive about the forms, then your main screen
will have to give you access to the vetted
records (main) and the incomplete records (scratch)
separately. (I'd go for the restrictive approach
myself).
To recap:
You can switch away from your census app, and
switch back -- but you can't leave the record
entry form until you've satisified all the
criteria. Even if the user syncs while switched
away, only the main db gets sync'd to the "real"
database, not the scratch db.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
> -----Original Message-----
> From: Scott Johnson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 31, 1999 11:19 AM
> To: Palm Dev Forum
> Subject: Strategy for navigation & validation
>
>
> Here's a problem to think about. Say I'm writing an address
> book style
> application for the 2000 census. It has a Done button on the
> Edit form,
> uses edit-in-place on its records, the usual stuff. When the
> user edits
> a record and then presses (say) the Calc button, then the
> current record
> is saved and the organizer switches to Calc. So far so good.
>
> But then I find that if the user happens to get a record only half
> entered and forgets the ZIP (postal) code, and saves the record by
> pressing Calc, then does a HotSync, it sadly causes the government's
> Microsoft SQL Server 7.0 database to crash and lose tens of
> millions of
> records of 2000 census data. Not good.
>
> So we need to >force< the user to enter the ZIP code (somehow) before
> the record gets synchronized, but in a Palm Zen-like manner,
> where force
> is not usually considered a good thing. How?
>
> When the user taps the Done button I can pop up an alert
> telling them to
> go back and enter the missing ZIP code. Easy.
>
> But when the user taps Calc to save >and< exit, should I put
> up the same
> alert and halt the app switch? This feels wrong. The user
> tapped Calc
> and didn't get Calc and doesn't feel the Zen of Palm.
>
> I could change the logic so when the user taps Calc the
> current ZIPless
> record is >discarded< before switching to Calc, with no alerts. Then
> the user gets his Calc but also loses a record he thought got saved.
>
> Or I could do something like the previous, but pop up an alert
> confirming that the record is to be discarded before
> switching to Calc.
> Again, an intrusive alert and not a seamless user experience.
>
> Hey, I could even "save" the ZIPless record in a sort of limbo state
> where it won't synchronize but will be editable after the
> user finishes
> Calc and returns to my program.
>
> I'm not finding an elegant hand held solution. Suggestions,
> discussion,
> official guidelines would be appreciated.
>
> -slj-
>
