My workaround is in the message you quoted. I don't see how overriding onPrepareDialog can work since it isn't called after the config change -- that's the essence of the bug.
On Apr 27, 9:02 am, AusR <[email protected]> wrote: > I see bug 1639 - is there a workaround to restore a 're-created'dialogusing > code in an overridden onPrepareDialog? > > On Mar 6, 6:13 am, Romain Guy <[email protected]> wrote: > > > >> It is a problem. In my, and others', opinion it is a *bug* that the > > >> onPrepareDialog is not called when adialogis restored on a > > >>configurationchange. onCreateDialog is called when appropriate, but > > >> onPrepareDialog is not.... > > > It is a bug indeed. > > > >> I think the onPrepareDialog should ALWAYS be called just before a > > >>dialogis shown, whether it is through an explicit call to showDialog > > >> (x) or through the restoration management of the activity. > > > >> On Mar 5, 1:32 pm, Nmix <[email protected]> wrote: > > > >> > On Mar 4, 11:59 pm, Nmix <[email protected]> wrote: > > > >> > > 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 thedialogdoesn'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 anydialog, > > >> > > survives overconfigurationchanges and temporary ceding of control to > > >> > > another activity. Until I encountered the problem with my dynamic > > >> > >dialogcontent I had everything under control. It was then that I > > >> > > speculated that I ought to just dismiss thedialogin this rare case > > >> > > to simplify my life since thedialogis easily re-accessed by the user > > >> > > with one button press. Ideally I would want to do have thedialog > > >> > > 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 brokendialogthat 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. > > > >> > This worked. However I suspect that there must be a better way to > > >> > handle managed dialogs, or perhaps there should be. Active dialogs > > >> > that I can't access or dismiss after activity restoration is a > > >> > problem.- Hide quoted text - > > > >> > - Show quoted text - > > > -- > > 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
