Actually 1 and 2 are the things to deal with; 3 is not really relevant. (It would be if the app had all of its activities finished before going in the background, then when coming back into the foreground the new activity instance doesn't have a saved state. So functionally the same starting the first time, and not interesting.)
You can provoke this behavior in your app either by using DevTools to set the maximum number of background process tiny so your process gets killed nearly immediately, or just use the shell's "ps" and "kill" to find your process after going in the background and killing it. As a design pattern, activities shouldn't have dependencies between each other. They should always be self-contained separable components. If you want to share state between them (which perfectly reasonable) a good way to do this is to have a separate class of your own managing the state, which is a singleton. Then each activity retrieves the singleton when it needs it, and it will always get initialized when needed (and not before when it is needed). On Fri, Aug 6, 2010 at 7:58 AM, Michael A. <[email protected]> wrote: > Hmm... does this mean there are three scenarios I need to consider? > > 1. App is put in background. Resumed later in the same state. > 2. App is killed. Resumed later in the same state. > 3. App is killed. Resumed later from scratch. > > I thought only 1. and 3. were possible scenarios. How can I provoke > scenario #2 so that I can test this? Currently, whenever I kill the > app, I always find that it restarts from scratch. > > Regards, > > Michael A. > > On Aug 6, 2:18 pm, Dianne Hackborn <[email protected]> wrote: > > If the app is killed, the next time the user returns to it only the > visible > > activities at that point will be re-started; not the entire activity > stack. > > > > > > > > On Fri, Aug 6, 2010 at 4:48 AM, Michael A. <[email protected]> > wrote: > > > I am seeing a lot of NullPointerException in my code at the moment > > > from public static variables. > > > > > I use these variables to store, e.g., my image library (used in > > > Activities throughout my code). All of them are initialized in the > > > OnCreate of my apps Base activity, and I check that they are > > > initialized in OnResume just to be certain (and initialize them if > > > they have somehow become nulled). > > > > > // Main APP Activity > > > MainActivity { > > > public static GlobalObject lib; > > > > > void OnCreate() { > > > if (lib == null) > > > lib = new GlobalObject(); > > > } > > > > > void OnResume() { > > > if (lib == null) > > > lib = new GlobalObject(); > > > } > > > > > } > > > > > // Some other activity instantiated later > > > OtherActivity { > > > void onCreate() { > > > lib.doSomething(); // This line will sometimes fail with a > > > NullPointerException > > > } > > > > > } > > > > > I am quite unable to recreate the situation in which this > > > NullPointerException occurs. As I understand the activity lifecycle, > > > it should not be possible for lib to be null when OtherActivity is > > > created (if OtherActivity is in memory, MainActivity's static > > > variables should also be in memory and if the app is killed, it should > > > start over from MainActivity?), but that is the error I seem to be > > > getting. > > > > > Suggestions, anyone? I suppose I am probably overlooking something > > > simple, but I just can't see it. > > > > > Regards, > > > > > Michael A. > > > > > -- > > > 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]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > > > -- > > 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, and so won't reply to such e-mails. 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]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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, and so won't reply to such e-mails. 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
