Hello everyone! First of all I'd like to thank you all for your helpful tips and information about what could be causing the problem.
That said, I'd like to address a few points that have been mentioned: 1. I'm not concerned about reboots or Force Closes - if the device is rebooted or the browser has a FC fit, I don't expect all of my windows to be restored. It'd be a nice feature, but not something necessary, like being able to resume a browser session after only having minimized it. 2. The primary suspect, in my eyes, is still the free program memory (not RAM but the Flash in which applications are installed) - it seems to me that if the browser cannot find enough free phone memory to save its state, the saving process fails silently. This is supported by the observation I made earlier - with 20MB of phone memory free, I was able to reproduce the problem with 8-10 simple forum/e-mail pages open. With 50MB of phone memory free, I was only able to reduce the problem if at least 4 or 5 of the open tabs were very graphically intensive (and therefore memory intensive) sites. Diane wrote: *To investigate these, you can use "adb shell dumpsys activity" to see the activity stack (in particular the browser activity entry) at various points. When it is in the background, does it say it has the saved state? Right before restarting it, is the entry still there will the saved state? If so, then there is most likely something going on when the browser tries to restore its state. If not, then something earlier is going buggy when the state is saved. *I'll give this a try tomorrow... can't make any promises, however, as I'm still very new to Android development - haven't gotten much farther than Hello World and a few pages of the Developer's Guide so far ;) Thanks again for all your help! On Sat, Jun 5, 2010 at 11:29 PM, Dianne Hackborn <[email protected]>wrote: > I am pretty sure the browser saves its state in onSaveInstanceState, not > persistently, and this is currently as intended. That is, it will retain > its state when its process gets killed and restarted, but it is deliberately > not trying to retain its state across reboots. > > Note that instance state is always saved before pause, BEFORE an app goes > to the background. So that is the key point for state saving; after that, > it doesn't matter when the process gets killed, nor is there a need to let > the app do anything before it gets killed, the activity manager already has > its saved state so it can be used to restore the activity in a new process. > > There are two main ways the browser could be losing its state: > > > > To investigate these, you can use "adb shell dumpsys activity" to see the > activity stack (in particular the browser activity entry) at various points. > When it is in the background, does it say it has the saved state? Right > before restarting it, is the entry still there will the saved state? If so, > then there is most likely something going on when the browser tries to > restore its state. If not, then something earlier is going buggy when the > state is saved. > > > On Sat, Jun 5, 2010 at 12:25 PM, Frank Weiss <[email protected]> wrote: > >> The state save I'm refering to is via SharedPreferences. I've observed >> this in my own application. Indeed, the Android Browser's bookmarks are >> saved across reboots, and I'd suppose across force closes as well, However, >> I think Mark is correct that some state may not be correctly saved in a FC >> situation. >> >> I think my theory still stands that the browser is not saving windows >> across reboots and FCs. If you think about it, it may not even be possible, >> depending on how you define saving windows, although FF and IE are able to >> restore tabs. >> >> -- >> 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]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Simon Broenner -- 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
