You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a project where we would love to use MBassador. In our use case, though, we'd prefer to avoid the use of annotations to mark hander methods, preferring instead the more 'old-fashioned way' where we have listeners that implement a particular interface.
More specifically, we have a class like this
public interface OurSpecialListener{
public void onEvent(Event e );
}
and then classes implement this interface in order to listen.
Is there a way to use MBassador in this situation? For a greenfield project, we agree that the annotations way is cleaner, and we're completely sold that the inner workings of MBassador is awesome, so we'd like to get the performance benefits, but stay compatible with our current listener structures
The text was updated successfully, but these errors were encountered:
It's true. #67 would provide you with a convenient solution. Unfortunately, I currently lack the time to implement this enhancement. Maybe there is someone who wants to pick up that issue? Most of the work would have to be done within the MetadataReader. It shouldn't be too hard to do but a bit of pain since the Java reflection API really is far from convenient.
We have a project where we would love to use MBassador. In our use case, though, we'd prefer to avoid the use of annotations to mark hander methods, preferring instead the more 'old-fashioned way' where we have listeners that implement a particular interface.
More specifically, we have a class like this
public interface OurSpecialListener{
public void onEvent(Event e );
}
and then classes implement this interface in order to listen.
Is there a way to use MBassador in this situation? For a greenfield project, we agree that the annotations way is cleaner, and we're completely sold that the inner workings of MBassador is awesome, so we'd like to get the performance benefits, but stay compatible with our current listener structures
The text was updated successfully, but these errors were encountered: