Why strange naming convention of "AlertDialog.Builder" instead of "AlertDialogBuilder" in Android

Question

Why not

AlertDialogBuilder builder = new  AlertDialogBuilder(this);
builder.setTitle("foo");

instead of

AlertDialog.Builder builder = new  AlertDialog.Builder(this);
builder.setTitle("foo");

Update: I want to know the reason behind this kind of writing/organization

Answer 1

According to the Javadocs, nested classes (and in this case, static nested classes) are generally used for three things:

1. Logically grouping classes which will only ever be used together.
2. Increasing encapsulation.
3. Increasing readability and maintainability of code.

Point #3 is one reason a lot of developers use static nested classes. Let's take, for example, the ViewHolder pattern in Android development. In a ListAdapter, we can make caching of lists easy by managing the contents of each list element in a ViewHolder (or similarly named inner class). In this situation, it is easy to notice that this specific ViewHolder is only for this class, and when we change this one, we don't change every single one. This means we don't need a List1ViewHolder, List2ViewHolder, ..., ListNViewHolder. Each List-type element can have its own ViewHolder.

Point #2 is a bit less relevant to this point, because we're dealing with static inner classes (that's what Builder is). But in this case, it prevents elements of the inner class from being accessed by the outer class.

Point #1 is the big one here, which is why I've saved it for last. Think of the situations in which you will use AlertDialog.Builder. I can guarantee, with 100% certainty, that every single time you use AlertDialog.Builder, it will be in the building/creation/handling of an AlertDialog. Consequently, this means that every use of AlertDialog.Builder is tied to how AlertDialog works. (This ties in somewhat with point #3; it's easier to maintain two classes in one file than to have them separated.)

Similar to points #1 and #3, but also of its own rite, is the fact that by keeping Builder within AlertDialog, we are not polluting the android.app package namespace. We still keep just AlertDialog within it; but Builder hides within that.

Android is not the only system that does this; the MotiveWave SDK does this also, as do the Adobe Access and eBay SDKs (which I lack links for). I also believe Java EE uses this methodology as well. You will also see it often in Enum types, which in turn is because of the reasons covered in point #1.

Now, you asked why we use AlertDialog.Builder instead of new AlertDialog(), and build it from the object instead of from the builder. The answer here is the same as the factory method pattern seen commonly in Java and other object-oriented programming languages. Notably (from Wikipedia), there are three reasons for this:

1. The creation of an object precludes its reuse without significant duplication of code.
2. The creation of an object requires access to information or resources that should not be contained within the composing class.
3. The lifetime management of the generated objects must be centralized to ensure a consistent behavior within the application.

These explain themselves pretty well; they speak against code duplication (being able to handle all creation functionality within one class), unauthorized access (bad encapsulation practices), and consistent behavior of construction. Also unlisted here is code readability.

I suspect--on a hunch--that AlertDialog is a very resource-intense process. It halts parts of the OS, keeps others running, has to load system resources, and so on. As this answer details, we do not want to provide direct access to the outer class (AlertDialog in this case). This allows the Builder to handle all resource-intensive operations properly. It also keeps us from having to handle esoteric situations which the OS developers considered, but we did not.

So, to conclude, this is actually a decently common design pattern, but not one that has a real explicitly defined meaning. Rather, it is for ease of use, understanding, and maintainability. You mention a concern about design considerations above; I wouldn't worry too much on that. Just keep in mind that static inner classes should always be solely related to their outer class, and you should be fine.

Answer 2

Builder is the static inner class inside the AlertDialog class. So to create a Builder class object, you need to call AlertDialog.Builder.

As there is no class like AlertDialogBuilder so you cannot do that.

If you want you can also use as like bellow.

Builder builder = new Builder(this);
builder.setTitle("foo");

But to use like this you need to import the Builder class to your class like

import android.app.AlertDialog.Builder;

instead of just

import android.app.AlertDialog;

A simple example

class A{
     static class B{}
}

you cannot use

AB obj = new AB();

you have to use

A.B obj = new A.B();

Hope you are clear now.

Answer 3

I'll try and clear you up behind this kind of organization.

First of all, Builder is a class inside the AlertDialog class. Why would you create a class inside another class? I personally only create nested classes if I want to add more functionality to an existing class and don't believe that from a designing point of view that the class should be extended. I'm sure one could argue about this one, since there are tons of different ways to add more functionality to a class; yet nested classes can be preferred above others (for some people).

Here's oracles point of view on nested classes.

I'd only use nested classes if I find that it makes the code more maintainable and intuitive.

In this case I believe the guys over at Google found that instead of creating a new class called AlertDialogBuilder compared to AlertDialog.Builder, is because both yield the same results; a dialog displaying some information on the screen with some buttons. The only difference between both (I think) is that you can set positive, neutral and negative button on the AlertDialog.Builder (which gives more functionality to the class, yet not necessary more that the class should be extended, again personal opinion).

In the end what matters is that the code works (hopefully without any bugs), is maintainable, readable and intuitive. There's no definite answer to your question, since people have different opinions on this topic.

I hope this helps.