My Android Activity contains multiple buttons that all need an OnClickListener. I've seen lots of different ways of doing this such as::

  • Implementing the interface in activity class
  • Creating a separate class that implements the interface
  • Defining an anonymous inner class for each button.

I've seen many examples of each approach. However, its not clear to me why one approach would be used instead of another. Are the differences between these approaches stylistic or are there reasons that make one approach better?

2 Answers 2


As with many things, the correct approach depends on what you are trying to do for the specific button and what else you are doing with the activity.

Activity class implements interface:
This is a good option when you only have one type of task to execute when this listener is called. An example of this would be a simple form with a number of fields and a save button. I prefer to not have my event listener check the source of the event in order to decide what actually needs to be done. I know that some may say this is a style thing, but I believe that by not requiring the listener to do this check makes the code easier to follow as you will know exactly what is being called for each event.

A different class implements interface:
As I said above, I prefer this option for when I have multiple items that can fire the same event. Extending the above example, lets add a clear button that also requires a click listener. Create one listener that that preforms the save actions and one that preforms the clear actions. Each listener is only added to the components that will produce that action.

This implementation has an additional benefit that you can utilize if you care. The benefit is that it prevents other classes from triggering the event inside of your activity class. Since the interface method must be public, anyone with a reference to the class can fire the event. If you want fine grained control over who can do what in the application, a separate class prevents anyone with a reference to the activity to trigger your form to be cleared or saved (or potentially breaking the code if the listener utilizing the source, but does not handle bad input).

An anonymous inner class implements interface:
This is really just a specific way to construct the second option of using a different class as the implementation. This option can even further restrict who has access to trigger the event as no one else can create an instance of the class. However, I think the more important factor between the two options is how much work is being done. Clearing a few text fields is a simple and straight forward operation. However, the process of saving the for can involve a number of task is you are validating the input (which you should be doing), writing to a database to store the values and triggering some post save action. In this case, making a separate class with its own file will provide a clearer divide between the input form and the data processing. This in turn keeps the form code instead of a larger file with multiple inner classes nested inside.

  • Wow, thanks for your response. In terms of overhead, is it more costly to create multiple listener classes?
    – slayton
    Commented Sep 22, 2011 at 18:36
  • @slayton: There will always be costs no matter what you do. The question should be "Does the difference matter to you?" There is a weight to making more objects, but the execution time will be longer if your listener has to go through a list of sources to decide what to actually do. If memory usage and performance are important to you, then you should profile the code and decide what is best based on your requirements. However, I would doubt that this would be the bottle neck of your code. Until shown otherwise, make your decisions the make the code clearer and better organized. Commented Sep 22, 2011 at 18:58

A fourth way is to set the onClick attribute in the layout:

<Button android:onClick="clickHandlerForButtonX" />

which has this corresponding method in the Activity:

public void clickHandlerForButtonX(View v) {
    //Handle Button X here
  • interesting, I wasn't aware you could do that. Although this seems to be an Android specific mechanism of dealing with button clicks.
    – slayton
    Commented Sep 22, 2011 at 20:25
  • I usually go with the "Activity class implements interface", though - that way, you have all click related stuff at the same place.
    – orjan
    Commented Sep 22, 2011 at 20:50
  • this particular method does not work with fragments. Commented Sep 30, 2015 at 12:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.