looks okay to me. Been using event listeners for a while on android. It uses java for its programming language. Event listeners are used for touch events for example. Also checking for sensor data I think.
[font=arial, verdana, tahoma, sans-serif][size=2]Here analogListener is a member variable of the base-type AnalogListener, that is initialized (i.e. set) at construction time. It is set to an instance of a anonymous class derived from AnalogListener. That sub-type overrides a single method of AnalogListener, namely [color="#000088"]void[color="#000000"] onAnalog[color="#666600"]([color="#660066"]String[color="#666600"], [color="#000088"]float[color="#666600"], [color="#000088"]float[color="#666600"]). The anonymous class will appear like MyClass$1.class (or perhaps an increased number if MyClass has more than one anonymous classes) in the build directory.
private AnalogListener analogListener = new MyListener();
}
but avoids the explicit naming of the inner class. As a consequence the anonymous inner class can be instantiated at just a single place in code (because you have no name to refer to it), but that is sometimes sufficient, especially for listeners.
It is further allowed to do this in routines, too. E.g. an alternative would be
[/font]
public class MyClass {
public MyClass() {
this.analogListener = new AnalogListener() {
...
}
}
private AnalogListener analogListener;
}
so it is also possible to choose the concrete anonymous class from code or to instantiate it only if its necessity is determined. This comes in handy especially when a client object is expecting a "listener" instance. E.g.
public class MyClass {
public void doAnything() {
client.addListener(new AnalogListener() {
...
});
}
}
is perfectly valid. Notice the "side-effect" that any non-static inner class has: It inherently refers back to the embedding class, so it can work fine as a mediator between the object listening to and the instance of MyClass, and that without compromising the interface of MyClass with that functionality.
