On Mar 4, 11:59 pm, Nmix <nepean...@gmail.com> 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 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.
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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
