[android-developers] Re: Life cycle of activities updating a database
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 -~--~~~~--~~--~--~---
[android-developers] Re: Life cycle of activities updating a database
It just means the data has to be saved in the provider earlier than
onPause ("cancel" in this context). The pattern sometimes results in
tiny content provider updates where the performance hit is an issue
I'm still learning about. They key, that "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, 5:14 pm, 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
-~--~~~~--~~--~--~---
[android-developers] Re: Life cycle of activities updating a database
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 -~--~~~~--~~--~--~---
[android-developers] Re: Life cycle of activities updating a database
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 -~--~~~~--~~--~--~---
[android-developers] Re: Life cycle of activities updating a database
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 -~--~~~~--~~--~--~---
[android-developers] Re: Life cycle of activities updating a database
I also wonder what the correct implementation would be.
If the design philosophy is "save on back", then why does this default
to
RESULT_CANCELED?
My workaround is to call "finish()" in the "onPause()" method, right
after "setResult(...)".
This results in 2 calls to onActivityResult(..): One with
RESULT_CANCELED, and one with RESULT_OK with the correct bundles
passed.
Furthermore, LogCat says:
W/ActivityManager( 6246): Duplicate finish request for
HistoryRecord{4009e378 {org.openintents/
org.openintents.shopping.share.ListShareSettingsActivity}}
Since there is a warning, this can not be 100% correct, but it seems
to work. I wonder what the "correct" solution would be - to pass a
bundle from a subactivity when the user presses the back button...
Peli
On Mar 27, 5:54 am, tenacious <[EMAIL PROTECTED]> wrote:
> I've encountered this paradigm too and would also like to know why
> results can't be set as late as onPause? Hopefully somebody
> knowledgeable can chime in...
>
> Having the differing behaviors between "confirm" and onPause() is
> causing pain because I want to have the "cancel" button act like
> confirm (the user is always saving unless explicitly clearing all
> fields or clicking a cancel/delete button)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: Life cycle of activities updating a database
I've encountered this paradigm too and would also like to know why results can't be set as late as onPause? Hopefully somebody knowledgeable can chime in... Having the differing behaviors between "confirm" and onPause() is causing pain because I want to have the "cancel" button act like confirm (the user is always saving unless explicitly clearing all fields or clicking a cancel/delete button) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
