[android-developers] Re: When is (or isn't) instance state restored ?
There is no way to do this. When you press back, your instance of the application is over, therefore there is no instance state to save. Perhaps you are saving something in instance state that doesn't really belong there? Persistent state and instance state are two different things. Data that needs to be saved into the persistent state should be saved in onPause, not onSaveInstanceState. Cheers, Justin Android Team @ Google On Jan 11, 7:45 am, Orde wrote: > What if we wanted to force the system to save the bundle when back > button is pressed? Currently I believe that > pressing MENU calls: > -onSaveInstanceState > -onPause > -onStop > > pressing back calls: > -onPause > -onStop > -onDestroy > > Ideally I would like to force my app to call onSaveInstanceState even > when back is pressed --~--~-~--~~~---~--~~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: When is (or isn't) instance state restored ?
What if we wanted to force the system to save the bundle when back button is pressed? Currently I believe that pressing MENU calls: -onSaveInstanceState -onPause -onStop pressing back calls: -onPause -onStop -onDestroy Ideally I would like to force my app to call onSaveInstanceState even when back is pressed --~--~-~--~~~---~--~~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: When is (or isn't) instance state restored ?
On Wed, Dec 17, 2008 at 8:30 AM, Peli wrote: > Also, assuming that the content of an EditText is stored in both, a > shared preference and the bundle, which of those has precedence? I don't think it makes sense to store it in both places. Pick one or the other, depending on the semantics you want for that state. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: When is (or isn't) instance state restored ?
I see a couple of problems with your scenario. While possible, its unlikely that an application is going to live that long in the background, unless you have a very unusual user. Secondly, data in a content provider can change at any time, even while your application us running. Whatever data you use in your application from a content provider (or any other source) needs to have an expiration lifetime that is reasonable for your application. Cheers, Justin Android Team @ Google On Dec 17, 8:30 am, Peli wrote: > The only possible complication is that it is also possible to save an > activity state through shared preferences (or a content provider) in > onPause() and retrieve that in onResume(), so there is a delicate > question which information to store in shared preferences (or content > provider) and which information to store in the bundle. > > Also, assuming that the content of an EditText is stored in both, a > shared preference and the bundle, which of those has precedence? > > (Probably the bundle has precedence, but consider the following > example: Application in the foreground; user presses Home, state saved > to bundle; one week later another app changes content of content > provider; two weeks later application is retrieved to foreground, uses > information of bundle and ignores changes to content provider..) > > Peli > > On Dec 17, 3:12 am, "Dianne Hackborn" wrote: > > > It really is not that complicated -- the system will at various points ask > > you to save your current instance state in onSaveInstanceState(), and if in > > the future it needs to restart your activity with some previous saved state, > > your onCreate() will be called with a Bundle containing the saved state you > > supplied in onSaveInstanceState(). > > > If you want to ignore this and do your own thing, you are of course free to, > > and your application won't behave consistently with others. Whether your > > users will care or not I can't say. > > > On Tue, Dec 16, 2008 at 11:33 AM, joshv wrote: > > > > Basically if you are interested in long term persistent state, ignore > > > the Bundle passed in onCreate - I don't pretend to understand the > > > reasons for why it is or is not null - perhaps they make sense to the > > > framework designers, but whatever the rationale, it doesn't make much > > > sense to store any state you care about in that default bundle. > > > > Use SharedPreferences or a database instead. > > > > On Dec 16, 2:47 am, jarkman wrote: > > > > Justin - thanks for the explanation. > > > > > I'm not making any allegation of impropriety on the part of the > > > > system, just trying to understand what the orthodox behaviour ought to > > > > be for a 'vanilla' app. > > > > > I had completely missed the distinction between leaving via 'back' and > > > > leaving via 'home', which may account for some of my confusion. I'm > > > > not sure our users will get that distinction either, but fortunately > > > > our state is pretty simple so they can't get too bemused. > > > > > So, just to check, is the plan that leaving via 'home' seems to the > > > > user like sending the app to the background, to be restored later, > > > > whereas leaving via 'back' is closing the app, so it next starts in a > > > > virgin state ? > > > > > Richard > > > > > On Dec 16, 12:18 am, "Justin (Google Employee)" > > > > wrote: > > > > > > Richard, > > > > > > If you save something into the bundle and hit 'home' (button with a > > > > > house on it), the system will always return a non-null Bundle to you. > > > > > If you don't save anything to the Bundle, I'm not sure what the system > > > > > will do. > > > > > > If you hit the 'back' button (button with the arrow), the system will > > > > > not call onSaveInstanceState and therefore give a null Bundle to > > > > > onCreate. > > > > > > The other thing that comes to mind is that if you're trying to tweak > > > > > launch modes, the system may be launching a new instance of your > > > > > Activity, which it would launch with a null Bundle. If this is the > > > > > case, hitting the 'back' button should eventually reveal another > > > > > instance of your same Activity. > > > > > > Its also worth noting that onPause is *not* always followed by > > > > > onCreate > > > > > (), it may be followed by onResume or onStop. onStop may then be > > > > > followed by onRestart, followed by onStart. > > > > > > If the system is improperly discarding state, this would be the first > > > > > time I've seen it, but its not impossible. > > > > > > Cheers, > > > > > Justin > > > > > Android Team @ Google > > > > > > On Dec 15, 9:32 am, jarkman wrote: > > > > > > > I'm a bit confused by the saved instance state mechanism. > > > > > > > If I breakpoint in onCreate, run the app, hit the Home button, then > > > > > > relaunch the app, I typically see a null Bundle passed in to > > > > > > onCreate. > > > > > > > But, if I (for example) rotate the emulator, I see a non-null Bundle > > > > > > in o
[android-developers] Re: When is (or isn't) instance state restored ?
The only possible complication is that it is also possible to save an activity state through shared preferences (or a content provider) in onPause() and retrieve that in onResume(), so there is a delicate question which information to store in shared preferences (or content provider) and which information to store in the bundle. Also, assuming that the content of an EditText is stored in both, a shared preference and the bundle, which of those has precedence? (Probably the bundle has precedence, but consider the following example: Application in the foreground; user presses Home, state saved to bundle; one week later another app changes content of content provider; two weeks later application is retrieved to foreground, uses information of bundle and ignores changes to content provider..) Peli On Dec 17, 3:12 am, "Dianne Hackborn" wrote: > It really is not that complicated -- the system will at various points ask > you to save your current instance state in onSaveInstanceState(), and if in > the future it needs to restart your activity with some previous saved state, > your onCreate() will be called with a Bundle containing the saved state you > supplied in onSaveInstanceState(). > > If you want to ignore this and do your own thing, you are of course free to, > and your application won't behave consistently with others. Whether your > users will care or not I can't say. > > > > On Tue, Dec 16, 2008 at 11:33 AM, joshv wrote: > > > Basically if you are interested in long term persistent state, ignore > > the Bundle passed in onCreate - I don't pretend to understand the > > reasons for why it is or is not null - perhaps they make sense to the > > framework designers, but whatever the rationale, it doesn't make much > > sense to store any state you care about in that default bundle. > > > Use SharedPreferences or a database instead. > > > On Dec 16, 2:47 am, jarkman wrote: > > > Justin - thanks for the explanation. > > > > I'm not making any allegation of impropriety on the part of the > > > system, just trying to understand what the orthodox behaviour ought to > > > be for a 'vanilla' app. > > > > I had completely missed the distinction between leaving via 'back' and > > > leaving via 'home', which may account for some of my confusion. I'm > > > not sure our users will get that distinction either, but fortunately > > > our state is pretty simple so they can't get too bemused. > > > > So, just to check, is the plan that leaving via 'home' seems to the > > > user like sending the app to the background, to be restored later, > > > whereas leaving via 'back' is closing the app, so it next starts in a > > > virgin state ? > > > > Richard > > > > On Dec 16, 12:18 am, "Justin (Google Employee)" > > > wrote: > > > > > Richard, > > > > > If you save something into the bundle and hit 'home' (button with a > > > > house on it), the system will always return a non-null Bundle to you. > > > > If you don't save anything to the Bundle, I'm not sure what the system > > > > will do. > > > > > If you hit the 'back' button (button with the arrow), the system will > > > > not call onSaveInstanceState and therefore give a null Bundle to > > > > onCreate. > > > > > The other thing that comes to mind is that if you're trying to tweak > > > > launch modes, the system may be launching a new instance of your > > > > Activity, which it would launch with a null Bundle. If this is the > > > > case, hitting the 'back' button should eventually reveal another > > > > instance of your same Activity. > > > > > Its also worth noting that onPause is *not* always followed by onCreate > > > > (), it may be followed by onResume or onStop. onStop may then be > > > > followed by onRestart, followed by onStart. > > > > > If the system is improperly discarding state, this would be the first > > > > time I've seen it, but its not impossible. > > > > > Cheers, > > > > Justin > > > > Android Team @ Google > > > > > On Dec 15, 9:32 am, jarkman wrote: > > > > > > I'm a bit confused by the saved instance state mechanism. > > > > > > If I breakpoint in onCreate, run the app, hit the Home button, then > > > > > relaunch the app, I typically see a null Bundle passed in to > > > > > onCreate. > > > > > > But, if I (for example) rotate the emulator, I see a non-null Bundle > > > > > in onCreate, and the app has the right state after the rotation. > > > > > > What causes the null in the first example ? It looks as though the > > > > > system has thrown away the saved instance state on our behalf. > > > > > > Thanks, > > > > > > Richard > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Develo
[android-developers] Re: When is (or isn't) instance state restored ?
It really is not that complicated -- the system will at various points ask you to save your current instance state in onSaveInstanceState(), and if in the future it needs to restart your activity with some previous saved state, your onCreate() will be called with a Bundle containing the saved state you supplied in onSaveInstanceState(). If you want to ignore this and do your own thing, you are of course free to, and your application won't behave consistently with others. Whether your users will care or not I can't say. On Tue, Dec 16, 2008 at 11:33 AM, joshv wrote: > > Basically if you are interested in long term persistent state, ignore > the Bundle passed in onCreate - I don't pretend to understand the > reasons for why it is or is not null - perhaps they make sense to the > framework designers, but whatever the rationale, it doesn't make much > sense to store any state you care about in that default bundle. > > Use SharedPreferences or a database instead. > > On Dec 16, 2:47 am, jarkman wrote: > > Justin - thanks for the explanation. > > > > I'm not making any allegation of impropriety on the part of the > > system, just trying to understand what the orthodox behaviour ought to > > be for a 'vanilla' app. > > > > I had completely missed the distinction between leaving via 'back' and > > leaving via 'home', which may account for some of my confusion. I'm > > not sure our users will get that distinction either, but fortunately > > our state is pretty simple so they can't get too bemused. > > > > So, just to check, is the plan that leaving via 'home' seems to the > > user like sending the app to the background, to be restored later, > > whereas leaving via 'back' is closing the app, so it next starts in a > > virgin state ? > > > > Richard > > > > On Dec 16, 12:18 am, "Justin (Google Employee)" > > wrote: > > > > > Richard, > > > > > If you save something into the bundle and hit 'home' (button with a > > > house on it), the system will always return a non-null Bundle to you. > > > If you don't save anything to the Bundle, I'm not sure what the system > > > will do. > > > > > If you hit the 'back' button (button with the arrow), the system will > > > not call onSaveInstanceState and therefore give a null Bundle to > > > onCreate. > > > > > The other thing that comes to mind is that if you're trying to tweak > > > launch modes, the system may be launching a new instance of your > > > Activity, which it would launch with a null Bundle. If this is the > > > case, hitting the 'back' button should eventually reveal another > > > instance of your same Activity. > > > > > Its also worth noting that onPause is *not* always followed by onCreate > > > (), it may be followed by onResume or onStop. onStop may then be > > > followed by onRestart, followed by onStart. > > > > > If the system is improperly discarding state, this would be the first > > > time I've seen it, but its not impossible. > > > > > Cheers, > > > Justin > > > Android Team @ Google > > > > > On Dec 15, 9:32 am, jarkman wrote: > > > > > > I'm a bit confused by the saved instance state mechanism. > > > > > > If I breakpoint in onCreate, run the app, hit the Home button, then > > > > relaunch the app, I typically see a null Bundle passed in to > > > > onCreate. > > > > > > But, if I (for example) rotate the emulator, I see a non-null Bundle > > > > in onCreate, and the app has the right state after the rotation. > > > > > > What causes the null in the first example ? It looks as though the > > > > system has thrown away the saved instance state on our behalf. > > > > > > Thanks, > > > > > > Richard > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: When is (or isn't) instance state restored ?
Right, but we can't get away from understanding what the designers had in mind. We need to know when we should be presenting to the user as a new run and when we should be presenting as a continuation of an old run, so the user gets a consistent model of the app lifetime. On most platforms we don't need to worry about it, because the actual app lifetime is the same as the apparent app lifetime. But on this one, where the system takes considerable trouble to generate a simulated app lifetime that's different from the actual one, we need to go along with the trick. Otherwise, there will be unhappiness. R. On Dec 16, 7:33 pm, joshv wrote: > Basically if you are interested in long term persistent state, ignore > the Bundle passed in onCreate - I don't pretend to understand the > reasons for why it is or is not null - perhaps they make sense to the > framework designers, but whatever the rationale, it doesn't make much > sense to store any state you care about in that default bundle. > > Use SharedPreferences or a database instead. > > On Dec 16, 2:47 am, jarkman wrote: > > > Justin - thanks for the explanation. > > > I'm not making any allegation of impropriety on the part of the > > system, just trying to understand what the orthodox behaviour ought to > > be for a 'vanilla' app. > > > I had completely missed the distinction between leaving via 'back' and > > leaving via 'home', which may account for some of my confusion. I'm > > not sure our users will get that distinction either, but fortunately > > our state is pretty simple so they can't get too bemused. > > > So, just to check, is the plan that leaving via 'home' seems to the > > user like sending the app to the background, to be restored later, > > whereas leaving via 'back' is closing the app, so it next starts in a > > virgin state ? > > > Richard > > > On Dec 16, 12:18 am, "Justin (Google Employee)" > > wrote: > > > > Richard, > > > > If you save something into the bundle and hit 'home' (button with a > > > house on it), the system will always return a non-null Bundle to you. > > > If you don't save anything to the Bundle, I'm not sure what the system > > > will do. > > > > If you hit the 'back' button (button with the arrow), the system will > > > not call onSaveInstanceState and therefore give a null Bundle to > > > onCreate. > > > > The other thing that comes to mind is that if you're trying to tweak > > > launch modes, the system may be launching a new instance of your > > > Activity, which it would launch with a null Bundle. If this is the > > > case, hitting the 'back' button should eventually reveal another > > > instance of your same Activity. > > > > Its also worth noting that onPause is *not* always followed by onCreate > > > (), it may be followed by onResume or onStop. onStop may then be > > > followed by onRestart, followed by onStart. > > > > If the system is improperly discarding state, this would be the first > > > time I've seen it, but its not impossible. > > > > Cheers, > > > Justin > > > Android Team @ Google > > > > On Dec 15, 9:32 am, jarkman wrote: > > > > > I'm a bit confused by the saved instance state mechanism. > > > > > If I breakpoint in onCreate, run the app, hit the Home button, then > > > > relaunch the app, I typically see a null Bundle passed in to > > > > onCreate. > > > > > But, if I (for example) rotate the emulator, I see a non-null Bundle > > > > in onCreate, and the app has the right state after the rotation. > > > > > What causes the null in the first example ? It looks as though the > > > > system has thrown away the saved instance state on our behalf. > > > > > Thanks, > > > > > Richard > > --~--~-~--~~~---~--~~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: When is (or isn't) instance state restored ?
Basically if you are interested in long term persistent state, ignore the Bundle passed in onCreate - I don't pretend to understand the reasons for why it is or is not null - perhaps they make sense to the framework designers, but whatever the rationale, it doesn't make much sense to store any state you care about in that default bundle. Use SharedPreferences or a database instead. On Dec 16, 2:47 am, jarkman wrote: > Justin - thanks for the explanation. > > I'm not making any allegation of impropriety on the part of the > system, just trying to understand what the orthodox behaviour ought to > be for a 'vanilla' app. > > I had completely missed the distinction between leaving via 'back' and > leaving via 'home', which may account for some of my confusion. I'm > not sure our users will get that distinction either, but fortunately > our state is pretty simple so they can't get too bemused. > > So, just to check, is the plan that leaving via 'home' seems to the > user like sending the app to the background, to be restored later, > whereas leaving via 'back' is closing the app, so it next starts in a > virgin state ? > > Richard > > On Dec 16, 12:18 am, "Justin (Google Employee)" > wrote: > > > Richard, > > > If you save something into the bundle and hit 'home' (button with a > > house on it), the system will always return a non-null Bundle to you. > > If you don't save anything to the Bundle, I'm not sure what the system > > will do. > > > If you hit the 'back' button (button with the arrow), the system will > > not call onSaveInstanceState and therefore give a null Bundle to > > onCreate. > > > The other thing that comes to mind is that if you're trying to tweak > > launch modes, the system may be launching a new instance of your > > Activity, which it would launch with a null Bundle. If this is the > > case, hitting the 'back' button should eventually reveal another > > instance of your same Activity. > > > Its also worth noting that onPause is *not* always followed by onCreate > > (), it may be followed by onResume or onStop. onStop may then be > > followed by onRestart, followed by onStart. > > > If the system is improperly discarding state, this would be the first > > time I've seen it, but its not impossible. > > > Cheers, > > Justin > > Android Team @ Google > > > On Dec 15, 9:32 am, jarkman wrote: > > > > I'm a bit confused by the saved instance state mechanism. > > > > If I breakpoint in onCreate, run the app, hit the Home button, then > > > relaunch the app, I typically see a null Bundle passed in to > > > onCreate. > > > > But, if I (for example) rotate the emulator, I see a non-null Bundle > > > in onCreate, and the app has the right state after the rotation. > > > > What causes the null in the first example ? It looks as though the > > > system has thrown away the saved instance state on our behalf. > > > > Thanks, > > > > Richard --~--~-~--~~~---~--~~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: When is (or isn't) instance state restored ?
Back closes whatever is on the front; home brings the home screen to the front. Everything else falls out from that. On Tue, Dec 16, 2008 at 12:47 AM, jarkman wrote: > > Justin - thanks for the explanation. > > I'm not making any allegation of impropriety on the part of the > system, just trying to understand what the orthodox behaviour ought to > be for a 'vanilla' app. > > I had completely missed the distinction between leaving via 'back' and > leaving via 'home', which may account for some of my confusion. I'm > not sure our users will get that distinction either, but fortunately > our state is pretty simple so they can't get too bemused. > > So, just to check, is the plan that leaving via 'home' seems to the > user like sending the app to the background, to be restored later, > whereas leaving via 'back' is closing the app, so it next starts in a > virgin state ? > > > Richard > > > On Dec 16, 12:18 am, "Justin (Google Employee)" > wrote: > > Richard, > > > > If you save something into the bundle and hit 'home' (button with a > > house on it), the system will always return a non-null Bundle to you. > > If you don't save anything to the Bundle, I'm not sure what the system > > will do. > > > > If you hit the 'back' button (button with the arrow), the system will > > not call onSaveInstanceState and therefore give a null Bundle to > > onCreate. > > > > The other thing that comes to mind is that if you're trying to tweak > > launch modes, the system may be launching a new instance of your > > Activity, which it would launch with a null Bundle. If this is the > > case, hitting the 'back' button should eventually reveal another > > instance of your same Activity. > > > > Its also worth noting that onPause is *not* always followed by onCreate > > (), it may be followed by onResume or onStop. onStop may then be > > followed by onRestart, followed by onStart. > > > > If the system is improperly discarding state, this would be the first > > time I've seen it, but its not impossible. > > > > Cheers, > > Justin > > Android Team @ Google > > > > On Dec 15, 9:32 am, jarkman wrote: > > > > > I'm a bit confused by the saved instance state mechanism. > > > > > If I breakpoint in onCreate, run the app, hit the Home button, then > > > relaunch the app, I typically see a null Bundle passed in to > > > onCreate. > > > > > But, if I (for example) rotate the emulator, I see a non-null Bundle > > > in onCreate, and the app has the right state after the rotation. > > > > > What causes the null in the first example ? It looks as though the > > > system has thrown away the saved instance state on our behalf. > > > > > Thanks, > > > > > Richard > > > > > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: When is (or isn't) instance state restored ?
Justin - thanks for the explanation. I'm not making any allegation of impropriety on the part of the system, just trying to understand what the orthodox behaviour ought to be for a 'vanilla' app. I had completely missed the distinction between leaving via 'back' and leaving via 'home', which may account for some of my confusion. I'm not sure our users will get that distinction either, but fortunately our state is pretty simple so they can't get too bemused. So, just to check, is the plan that leaving via 'home' seems to the user like sending the app to the background, to be restored later, whereas leaving via 'back' is closing the app, so it next starts in a virgin state ? Richard On Dec 16, 12:18 am, "Justin (Google Employee)" wrote: > Richard, > > If you save something into the bundle and hit 'home' (button with a > house on it), the system will always return a non-null Bundle to you. > If you don't save anything to the Bundle, I'm not sure what the system > will do. > > If you hit the 'back' button (button with the arrow), the system will > not call onSaveInstanceState and therefore give a null Bundle to > onCreate. > > The other thing that comes to mind is that if you're trying to tweak > launch modes, the system may be launching a new instance of your > Activity, which it would launch with a null Bundle. If this is the > case, hitting the 'back' button should eventually reveal another > instance of your same Activity. > > Its also worth noting that onPause is *not* always followed by onCreate > (), it may be followed by onResume or onStop. onStop may then be > followed by onRestart, followed by onStart. > > If the system is improperly discarding state, this would be the first > time I've seen it, but its not impossible. > > Cheers, > Justin > Android Team @ Google > > On Dec 15, 9:32 am, jarkman wrote: > > > I'm a bit confused by the saved instance state mechanism. > > > If I breakpoint in onCreate, run the app, hit the Home button, then > > relaunch the app, I typically see a null Bundle passed in to > > onCreate. > > > But, if I (for example) rotate the emulator, I see a non-null Bundle > > in onCreate, and the app has the right state after the rotation. > > > What causes the null in the first example ? It looks as though the > > system has thrown away the saved instance state on our behalf. > > > Thanks, > > > Richard > > --~--~-~--~~~---~--~~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: When is (or isn't) instance state restored ?
Richard, If you save something into the bundle and hit 'home' (button with a house on it), the system will always return a non-null Bundle to you. If you don't save anything to the Bundle, I'm not sure what the system will do. If you hit the 'back' button (button with the arrow), the system will not call onSaveInstanceState and therefore give a null Bundle to onCreate. The other thing that comes to mind is that if you're trying to tweak launch modes, the system may be launching a new instance of your Activity, which it would launch with a null Bundle. If this is the case, hitting the 'back' button should eventually reveal another instance of your same Activity. Its also worth noting that onPause is *not* always followed by onCreate (), it may be followed by onResume or onStop. onStop may then be followed by onRestart, followed by onStart. If the system is improperly discarding state, this would be the first time I've seen it, but its not impossible. Cheers, Justin Android Team @ Google On Dec 15, 9:32 am, jarkman wrote: > I'm a bit confused by the saved instance state mechanism. > > If I breakpoint in onCreate, run the app, hit the Home button, then > relaunch the app, I typically see a null Bundle passed in to > onCreate. > > But, if I (for example) rotate the emulator, I see a non-null Bundle > in onCreate, and the app has the right state after the rotation. > > What causes the null in the first example ? It looks as though the > system has thrown away the saved instance state on our behalf. > > Thanks, > > Richard --~--~-~--~~~---~--~~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
