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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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)" <[email protected]> > > > > 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 <[email protected]> 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 > > [email protected] > > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
