0

Is this generally a good practice to adopt?

I am working through the tutorials and got to the part where button listeners are being implemented:

 @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_quiz);

        mTrueButton = (Button) findViewById(R.id.true_button);

        //and here is the anonymous inner class
        mTrueButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
            }
        });
    }

Am I better off learning this style or is there another way I should be learning this for the sake of good practice? It seems a little counter to my basic understanding of OOP where things seem to be... separated and modularized, if that makes sense.

John Smith
  • 11,678
  • 17
  • 46
  • 51
  • This is quite a common practice. Whether or not it's good or bad, is rather a matter of opinion. – Aleks G Jan 11 '15 at 19:19
  • So as a beginner is it not a big deal if I adopt this style? What would the code look like without using the anonymous inner class? – John Smith Jan 11 '15 at 19:20
  • There are a few different ways of listening for a button click. Which one is appropriate depends on the broader context. If this is the *only* place in the code that needs to respond to this button, and the code in the click handler is trivial, I don't think it's a bad practice. But perhaps Big Nerd Ranch are using this as an introduction to this style, rather than because it's be best practice—much example code in tutorials is a little contrived. – Matt Gibson Jan 11 '15 at 19:21
  • So what if I think it's the only place in the code, but then later I need to change it and have it be used in several? Wouldn't it have been easier to keep it separate in the first place? – John Smith Jan 11 '15 at 19:22
  • Yes. There are times when you can be pretty confident that's not going to happen, though, and in that case it may be cleaner and more separate to handle the clicks like this than add more code to a busy click handler that's already doing other stuff. And this style is also used when, say, dynamically creating an AlertDialog, where you can be more certain that you'll only be handling the click in one place, so it's still useful to know about. – Matt Gibson Jan 11 '15 at 19:26

1 Answers1

1

Yes, there is another way that I often prefer (especially in big projects), your class can implement listeners

So your Activity/Fragment can be declared this way

public class MyActivity implements View.OnClickListener{

and your view object, button in this case, would set it's listener this way

mTrueButton.setOnClickListener(this)

and then you would have another class called onClick() where ALL of your clickable view elements can now have their code

@Override
public void onClick(View v){

     switch(v.getId()){
          case R.id.true_button:

          break;
     }


}
CQM
  • 42,592
  • 75
  • 224
  • 366
  • Additionally, rather than setting the listener in code you can also set it in XML: http://stackoverflow.com/questions/4153517/how-exactly-does-the-androidonclick-xml-attribute-differ-from-setonclicklistene – Matt Gibson Jan 11 '15 at 19:22
  • @MattGibson yes, but some view elements ignore the XML, so you still wind up having to set the listener and the `clickable` attribute in code – CQM Jan 11 '15 at 19:23
  • Right now I have "public class QuizActivity extends ActionBarActivity" -- how do I keep it extending ActionBarActivity while also implementing View.OnClickListener? – John Smith Jan 11 '15 at 19:29
  • @JohnSmith `public class QuizActivity extends ActionBarActivity implements View.OnClickListener`. But I usually have my own `BaseActivity` which would extend `ActionbarActivity`, and then QuizActivity would extend BaseActivity. BaseActivity would initialize `context` and the actionBar object amongst other things, so then all of it's activities would already have it – CQM Jan 11 '15 at 19:31