Anonymous Classes for Listeners

Question

While working with Android GUI my approach to adding Listeners for GUI elements is usually:

Button helpBt = (Button) findViewById(R.id.help_button);
helpBt.setOnClickListener(new View.OnClickListener() {  
   /* Code */
});

Currently, I am at learning stage. However, will this approach be maintainence 'friendly' as I get working with more complex apps? If not, then what are suitable alternatives?

Answer 1

It depends on how much /* Code */ there is. If it's just a few lines, that's one thing. If it gets too large though, the reader will lose sight of the fact that you're creating an anonymous listener. I would say that if the anonymous listener is more than 5, or maybe 10 lines then you should use an inner class instead.

There comes a point where even an inner class is really too large though.

In general, questions about "When is too big?" are highly subjective, but failing to ask them, and failing to act on the answers leads to hard to read, difficult to maintain code.

Also, as biovamp pointed out, if you want to reuse the code, then you need to create a regular class.

Answer 2

you can use it this way

1 helpBt.setOnClickListener(mListenr);

private OnClickListener mListenr=new OnClickListener(
    @Override
    public void onClick(View v){
        int id=v.getId();
        switch(id){
            case R.id.click1:
            //Code here
            break;
            //and so on..
        }
     }
);

2

  implementd OnClickListener

write OnCLick for same Actiivty/Class and

helpBt.setOnClickListener(this);

Answer 3

I'm agree with Donald.McLean, but there is one more thing - anonymous class is not reusable.

So, if don't need more than one instance - this approach is good

Answer 4

I find "How big is too big" pretty easy to answer. Inevitably, you'll be back in the code a week later reviewing or making an addition. If you find it hard to read or code feels illogically grouped, refactor (eclipse is great for this).

If you have multiple anonymous classes fulfilling the same purpose, create inner classes with a nice comment header for grouping inner class functionality. If you start finding a need to say things like "I could reuse this instance elsewhere", then move it to a separate class file and setup a constructor for anything you were using before (such as a Context for example).

Point here is, start simple, refactor quickly as needed.

For me personally, about the only place I might find an anonymous class like that would be:

• In a simple about-us with a single button
• Spiking out functionality
• A static method for special case stuff

Answer 5

If the inner class contains code that needs to be unit tested then extracting it makes sense. Writing an efficient and robust unit test for an anonymous inner class can be difficult.

If the inner class simply passes data to the containing class without conditions or processing, then it makes sense to keep it as an anonymous inner class.