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 wrote:
> I see bug 1639 - is there a workaround to restore a 're-created'dialogusing
> code i
I see bug 1639 - is there a workaround to restore a 're-created'
dialog using code in an overridden onPrepareDialog?
On Mar 6, 6:13 am, Romain Guy 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
> >>c
>> It is a problem. In my, and others', opinion it is a *bug* that the
>> onPrepareDialog is not called when a dialog is restored on a
>> configuration change. onCreateDialog is called when appropriate, but
>> onPrepareDialog is not
It is a bug indeed.
>>
>> I think the onPrepareDialog shoul
I'm leaning towards agreeing with you, but it may be a toss up between
being a bug or obscure documentation, or that I'm just not
understanding the situation well enough. If it is a bug, it may be
more fundamental than onPrepareDialog() since it doesn't seem as if
the old dialog is reachable after
Good to hear you got it working.
It is a problem. In my, and others', opinion it is a *bug* that the
onPrepareDialog is not called when a dialog is restored on a
configuration change. onCreateDialog is called when appropriate, but
onPrepareDialog is not
I think the onPrepareDialog should ALW
On Mar 4, 11:59 pm, Nmix 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 onSaveInstan
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 a
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
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,
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 wrote:
> I had a similar issue. There seems to be an issue with onPrepareDialog
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 hap
Sorry I got confused, you want removeDialog(), not dismissDialog().
The latter only closes the dialog but it is still known as a managed
dialog. removeDialog() on the other hand tells the Activity to forget
about the dialog *and* to dismiss it.
On Wed, Mar 4, 2009 at 10:53 AM, Nmix wrote:
>
> Ju
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
recrea
On Mar 4, 12:21 pm, Marco Nelissen wrote:
> On Wed, Mar 4, 2009 at 9:13 AM, Nmix 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
On Wed, Mar 4, 2009 at 9:13 AM, Nmix 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
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
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
17 matches
Mail list logo
