Question

One of the struggles I have as android development newbie is that my classes have the tendency to get quite extensive with all the inner classes etc for gui listener and so on. So I came up with one solution to decompose my classes which I would like to hear some feedback form the android experts around.

To put it into an example. I dont want to define all the dialogs a particular Activity has within the same class (there is a series of Dialogs taking place in that activity)
So I implemented a DialogManager class to define and hold all the potential Dialogs, hand over a handler instance from the Activity to this DialogManager and use it to inform the Activity about what gui events have happened.

Here a snippet of this DialogManager class, mHandler is the handler which calls back to the Activity

mDownloadDialog = new ProgressDialog(mContext);

mDownloadDialog.setButton(AlertDialog.BUTTON_NEGATIVE, "Cancel",
                new DialogInterface.OnClickListener() {

    @Override
    public void onClick(DialogInterface dialog, int which) {                      

                        mDownloadDialog.dismiss();

                        Message message = mHandler.obtainMessage();
                        message.arg1 = DOWNLOAD_DIALOG;
                        message.arg2 = AlertDialog.BUTTON_NEGATIVE;
                        message.sendToTarget();
                    }
                });

So this works and I am happy with the more organized source code now but I wonder if the Handler class is the proper way to do this or if this is a bit of an overkill and there are some better ways to achieve the same result which are recommended.

EDIT:
As pointed out by boulder

handler messages aren’t executed immediately

So with this in mind using Handler is not the proper way to go.

Next idea would be as simple as defining in the given example an Interface

public interface DialogEventReceiverInterface { 
public void dialogEvent(int dialog,int button);
}

implementing that interface in the Activity, hand the activity over to the DialogManager and call dialogEvent in the case an event takes place. Pretty straight forward it seems to me now …

Answer 1

I appreciate that you’re not necessarily specifically asking about tidying up the clutter associated with Dialogs, but rather the Dialog code you show is just an illustration of a wider problem I think you’re asking for a design pattern to solve.

However, focusing on your specific example of Dialogs, the Android APIs now already provide a much cleaner solution for this in the form of Fragments and specifically DialogFragment. Using the Fragment classes is a much cleaner way of doing things because you generally define your DialogFragments in separate class files. The Android API documentation contains very good guidelines about how to handle communication between the DialogFragments and parent Activity.

Before I switched to using Fragments for everything, I too ended up with lots of Dialogs being created within Activity classes and I tried various design patterns with dialog managers, etc. However, the Fragment approach is so much cleaner in my opinion.

Compatibility with earlier Android versions is no problem because you can use the V4 support package.