Add @FromEventBus annotation

[GoogleCodeExporter]

It is a proposal issue

Just to recognize which methods in presenter are related to event bus and which 
are not just looking in the presenter code.

Original issue reported on code.google.com by shaman.sir on 25 Jun 2011 at 8:37

[GoogleCodeExporter]

What would be the behavior of this application? Would you use it as a simple 
marker or woud you except some control from mvp4g?

Only my handling methods starts by "on" so I can easily recognize method 
related to the event bus.

Thanks

Original comment by plcoir...@gmail.com on 27 Jun 2011 at 2:36

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I think a simple marker is ok for start, optional as @Override is, for example. 
(and Annotation Processing Factory control about its actuality)

We are recently use the other names for events, and often the events like 
onclick also star with "on", so this marker can be something to know that this 
method is from eventbus "for sure" :). (And may be the same/similar marker for 
historyconverters)

Original comment by shaman.sir on 27 Jun 2011 at 2:58

[GoogleCodeExporter]

I can see the utility in this.  It would be nice to be able to skim the code 
visually and pick out which methods are intended to handle events.  Even better 
would be to get some warnings when I screw up.

For instance, when I remove a method from the event bus, I sometimes forget to 
remove the corresponding handler method.  That leaves me with extra, useless 
code that's never going to be executed.  Likewise, if I rename a method on the 
event bus, I get errors for the event bus class (that the handler doesn't 
handle the event), but no errors or warnings for the handler class itself.

If my handler method was annotated as @EventHandler("eventName") then it might 
be possible (via APT?) to give an error or warning for that method, like "this 
method handles a non-existent event".  That would provide some symmetry - the 
errors view would show all of the changes that need to be made to correct the 
situation.

I don't know what the underlying implementation looks like, but maybe it would 
be possible to look for annotated handler methods first, and fall back on the 
inferred handler methods (based on the onEvent nomenclature)?  That way, you 
can make the annotation optional.

Anyway, I consider this a nice-to-have, not a requirement... but it would be 
useful.

Original comment by prono...@gmail.com on 23 Feb 2012 at 7:44