On Mon, Dec 03, 2001 at 02:04:17PM -0800, Scott Johnson wrote:
> Record is *silently* tossed in the "don't sync"
> database.
[...]
> 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?"
I didn't say "silently". You're right of course: anyone worth their salt
would at least pop up an alert. But doing so would likely involve event
processing after appStopEvent, which violates my austere interpretation
of that Palm OS Reference quotation. Alas.
Really, I think the bottom line is that input validation (i.e., the
possibility that the data on an edit form can be in an invalid state) and
Palm Zen implicit edit form saving are simply incompatible.
>> I read this sentence as "An application MUST respond thus;
>> otherwise the system's behaviour is undefined"
>
> [...] AFAIK the issue of quashing appStop is entirely in the
> realm of user interface design rather than one of actually breaking
> anything.
And Neil Rhodes wrote:
> from a technical point of view, there's no problem in just ignoring
> appStopEvents.
Guess what, guys? I did actually have a reason for saying that! :-)
I think I now understand the problem David Kendall had last month -- I
partially had the wrong end of the stick in my postings at the time.
His application had a dialog with its own event loop that did the
"repost appStopEvent and close itself when it sees an appStopEvent"
thing.
This dialog had a field on it. Now suppose the user is in this dialog
and brings up the keyboard dialog, and then taps the Launcher button.
The keyboard dialog gets the appStop, reposts it, and posts a fldChanged
for David's dialog's field. David's dialog's event loop gets the
appStop, and reposts it (after the fldChanged), and closes itself
(the dialog).
Then the application's main event loop gets a fldChanged event *for a
field which no longer exists* and explodes.
There's various ways to explain the cause of this crash:
* Perhaps the main event loop should have been more robust and ignored
the fldChanged event that wasn't meant for it;
* Perhaps we should say "separate event loops are bad". Well, we all
do say this, and it doesn't help us in the form validation case anyway;
* Perhaps we should say that the fldChanged event should never have been
processed because (as far as David's app was concerned) it only ever
appeared *after* an appStopEvent had already been sent.
Whether he should have ignored it or not, I think it's fair to say
that David encountered an impossible field event precisely because
he *ignored* a preceeding appStopEvent. Thus I think it's fair to
say that ignoring appStopEvents does indeed cause technical problems
(at least in some circumstances).
I have a little more to explain, but I have to go now. More tomorrow,
if anybody's interested...
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
