Killing the app while it was in the background did the trick when I restarted (weird that I never encountered this when using Taskiller on an actual device). Ah well - one more test to deal with. Thanks for the explanation.
Since I need the application context, extending android.app.Application is probably the better option for me. Regards, Michael A. On Aug 6, 7:18 pm, Dianne Hackborn <[email protected]> wrote: > 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
