It's even worse than what you're speaking of, now that I've been doing more testing.
onSaveInstanceState() is called for activity pauses (like an incoming call) and also for configuration changes. However it now matters which occurred, it seems, when it comes time to recover. If it was a pause, you have to use onResume(), which you are doing in your example. If it was a configuration change I need the savedInstanceState in either onCreate() or onRestoreInstanceState(), which isn't provided in onResume(). This wouldn't be so bad since the dialogs survive a pause/resume cycle, *except* that I call dismissDialog() from onSaveInstanceState (). Now my earlier "solution" doesn't work unless I call showDialog() from onResume(), provided that I restore the data in onCreate() but do nothing more. I haven't tried this yet, but I will need to fix something to get it working in all these use cases. Painful. On Mar 4, 5:37 pm, Streets Of Boston <[email protected]> wrote: > Made a copy-paste error. > The 'dirty' workaround in the onResume() should read: > > if (mPrepareDialog) { > onPrepareDialog(R.layout.mydialogid, mDialog); > } > > On Mar 4, 5:33 pm, Streets Of Boston <[email protected]> wrote: > > > I had a similar issue. There seems to be an issue with onPrepareDialog > > after a configuration change. > > > In my app i'm using managed dialogs as well. the onCreateDialog > > creates it and the onPrepareDialog makes sure that the dynamic content > > is shown correctly. > > > However, when a configuration change happens (keyboard open/close), > > the onPrepareDialog is never called, just like you mentioned! > > This is a big > > problem.http://groups.google.com/group/android-developers/browse_thread/threa... > > > I made a work-around for it by coding this in my Activity: > > > @Override > > protected void onPrepareDialog(int id, Dialog dialog) { > > switch (id) { > > case R.layout.mydialogid: > > mDialogPrepared = true; > > ... > > ... > > break; > > > default: > > break; > > } > > super.onPrepareDialog(id, dialog); > > } > > > @Override > > protected void onSaveInstanceState(Bundle outState) { > > super.onSaveInstanceState(outState); > > > outState.putBoolean("mPrepareDialog", (mDialog != null && > > mDialog.isShowing())); > > } > > > @Override > > protected void onRestoreInstanceState(Bundle savedInstanceState) > > { > > super.onRestoreInstanceState(savedInstanceState); > > > mPrepareDialog = !mDialogPrepared && > > savedInstanceState.getBoolean("mPrepareDetailView"); > > } > > > @Override > > protected void onResume() { > > super.onResume(); > > > ... > > ... > > if (mPrepareDialog) { > > onPrepareDialog(R.layout.album_details, > > mAlbumDetailsDlg); > > } > > } > > > Again, this is a very dirty trick, but the only way i could get it to > > work. > > > On Mar 4, 1:53 pm, Nmix <[email protected]> wrote: > > > > Just to finish this off, here is what I've learned now that I have it > > > working properly. > > > > First, dismissDialog() in onDestroy() does not dismiss the dialog. I > > > have to do it in onSaveInstanceState(). If I do it in onDestroy() and > > > I try to recreate it in onCreate() with showDialog() -- after > > > recreating the dynamic data it needs -- I get two dialog windows: one > > > that's broken (empty dynamic data) and one that's good. > > > > Second, if I do nothing at all, onPrepareDialog() is not called on the > > > active dialog after the config change. So simply recreating the data > > > it needs does nothing. I just displays the empty dialog. > > > > It all works perfectly when I do a dismissDialog() in > > > onSaveInstanceState(), save the dialog id in the bundle, pull it back > > > out in onCreate(), then create the data and call showDialog(). I > > > suppose it all makes some sort of sense although I do wish it were > > > more intuitive (and simpler). > > > > Romain, Marco, thanks for the feedback. > > > > On Mar 4, 12:13 pm, Nmix <[email protected]> wrote: > > > > > Ugh. I already use onCreateDialog() and onPrepareDialog() since that > > > > is how I deal with making the content dynamic. I figured dismissing > > > > it (ok, I agree that's not quite a best practice), would be simplest, > > > > especially since in the context of the app it is very unlikely that > > > > the user would change config while it is showing. > > > > > I'll try dismissing in onDestroy(). I hadn't done that since I wasn't > > > > sure that it'd be called on a config change. > > > > > It also seems from your comment that onCreateDialog() and > > > > onPrepareDialog() do get called again sometime after onCreate(). If > > > > true, I hadn't realized that. I may look into that later and see if I > > > > can refresh those dialogs. > > > > > Thanks. > > > > > On Mar 4, 11:42 am, Romain Guy <[email protected]> wrote: > > > > > > If you want to call dismissDialog(int) you need to use managed > > > > > dialogs. You will need to look at the javadoc for showDialog(int), > > > > > onCreateDialog() and onPrepareDialog(). The API Demos also show how to > > > > > use managed dialogs. > > > > > > If you are already using these APIs, onCreate() is not the right > > > > > placae to dismiss the dialog since it doesn't exist yet. You would > > > > > have to do this in onDestroy() for instance. Note that dismissing the > > > > > dialog on configuration change goes against the purpose of managed > > > > > dialogs :) > > > > > > On Wed, Mar 4, 2009 at 8:37 AM, Nmix <[email protected]> wrote: > > > > > > > Flipping between landscape and portrait is causing me a problem with > > > > > > dialogs that are active at the time of config change. The dialogs > > > > > > survive (which I think is good), but I have the problem that some of > > > > > > my dialogs contain dynamic content which would need to be refreshed > > > > > > in > > > > > > the dialog views. All that content disappears from the dialog views > > > > > > after the config change. > > > > > > > I thought it would be easier to do a dismissDialog() on restoration > > > > > > in > > > > > > onCreate(), letting the user press the button that shows the dialog. > > > > > > I successfully save and recover the dialog id, but when I attempt to > > > > > > dismissDialog(id) I get an IllegalArgumentException: no dialog with > > > > > > id > > > > > > 1 was ever shown via Activity$showDialog. > > > > > > > Ok, so that doesn't work, and I still have that messed up dialog up > > > > > > on > > > > > > the screen that I want to get rid of. How can I do that? Are there > > > > > > any other reasonable alternatives? Thanks. > > > > > > -- > > > > > Romain Guy > > > > > 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- Hide > > > > > quoted text - > > > > - Show quoted text -- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
