It just means results have to be saved earlier than onPause(). The design pattern sometimes results in tiny content provider updates where the performance hit is an issue I'm still learning about. The key, "When you are saving your data you are storing it in a content provider, not returning it as a result" is subtle yet instructive.
Thanks! On Mar 31, 7:31 pm, hackbod <[EMAIL PROTECTED]> wrote: > Yeah for prompting dialogs I believe our approach is to have ok and > cancel buttons, with back meaning cancel. These are very different > than editing screens, where there is actually some concrete thing you > are operating on. > > These details of the UI have still been in flux; it's not something I > am involved with a lot, so I can't really give you concrete answers > for these details of UI conventions. > > On Mar 31, 5:05 pm, Peli <[EMAIL PROTECTED]> wrote: > > > Ok, thank you for the hints. > > > In my case, I display a subactivity in form of a dialog for entering > > connection settings. Pressing "back" returned to the main activity > > that reconnected with the new settings. > > > So I guess the best is to introduce the "OK" and "Cancel" buttons, and > > have pressing "back" meaning "Cancel" in a dialog, right? (so the edit- > > in-place model really applies only to main activities, and not to > > dialogs as I mistakenly assumed...) > > > Peli > > > On Apr 1, 1:14 am, hackbod <[EMAIL PROTECTED]> wrote: > > > > On Mar 31, 1:38 pm, Peli <[EMAIL PROTECTED]> wrote: > > > > > If the design philosophy is "save on back", then why does this default > > > > to > > > > RESULT_CANCELED? > > > > Activities only return results when the caller is asking for something > > > -- typically the user picking an item like a contact, a media file, > > > etc. When you are saving your data you are storing it in a content > > > provider, not returning it as a result. > > > > > My workaround is to call "finish()" in the "onPause()" method, right > > > > after "setResult(...)". > > > > You almost certainly don't want to always call finish() in onPause(), > > > you can be paused for many reasons: the user pressing the home button, > > > the device going to sleep, etc. > > > > The key thing is that while being paused, you need to have your state > > > saved away so it can be recovered if the process has to be killed and > > > your activity later restarted. This is one of the motivations for > > > using an edit-in-place model, in addition to the fact that the user > > > can easily be distracted from your applications (by a phone call for > > > example) and not return any time soon to what they were doing. > > > Typically this can be handled by either writing the data so far, or > > > storing a "draft" record that the user can go back and complete (for > > > example if composing an e-mail). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
