Custom Dialog

81 views
Skip to first unread message

Dirk Vranckaert

unread,
Mar 15, 2010, 4:50:02 PM3/15/10
to Android Developers
I'm trying to create a custom dialog in my application to show an
about window but it ain't working. Maybe one of you knows a solution?

So I have an activity with the onCreateDialog(int id) overriden in it:

@Override
protected Dialog onCreateDialog(int id) {
Dialog dialog = null;
switch (id) {
case EPISODE_LOADING_DIALOG:
...
case EXCEPTION_DIALOG:
...
case ABOUT_DIALOG:
dialog = new Dialog(getApplicationContext());
dialog.setContentView(R.layout.aboutdialog);
dialog.setTitle("MyTitle");
break;
default:
...
}
return dialog;
}

My aboutdialog layout files looks like this:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/
android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:padding="10dp"
>
<TextView android:id="@+id/aboutText"
android:layout_width="wrap_content"
android:layout_height="fill_parent"
android:textColor="#FFF"
android:text="@string/aboutText"
/>
</LinearLayout>

This is exactly as described here: http://developer.android.com/guide/topics/ui/dialogs.html#CustomDialog
However this my exception thrown:

03-15 21:48:32.055: ERROR/AndroidRuntime(2004): Uncaught handler:
thread main exiting due to uncaught exception
03-15 21:48:32.130: ERROR/AndroidRuntime(2004):
android.view.WindowManager$BadTokenException: Unable to add window --
token null is not for an application
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.view.ViewRoot.setView(ViewRoot.java:429)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.view.WindowManagerImpl.addView(WindowManagerImpl.java:178)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.app.Dialog.show(Dialog.java:231)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.app.Activity.showDialog(Activity.java:2407)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
eu.vranckaert.episodeWatcher.EpisodesWatchListActivity.onOptionsItemSelected(EpisodesWatchListActivity.java:
130)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.app.Activity.onMenuItemSelected(Activity.java:2085)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
com.android.internal.policy.impl.PhoneWindow.onMenuItemSelected(PhoneWindow.java:
820)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
com.android.internal.view.menu.MenuItemImpl.invoke(MenuItemImpl.java:
139)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
com.android.internal.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:
813)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
com.android.internal.view.menu.IconMenuView.invokeItem(IconMenuView.java:
519)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
com.android.internal.view.menu.IconMenuItemView.performClick(IconMenuItemView.java:
122)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.view.View.onTouchEvent(View.java:3828)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.widget.TextView.onTouchEvent(TextView.java:6291)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.view.View.dispatchTouchEvent(View.java:3368)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:863)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:863)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
com.android.internal.policy.impl.PhoneWindow
$DecorView.dispatchTouchEvent(PhoneWindow.java:1691)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.view.ViewRoot.handleMessage(ViewRoot.java:1525)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.os.Handler.dispatchMessage(Handler.java:99)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.os.Looper.loop(Looper.java:123)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
android.app.ActivityThread.main(ActivityThread.java:3948)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
java.lang.reflect.Method.invokeNative(Native Method)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
java.lang.reflect.Method.invoke(Method.java:521)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:782)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:540)
03-15 21:48:32.130: ERROR/AndroidRuntime(2004): at
dalvik.system.NativeStart.main(Native Method)

Kumar Bibek

unread,
Mar 15, 2010, 4:58:43 PM3/15/10
to Android Developers
Try getBaseContext();

Thanks and Regards,
Kumar Bibek

Dirk Vranckaert

unread,
Mar 15, 2010, 5:05:09 PM3/15/10
to Android Developers
Thx for the quick response but doesn't change a thing, it gives me
exactly the same exception!

Adrian Vintu

unread,
Mar 15, 2010, 5:15:22 PM3/15/10
to android-d...@googlegroups.com
This one hs been answered a couple of times on this forum.

Use
dialog = new Dialog(this);
instead of
dialog = new Dialog(getApplicationContext());

BR,
Adrian Vintu

http://adrianvintu.com


--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-d...@googlegroups.com
To unsubscribe from this group, send email to
android-develop...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Dirk Vranckaert

unread,
Mar 15, 2010, 5:47:04 PM3/15/10
to Android Developers
Thx a lot, this works!

On 15 mrt, 22:15, Adrian Vintu <adrianvi...@gmail.com> wrote:
> This one hs been answered a couple of times on this forum.
>
> Use
> dialog = new Dialog(this);
> instead of
> dialog = new Dialog(getApplicationContext());
>
> BR,
> Adrian Vintu
>
> http://adrianvintu.com
>
> On Mon, Mar 15, 2010 at 10:05 PM, Dirk Vranckaert

> <dirkvrancka...@gmail.com>wrote:

> > android-develop...@googlegroups.com<android-developers%2Bunsu...@googlegroups.com>

Bob Kerns

