This doesn't work. It is still associated with the original context/activity, so at the very least you are now leaking that object and worse it may be trying to do stuff with it (such as use the WindowManager service) that is now on a context that is no longer live.
On Fri, Apr 15, 2011 at 4:54 PM, Shri Borde <[email protected]> wrote: > It actually worked with Fragment#setRetainInstance. I just had to call > ((ViewGroup) fragmentLayout.getParent()).removeView(fragmentLayout) before I > could reuse the views. > > I got crashes in native code when I tried doing the same with > Activity#onRetainNonConfigurationInstance. > > > On Fri, Apr 15, 2011 at 2:53 PM, Dianne Hackborn <[email protected]>wrote: > >> Sorry, you just can't re-use a WebView across config changes -- a view is >> instantiated with a Context it runs in, which is the Activity that created >> it. You can't change this context later, when you have a new Activity >> instance. >> >> On Fri, Apr 15, 2011 at 8:33 AM, Shri <[email protected]> wrote: >> >>> I have a WebView in my Activity which I want to reuse across config >>> changes so that the webpage does not get reloaded after every >>> orientation change. I can use >>> Activity#onRetainNonConfigurationInstance/getLastConfigurationInstance >>> for this. However, I have heard that Fragment#setRetainInstance is >>> better for this purpose. This does not seem correct if there are other >>> Views involved which should be recreated after a config change (eg. >>> TextView which should be recreated after a locale change so that new >>> string resources can be picked up). I could keep only the WebView in a >>> Fragment, and all other Views in the Activity, but then either >>> approach seems good enough. >>> >>> Just checking that Activity#onRetainNonConfigurationInstance/ >>> getLastConfigurationInstance are not considered to be bad practice >>> going forward. >>> http://developer.android.com/guide/topics/resources/runtime-changes.html >>> only mentions these apis anyway, not Fragment#setRetainInstance. >>> >>> Thanks >>> Shri >>> >>> -- >>> 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 >>> >> >> >> >> -- >> 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. >> >> > -- 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
