Question 1:Unfortunately the one in which you you say is most intuitive is the least used in Android. As I understand, you should separate your UI (XML) and computational functionality (Java Class Files). It also makes for easier debugging. It is actually a lot easier to read this way and think about Android imo.

Question 2:I believe the two mainly used are #2 and #3. I will use a Button clickButton as an example.

2

is in the form of an anonymous class.

Button clickButton = (Button) findViewById(R.id.clickButton);clickButton.setOnClickListener( new OnClickListener() {                        @Override            public void onClick(View v) {                // TODO Auto-generated method stub                ***Do what you want with the click here***            }        });

This is my favorite as it has the onClick method right next to where the button variable was set with the findViewById. It seems very neat and tidy that everything that deals with this clickButton Button View is located here.

A con that my coworker comments, is that imagine you have many views that need onclick listener. You can see that your onCreate will get very long in length. So that why he likes to use:

3

Say you have, 5 clickButtons:

Make sure your Activity/Fragment implement OnClickListener

// in OnCreateButton mClickButton1 = (Button)findViewById(R.id.clickButton1);mClickButton1.setOnClickListener(this);Button mClickButton2 = (Button)findViewById(R.id.clickButton2);mClickButton2.setOnClickListener(this);Button mClickButton3 = (Button)findViewById(R.id.clickButton3);mClickButton3.setOnClickListener(this);Button mClickButton4 = (Button)findViewById(R.id.clickButton4);mClickButton4.setOnClickListener(this);Button mClickButton5 = (Button)findViewById(R.id.clickButton5);mClickButton5.setOnClickListener(this);// somewhere else in your codepublic void onClick(View v) {    switch (v.getId()) {        case  R.id.clickButton1: {            // do something for button 1 click            break;        }        case R.id.clickButton2: {            // do something for button 2 click            break;        }        //.... etc    }}

This way as my coworker explains is neater in his eyes, as all the onClick computation is handled in one place and not crowding the onCreate method. But the downside I see is, that the:

1. views themselves,
2. and any other object that might be located in onCreate used by the onClick method will have to be made into a field.

Let me know if you would like more information. I didn't answer your question fully because it is a pretty long question. And if I find some sites I will expand my answer, right now I'm just giving some experience.

#1 I use the last one frequently when having buttons on the layout which are not generated (but static obviously).

If you use it in practice and in a business application, pay extra attention here, because when you use source obfuscater like ProGuard, you'll need to mark these methods in your activity as to not be obfuscated.

For archiving some kind of compile-time-security with this approach, have a look at Android Lint (example).

#2 Pros and cons for all methods are almost the same and the lesson should be:

Use what ever is most appropriate or feels most intuitive to you.

If you have to assign the same OnClickListener to multiple button instances, save it in the class-scope (#1). If you need a simple listener for a Button, make an anonymous implementation:

button.setOnClickListener(new View.OnClickListener() {    @Override    public void onClick(View view) {        // Take action.    }});

I tend to not implement the OnClickListener in the activity, this gets a little confusing from time to time (especially when you implement multiple other event-handlers and nobody knows what this is all doing).

I prefer option 4, but it makes intuitive sense to me because I do far too much work in Grails, Groovy, and JavaFX. "Magic" connections between the view and the controller are common in all. It is important to name the method well:

In the view,add the onClick method to the button or other widget:

    android:clickable="true"    android:onClick="onButtonClickCancel"

Then in the class, handle the method:

public void onButtonClickCancel(View view) {    Toast.makeText(this, "Cancel pressed", Toast.LENGTH_LONG).show();}

Again, name the method clearly, something you should do anyway, and the maintenance becomes second-nature.

One big advantage is that you can write unit tests now for the method. Option 1 can do this, but 2 and 3 are more difficult.