Why does a callback method needs to return something?

Question

I have never before seen such a thing, so let's say I have such listener object:

MyWhateverListener dafuqListener = new MyWhateverListener() {

  @Override
  public void onSuccessCall(String s) {
    // success call
  }

  @Override
  public void onFailCall(boolean b) {
    // fail call
  }

  @Override
  public boolean onDafuqCall(int i, boolean b) {
      // some whatever code
      return false;
  }
};

Everything fine, the appropriate method will be called back to, when some action succeedes, but what's with this return inside onDafuqCall method, why is it needed, where it will return something?

P.S. This interface is from an Android ads provider's SDK.

Answer 1

It is quite unclear what you ask but I'll give it a shot.

Interfaces are a way to allow objects to follow a specific pattern. They come handy, for instance, when I have an interface called "Listener" and five implementations: ActionListener, MouseListener, KeyListener, CloseListener, StateChangeListener. If I want to have a method allowing the user to register a user, instead of having to make separate "registerListener" methods for each implementation I can have: registerListener(Listener l).

Now back to your post, Interfaces may contain methods with return values, as an example if I have an interface called Event, and it contains a method called isCanceled() that returns boolean, then if I have an implementation called "ClickEvent" and I want to check if this event (after it has been called) is canceled by anyone or anything I'll invoke the isCanceled() method and that should return a value, because it is handled by the implementing object.

So to wrap this up, the return value is needed by the piece of code that calls the listener to get information. If we look in Java interfaces and their implementations we can find a ton of examples. You can check for yourself by looking into the java.uti.List interface source and an implementation like java.util.ArrayList

More information can be obtained from the Docs:

• https://docs.oracle.com/javase/tutorial/java/concepts/interface.html

• https://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html

EDIT #1: Here is the example explained above, represented in code:

The event interface:

package com.fillpant.examples;

public interface Event {

    public boolean isCanceled();
    public void setCanceled(boolean value);

}

The ClickEvent (that implements Event):

package com.fillpant.examples;

public class ClickEvent implements Event {

    private boolean canceled = false;

    @Override
    public boolean isCanceled() {
        return canceled;
    }

    @Override
    public void setCanceled(boolean value) {
        canceled = value;
    }

}

The place where ClickEvent is called. Here I demonstrate why the return value is needed (See the isCanceled() method):

package com.fillpant.examples;

public class EventCaller {
//This class calls an event, and all the listeners will have to handle it;

    public void callClickEvent(){
        Event e = new ClickEvent();
        for(Listener l : all_registered_listeners){//this is hypothetical, if we had listeners.
            l.event(e);
        }
        if(e.isCanceled()) return;
        else{
            //DoStuff
        }
    }

}

If you have any question don't hesitate to ask :D

Answer 2

This is my understanding about the topic: Generally Listener/call-back methods don't need to return anything and they are called in response to an event. e.g. onClick() method of OnClickListener.

OnClickListener onClickListener = new OnClickListener() {

    @Override
    public void onClick(View v) {
        //some click handling code
    }
};

But if they are part of an event-chain then a boolean return type is used to either abort of continue the execution of events. e.g. onDrag() method from OnDragListener.

OnDragListener onDragListener = new OnDragListener() {
    @Override
    public boolean onDrag(View v, DragEvent event) {
        //some drag handling code
        return false;
    }
}

Documentation of this method says "return true if the drag event was handled successfully, or false if the drag event was not handled. Note that false will trigger the View to call its onDragEvent() handler." so it is not very uncommon to have return in call-back/event-handling methods if they are part of chain of events. And what should be returned is part of the documentation of the API.

Answer 3

This is really quite a normal thing. A listener/observer interface is paired with a subject/event throwing class. Often you want your listeners to be totally disconnected from the behaviour of the subject, to the extent that the subject neither knows nor cares about how many listeners are registered. This is the 'pure' pattern. And this is the most common and it makes sense for all the methods to be void, since they are called only by the subject and the subjects behaviour does not depend on its listeners.

However, sometimes it makes sense for a listener to have other methods not intended to be called by the subject, and for the listener to act as a bridge between the state of the subject and some other part of the program. One common example is making special listeners for debugging. Here you make a new listener which extends your previous listener but it also keeps track of exactly when it is called by a subject, it then has a method with a return value so that your testing code can access this state, and see exactly what that listener was doing.

Finally, it occasionally makes sense to have listeners which affect the behaviour of the subject. In this case return methods are necessary. But this is rare and not without danger, it is sometimes used e.g. to make sure that things are deleted in a chain in the right order. So you stop the chain of deletes if you failed to delete a child. It has a name, but I cannot remember exactly what this pattern is called right now.