unread,
Mar 16, 2010, 4:55:27 PM3/16/10
to Android Developers
I've not been able to come up with a single use case for calling
getApplicationContext(); I suspect the need for it is ENTIRELY
internal. Also getBaseContext().

Generally, you want to pass along the most specific context available.
That will be your current activity or service. UI components like
Views always need an Activity as a context, as a practical matter.

As long as I'm explaining that point, let me go on to cover the rest
of the topic -- the Application as a context:

If you're looking for a shared context (as in sharing a common object
between activities), that would be getApplication()..

getApplicationContext() can return you an entirely different
application from the same process. You can't access anything
interesting in it -- it was loaded with a different classloader, and
you don't really have any control over just WHICH application object
will be returned. It's best to just consider it a toxic object you
don't want to be touching, because it can only add bugs, not
functionality.

It's tempting, or at least it was to me until I learned better, to
override getApplicationContext() to typecast to the more specific
application class. But that doesn't work for the above reasons. And it
doesn't work to do it for getApplication(), since that is declared
final.

So I have a getApp() method in a common activity base class that casts
to my specific app class.

You have to be careful with Application objects anyway -- they can't
own any dynamic state. An activity or service must always take
responsibility for persisting any dynamic state.

> > > android-develop...@googlegroups.com<android-developers%2Bunsubs cr...@googlegroups.com>

TreKing

unread,
Mar 17, 2010, 9:38:50 AM3/17/10
to android-d...@googlegroups.com
On Tue, Mar 16, 2010 at 3:55 PM, Bob Kerns <r...@acm.org> wrote:
I've not been able to come up with a single use case for calling getApplicationContext();

Could someone from Google PLEASE update the documentation for this function and the samples that use it incorrectly? It is the source of massive confusion for people new to the platform and results in basically the exact same "my dialog is crashing" question on an almost weekly basis.

It shouldn't take someone more than 10 minutes to comment this function warning people not to use it and to do a find and replace on the examples to change it to "this" (or whatever is appropriate in the samples). This will ultimately save a TON of time people would otherwise waste trying to figure out why the examples don't work, posting here, and ultimately getting the exact same answer every time.

Thank you.

-------------------------------------------------------------------------------------------------
TreKing - Chicago transit tracking app for Android-powered devices
http://sites.google.com/site/rezmobileapps/treking

Lance Nanek

unread,
Mar 17, 2010, 11:09:22 AM3/17/10
to Android Developers
I tried the official issue route of getting someone to do something
here:
http://code.google.com/p/android/issues/detail?id=5748

You can star/vote it up, I suppose. It's been months, though.
Disappointing that such a trivial fix that would help so many people
who are starting out isn't being acted on. I've run into many other
documentation bugs as well. Too bad there's no way to get them fixed.

It would be easy to put up a site with a copy of the docs that aren't
left to die. Allowing comments like in the PHP manual would help a lot
too. There'd be no way to get traffic to the fixed copy instead of the
broken official ones, though. Just like how all the Market
alternatives get so few users.

mah

unread,
Mar 17, 2010, 4:35:41 PM3/17/10
to Android Developers
I've been bit by this incorrect documentation as well.

I've just starred your issue, but I see that currently the vote count
on it is very small. I hope that more people will vote to have this
(and any other incorrect documentation) issue addressed; without solid
documentation, the system value diminishes.

TreKing

unread,
Mar 17, 2010, 4:36:24 PM3/17/10
to android-d...@googlegroups.com
On Wed, Mar 17, 2010 at 10:09 AM, Lance Nanek <lna...@gmail.com> wrote:
I tried the official issue route of getting someone to do something
here:
http://code.google.com/p/android/issues/detail?id=5748

Thanks Lance. I starred it up ... now up to 3! It'll get fixed in no time now! 
 
Disappointing that such a trivial fix that would help so many people
who are starting out isn't being acted on.

Yeah, this amazes me. If it were my code and documentation, I would be so embarrassed by such glaring errors in the documentation and samples that I would fix it ASAP.
 
It would be easy to put up a site with a copy of the docs that aren't
left to die. Allowing comments like in the PHP manual would help a lot
too. There'd be no way to get traffic to the fixed copy instead of the
broken official ones, though.

That's a good idea. I'm sure posting links right in these groups would be a good way to drive traffic to such a site.

DonFrench

unread,
Mar 17, 2010, 5:21:03 PM3/17/10
to Android Developers
Same error in AlertDialog. Cost me two hours. I just starred it.

brucko

unread,
Mar 17, 2010, 6:52:49 PM3/17/10
to Android Developers
Bob,

Thanks for this and other posts. If it weren't for yourself, Mark
Murphy and TreKing I would be pulling my hair out - and its getting
too precious to be doing that these days.

As someone with not a lot of experience in things Android, the Context
is one of the most confusing things to me and I would love to see a
blog article/ Mark Murphy chapter specifically on each of the various
levels of Context returned by the various methods and when they should
be used.

