Awesome! Annotations were planned for EventBus version 3. It makes sense today, because Android 4 is adopted widely these days. With Android 4, the performance difference should not really matter anymore. You can verify with the performance app project. Looking forward to check your changes, however it might get December - so no hurry. We just did a release anyway. Thanks!

Sounds good! Here is a link to the actual changeset.

rjbrock@e42992a

If things look ok (so far) I can flesh this out with more comments and unit test coverage as well as docs.

I see it's possible to do either method names searching and Annotations? That's nice for transition. I'd suggest to move that switch to the builder. The forthcoming release (e.g. 3.1) can prune the method name option afterwards.

Let's think a bit about consequences of adopting annotations:

• Options should move from registration to annotation (sticky, priority)
• Lots of unit tests have to be adjusted
• New unit tests are required, e.g. there may be multiple subscriber methods wired to the same subscriber, but with different options (sticky, priority)
  • It would be interesting to have something like @SubscriberOption for subscriber classes at some point. E.g. to make the subscriber weakly referenced (How about to use SoftReference or WeakReference when register to EventBus #54). @SubscriberOption(WeaklyReferenenced) for example.

What do you think?

PS.: Please ensure you are working on the latest version, there were some changes in this area...

Giving it some more thought, maybe we should just drop method name searching completely? It will get messy supporting both. Forcing people to add an annotation to their onEvent method should not be a big problem, I think.

I am totally on board with dropping method name searching completely. My goal with the original changeset that I linked you to was to be as minimally intrusive as possible.

I will update my changes to remove method name searching altogether then.

Do you want me working off of my repo for now? I will create an annotations branch.

Sounds good. Next weeks will be busy for me, but I'm really looking forward to have a look.

How is this going to work with inheritance? When using Otto for example, you can't put an annotation on a superclass and have the subclass get the message because Otto doesn't traverse the class hierarchy for performance reasons.

@MariusVolkhart This doesn't change any behavior. This only changes the way that reflection is used to find the methods that are subscribing.

Ok I did some more reading. I remembered there being a limitation to inheriting annotations, but it's just that annotations can't come from interfaces, they have to come from super classes. Looking through #130 I see it does traverse the entire class hierarchy to find the annotations so that should work.

I merged the branch of @rjbrock into this repo's annotations branch:
https://github.com/greenrobot/EventBus/tree/annotations

To make it a bit faster, I also did some work on SubscriberMethodFinder. Registration got like 30-40% faster, but it's still much slower than without annotation-support (tested on Android 5.0). Maybe this needs some more work.

Update: added annotation processor to index @ Subscribe annotation during compilation. Performance is pretty good like this. Still alpha state.

@greenrobot awesome, thanks for taking a look at this. Any help you need from me? L

@rjbrock and everyone: it would be cool if you could give it a shot. I'd be especially curious about your feedback on annotation processing at compile time. Thanks!

@greenrobot and @rjbrock: I have been extensively using EventBus in projects I work on and I have been tracking the progress and changes you're making to switch annotations. I see that anonymous class support may get dropped because they cannot be annotated. I assume many people have been registering anonymous classes to cope with Activity/Fragment lifecycle hell and ensure events get delivered only in proper state of components. Is it possible to add as a feature partial object subscription (eg. add something like EventBus.register(Object subscriber, Class eventTypes) and a corresponding unregister(Object subscriber, Class eventTypes)). Would adding some sort of filtering to SubscriberMethodFinder hurt performance too much?

The reason to suggest that is that it would make subscriptions more flexible and would reduce boilerplate when using with Activity/Fragments when there would be events requiring view interaction/updating or Fragment transactions which can be done only while some tricky conditions are met.
I am willing to help if you think that is feasible to add my suggestion as feature.

@g-neykov Agreed. I think there is no way to detect anonymous classes by the annotation processor. Anyone is welcome to verify this shortcoming, maybe there's some work around. Thanks!

I don't want to (re-)inroduce "EventBus.register(Object subscriber, Class<?> eventTypes)" to keep the API simple.

I see. Anyway, a big "Thank you" to you and all other contributors for the
wonderful library.

On Tue, Apr 7, 2015 at 7:53 AM, greenrobot notifications@github.com wrote:

@g-neykov https://github.com/g-neykov Agreed. I think there is no way
to detect anonymous classes by the annotation processor. Anyone is welcome
to verify this shortcoming, maybe there's some work around. Thanks!

I don't want to (re-)inroduce "EventBus.register(Object subscriber,
Class<?> eventTypes)" to keep the API simple.

—
Reply to this email directly or view it on GitHub
#126 (comment).

When will snapshot builds be available? They are not currently available on Sonatype's snapshot repository (as stated in README.md).

@greenrobot i can confirm that anonymous classes are not available for annotation processing.

Do you plan to release a snapshot which contains the annotations branch?

Could you build a release including this? Thanks.

+1 Awesome! Love it

Yesterday, I announced a beta version available on Maven Central: http://androiddevblog.com/eventbus-3-droidcon/

Looking forward to your feedback!

Awesome！

This feature is implemented and can be closed.