Listener is usually a type of interface implemented by object classes that respond to certain actions. If you have an OnFileContentChangedListener interface, for example, it will declare a method called OnFileContentChanged. Anyone who wants to respond to file change events must be from a class that implements this interface. But that's probably not going to be enough. You must register these objects as listeners of the event with the object that notices that such an event occurred. An example, in the case of Android, is when you make botao.setOnClickListener (yourListener), where yourListener is a copy of a class that implements OnClickListener. What will happen is that the button, when receiving from the user interface manager a signal that there was a click on it, it will fetch from its internal list of interested listeners to know that there was a click and call the OnClick method of each one of them.
As you can see, there is no magic: someone has to call his method. In the case of the OnFileContentChangedListener, there will have to be an object that registers file change listeners. This object will have to have some way of knowing when there was a change in the file to call the OnFileContentChanged methods of the registered listeners. This may or may not be done by polling (staying all the time going there and checking the modification date, for example). Even if it is, it is still much better than every interested object to be doing their own polling. In the real world, many events of this type work through signals, as polling is not very efficient.
In short: your listener will not stand by waiting. He will register as a listener and move on with life. Who will be responsible for advising when the time comes is the "observer". On how to implement a file watcher, check the implementations of the WatchService (Java 7) interface. If you need more information, I'll add it when I'm on the PC.