Frankly there are that many posts about:-

* dialogs and conflicts with documentation like this one.

* toasts and leaks (
http://groups.google.com/group/android-developers/browse_thread/thread/de2f0cebec002303/475f545e947a5915?lnk=gst&q=toast+leak+context#475f545e947a5915)

* leaks and using ApplicationContext with long lived objects

"There are two easy ways to avoid context-related memory leaks. The
most obvious one is to avoid escaping the context outside of its own
scope. The example above showed the case of a static reference but
inner classes and their implicit reference to the outer class can be
equally dangerous. The second solution is to use the Application
context. This context will live as long as your application is alive
and does not depend on the activities life cycle. If you plan on
keeping long-lived objects that need a context, remember the
application object. You can obtain it easily by calling
Context.getApplicationContext() or Activity.getApplication()." -
http://developer.android.com/resources/articles/avoiding-memory-leaks.html

* Binder.java having internal comments warning about potential
memory leaks using non-static sub-classes - but nothing in the javadoc
documentation. (Well, maybe experienced Java developers are fully
aware of the references inner classes have on their outer class - but
some of us have very little experience and are putting our apps
alongside yours)


THAT quite frankly confuses the hell out of anyone new to Android.
There doesn't appear to be any real documentation in the developer
Resources area (I apologise if I have missed it) that really explains
what all the different hierarchies of context are, what they give you
or with what types of objects they are to be used. Hopefully I am
correct in saying that every Intent is either passed or receives from
somewhere a Context of some form - but there is little information on
what that is or should be.

I'll be the first to admit that, when I first started and until quite
recently, been passing contexts that are as non-specific or higher up
in the hierarchy as possible with the perhaps misguided opinion that -
" well at least if I leak this it wont keep around anything else
that's not there anyway". Yes, I agree with you I am an idiot who
doesn't know the first thing about leaks, SoftReferences and memory
management. But until I started learning about these things and MAT
and tracking leaks, without a real resource on Contexts - can you
forgive me for succumbing to temptation? After all, until you know
better isn't Java supposed to take care of all this for you?

With the ease of publishing apps on the market, goods apps put out
there by people like yourselves - are next to apps by teenagers with
little experience in Java let alone Android. Bad apps impact the good
ones, not just whilst they are running, but also through the entire
"Android experience" that users get. If an app force closes one gets
this little voice in the back of their head telling them that Android,
and not just that app, is prone to being buggy. When most of the time
it is newbies like me who fail to really understand the Android
environment whinging and complaining about Androids faults when all we
are really doing is externalising our own shortcomings.

On the whole, I love Android, but an article on Context best practice
(or maybe half a chapter, or Appendix table, in one of Mark Murphys
books) is really needed so that Learner drivers like myself don't ruin
the Android experience for everyone.

Mark Murphy

unread,
Mar 17, 2010, 7:23:23 PM3/17/10
to android-d...@googlegroups.com
brucko wrote:
> As someone with not a lot of experience in things Android, the Context
> is one of the most confusing things to me and I would love to see a
> blog article/ Mark Murphy chapter specifically on each of the various
> levels of Context returned by the various methods and when they should
> be used.

???

Why on Earth would you want the President/CEO of the Green Bay Packers
to write about Contexts?

Oh, wait. You mean me.

:-)

> On the whole, I love Android, but an article on Context best practice
> (or maybe half a chapter, or Appendix table, in one of Mark Murphys
> books) is really needed so that Learner drivers like myself don't ruin
> the Android experience for everyone.

As one of the set (Crosby, Stills, Nash, Young) sorta wrote, "if you
can't be with the Context you love, love the Context you're with".

IOW, if you're in an Activity, and you need a Context, use the Activity,
because Activity inherits from Context. If you're in a Service, and you
need a Context, use the Service, because Service inherits from Context.
If you're in onReceive() of a manifest-registered BroadcastReceiver, and
you need a Context, use the one passed in as a parameter. And so on.

That covers perhaps 90% of the cases right there, IMHO.

No question, the remaining 10% is confusing. It's one of those topics
I'm scared to tangle with, mostly because of the reasons you pointed
out: it's a bunch of sometimes-contradictory rules of thumb. There are
some subjects where I can't be as definitive as I want to be -- tasks
are another fine example -- so I tend to avoid 'em. I'm just a wimp.

I'd love to be able to pick Google's collective brains on these things
(in some non-discriminatory fashion, as I'm *so* not looking for special
treatment). We need to get more advice on topics like this out there,
and I think some core Android team members and some community folk could
knock out advice for some of the icky stuff in a one-day event.

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_
Version 1.3 Available!

brucko

unread,
Mar 18, 2010, 12:33:13 AM3/18/10
to Android Developers
Sorry to single you out Mark, but you just write stuff that makes
sense.
Reply all
Reply to author
Forward
0 new messages