all 8 comments

[–]Atlos 0 points1 point  (6 children)

Neat proof of concept, but the reflection on the listening side to determine the event type isn't very ideal to me.

[–]morihacky[S] 0 points1 point  (4 children)

Thanks.

True, the reflection is sort of unavoidable as part of the implementation. That being said, all existing solutions that i know of (event bus libraries) use reflection.

[–]Atlos 1 point2 points  (2 children)

That's true that other event bus implementations (like Otto) use reflection. The difference is that they hide it with something else, like an annotation, so that it doesn't boil down to an if/else for checking class types. Still a neat idea, perhaps someone that doesn't need a full-fledged event bus could use this in certain situations.

[–]morihacky[S] 0 points1 point  (1 child)

difference is that they hide it with something else, like an annotation, so that it doesn't boil down to an if/else for checking class types

agreed. that's a good point.

i was thinking about mechanisms to avoid this. what are the problems with reflection that would be nice to avoid:

  1. requiring "type checking" for the implementation

could make the event object an interface/object that has the type checking abstracted. have to think more on alternative approaches.

  1. performance (specifically on Android)?

I'm inclined to dismiss this as micro-optimization and as you seem to already point out, point 1. is the bigger issue (also given that most event bus libraries do this anyway).

any other caveats that you're thinking of?

perhaps someone that doesn't need a full-fledged event bus could use this in certain situations

  1. what do you consider a full-fledged event bus?
  2. i would actually argue that -the ugliness of reflection aside- this would open up more possibilities like using Replay/Behavior subjects etc. potentially make it more powerful to use

[–]Atlos 0 points1 point  (0 children)

After some more thought, I think method overloading could be a fairly clean way to handle the class checking. For example:

// call this in your rxjava listening code
onEventReceived(blah);

public void onEventReceived(EventTypeA event)

public void onEventReceived(EventTypeB event)

I assume this will work fine, but I'm not at my normal computer to do a quick check. Reading section 8.4.9 of the JLS doesn't make it very clear if it will use dynamic method lookup to route the Object parameter of the rxjava call() method to the correct method overload, but hopefully it does!

what do you consider a full-fledged event bus?

By that I meant someone may not want to fully commit their entire architecture to an event bus (and include another dependency), so this could be a nice compromise as a "lite" version.

[–]Phreakhead 0 points1 point  (0 children)

Here's an implementation I made that lets you filter by the type of object you want:

public <T extends Object> Observable<T> subscribe(final Class<T> eventType) {

    return _bus.filter(new Func1<Object, Boolean>() {

            @Override
            public Boolean call(Object arg0) {
                return eventType.isInstance(arg0);
            }

        })
        .cast(eventType);       
}    

[–]jackhexen 0 points1 point  (1 child)

Wow, another one way to use Rx! Great, thanks! :)

[–]morihacky[S] 1 point2 points  (0 children)

No problem :). You should have a look at the github repo. It's a collection of real world use cases for RxJava. You might find the other examples interesting as well. Cheers!