为什么AlertDialog.Builder（上下文的背景下）只接受活动作为参数？ [英] Why does AlertDialog.Builder(Context context) only accepts Activity as a parameter?

问题描述

在我不断学习的过程（对话框这个时候），我发现这个作品：

In my ongoing learning process (dialog boxes this time), I discovered that this works:

  AlertDialog.Builder builder = new AlertDialog.Builder(this);

而下面不工作（在运行时失败与窗口管理器，$ BadTokenException）：

While the following doesn't work (fails at runtime with WindowManager$BadTokenException):

  AlertDialog.Builder builder = new AlertDialog.Builder(this.getApplicationContext());

我不明白为什么，因为<一href="http://developer.android.com/reference/android/app/AlertDialog.Builder.html#AlertDialog.Builder%28android.content.Context%29">the构造为AlertDialog.Builder被定义为接受上下文作为参数，而不是活动：

I don't understand why, because the constructor for AlertDialog.Builder is defined to accept Context as a parameter, not Activity:

公共AlertDialog.Builder（上下文   上下文）

public AlertDialog.Builder (Context context)

使用上下文此Constructor   建设者和AlertDialog它   造成的。

Constructor using a context for this builder and the AlertDialog it creates.

我在想什么？

推荐答案

这是活动继承了语境。 AlertDialog.Builder指定一个上下文参数，因为它可以被用于任何类，它是一个子类语境，包括活动，ListActivity，服务，......（有这背后一个共同的编码成语 - 你可以更多地了解它由约书亚布洛赫的美妙有效的Java读取项目I8（在接口和抽象类））。

An Activity inherits a Context. AlertDialog.Builder specifies a Context argument because it can then be used by ANY class that is a subclass of Context, including an Activity, ListActivity, Service, ... (There is a common coding idiom behind this - you can learn more about it by reading Item I8 (on Interfaces and Abstract classes) in Joshua Bloch's fantastic Effective Java).

getApplicationContext（）返回上下文为您的应用程序，其中大部分是一样的你的活动范围内 - 与大多是是什么，是你扔了。的细节尚不清楚，但是这是一个广泛的问题时遇到，和典型答案是使用将被写入警报的屏幕的上下文。请注意，这是的没有的由getApplicationContext（）返回一个

getApplicationContext() returns the context for your application, which is mostly the same as your activities context - and the "mostly" is what is throwing you off. The details are unclear but this is a widely encountered issue, and the typical answer is to use the context that will be writing the alert to the screen. Note that that is not the one returned by getApplicationContext().

现在，如果你像我一样，你可能会说，但我在工作中，不从活动继承的类 - 这就是为什么我要在第一时间使用getApplicationContext（）这个 - ！咄实际上，我不说话十分粗鲁地说，P ..点是我已经在这里了。我固定它，像这样：1）问自己：我有我的UI AlertDialog code在非活性类，因为我希望在整个活动分享..甚至可以跨越ListActivities，服务，......？。如果不是，嗯...你真的有在code，你不能保证将有机会获得到UI（和上下文）AlertDialog UI电话？如果是这样，重新考虑你的设计。

Now if you're like me, you may say "but I am working in a class that does not inherit from Activity - which is why I want to use getApplicationContext() for this in the first place - duh!" I'm actually don't speak as rudely as that ;p .. the point was I've been here too. I fixed it like so: 1) ask yourself "do I have my UI AlertDialog code in a non-activity class because I want to share it across activities .. or even across ListActivities, Services, ...?". If not, hmmm... do you really have AlertDialog UI calls in code that you can't guarantee will have access to the UI (and thus context)? If so, reconsider your design.

presuming你想分享这个类在整个活动中，......答案就清澈见底。你想你的类的各种呼叫者是可用的，每一个可能与自己的上下文：所以调用者必须通过它的上下文到类作为一个参数：

Presuming you do want to share this class across Activities, ... the answer becomes clear. You want your class to be usable by a variety of callers, each probably with its own context: so the caller must pass its context into your class as an argument:

MyClass的（语境theContext，...）{...}

每个活动，服务等，然后进行调用，像这样：

Each activity, service, etc. then makes calls like so:

MyClass的（这一点，...）;

看起来很熟悉？

千万要小心！如果您共享code，你必须考虑不同的呼叫进入您的共享code平行，与所有的许多后果的可能性。超出了我们这里的范围，那是......

Do be careful! that if you are sharing code, you must consider the possibility of different calls coming into your shared code in parallel, with all the many ramifications. Thats beyond our scope here...

玩得开心：）

这篇关于为什么AlertDialog.Builder（上下文的背景下）只接受活动作为参数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！