No doubt you're right. After a while it feels like I'm doing a peculiar dance to celebrate the Rites of Spring, all the while sprinkling magic pixie dust over my code.
I had already come to the same conclusion, that doing dismissDialog() in onSaveInstanceState() is a mistake, because it changes activity state in a way such that the dialog doesn't automatically reappear at the end of a phone call (which it did before). As to what I want to accomplish, it's very simple: all views, including any dialog, survives over configuration changes and temporary ceding of control to another activity. Until I encountered the problem with my dynamic dialog content I had everything under control. It was then that I speculated that I ought to just dismiss the dialog in this rare case to simplify my life since the dialog is easily re-accessed by the user with one button press. Ideally I would want to do have the dialog survive, and contain the same (refreshed) dynamic data. So let me see if I've got this right (I can revisit the code later to try stuff). In onSaveInstanceState() I bundle away the stateful data I need to refresh the app state and all views, including dialogs. If the app is just being paused, the saved data shouldn't be used elsewhere, such as in onResume(), where it isn't delivered anyway. And I believe onRestoreInstanceState() will not be called. I am uncertain at this point whether, in case of restoration after config change, I should pull the saved data from the bundle in onCreate () or, (which I image happens afterward) in onRestoreInstanceState(). When I was merely pulling database records and filling in dynamic parts of the main layout view, I don't believe it mattered. With static dialogs, I don't need to do anything at all. With dynamic dialogs I started running into problems and coming up with ineffective solutions. As reported earlier, I can't call dismissDialog() -- it seemed unavailable to my code after restoration of the activity. So if I don't call dismissDialog() before the activity is destroyed I have a visibly broken dialog that I can't dismiss. The buttons still work fine so the user can close it, but that is absolutely not good. When I tried dismissDialog() in onDestroy (), along the lines that Marco suggested, nothing happened. I haven't checked but I assume onDestroy() was not called. Romain suggested removeDialog(), which I haven't tried yet, though I have to wonder if it'll work after restoration when dismissDialog() does not work. The way things stand, if I don't call dismissDialog() in onSaveInstanceState() I can't get rid of it. Yet if I do I seem to be creating additional trouble for myself since if it was just an ordinary pause I have to redo showDialog() in onResume() for no particularly good reason other than I can't find a better way. Sorry to be so long winded, but I wanted to try and be clear about this. If I hear nothing I will likely try this latter route and see what happens. I'll pull the saved data in onCreate() and then call showDialog() in onResume(). If I manage stateful data appropriately I think this will work. I just hope there's a better way. Thanks for your interest. On Mar 4, 9:23 pm, Dianne Hackborn <[email protected]> wrote: > I think you are getting yourself into a more and more tangled mess. As a > fairly broad rule, you shouldn't be doing any state-changing behavior in > onSaveInstanceState() -- this is not for the system to tell you about > something interesting happening, but for it to get your current state at > whatever point it thinks it might need it. > > Could we back up and look at exactly what you are trying to do? In which > situations do you want the dialog to stay, and in which do you want it to > disappear? This shouldn't be in terms of "when state is saved" or "when it > is destroyed", but "when the user flips the lid / changes the > configuration," "when the user presses home," "when the user switches to > another activity," etc. > > > > On Wed, Mar 4, 2009 at 5:28 PM, Nmix <[email protected]> wrote: > > > 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 - > > -- > 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. 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 -~----------~----~----~----~------~----~------~--~---
