RxJava-pull-requests #1399 FAILURE
Looks like there's a problem with this pull request

cast @mttkay.

There are no tests for OperatorBroadcastRegister yet, because Roboelectric seems to ignores calls
context.registerReceiver(broadcastReceiver, intentFilter, broadcastPermission, schedulerHandler), and I don't know how to write correct tests for it.

This looks pretty good to me overall, would love to test it out.

One suggestion I have: have you thought about using Subjects instead? I think they would model more closely what a broadcast is, since they can fire without a subscriber.

I thought about it, but it creates much more questions, and become not so clear.

1. It's more closer to "Producer" (I know that there is no such entity), than to Receiver.
2. We can not determine (before registering receiver which type of Intent will we receive (sticky or not), so we can not pick up right implementation of subject (behavior or publish)
3. And at least if user want to multicast observable, he/she can use operations like publish, replay, etc.
   He can even subscribe to observable several times (as it will create several independent Receivers)

RxJava-pull-requests #1400 SUCCESS
This pull request looks good

The intent matching within robolectric was fixed not too long ago here: robolectric/robolectric#1162

@dpsm I was having another problem.
As BroadcastOperator use call context.registerReceiver(broadcastReceiver, intentFilter, broadcastPermission, schedulerHandler) (event for method fromLocalBroadcast(Context context, IntentFilter filter)) it seems like roboelectric ignore this call at all.

However if i use context.registerReceiver(broadcastReceiver, intentFilter) everything works well in roboelectric, but I don't want to change semantics of code just to pass the tests.

Looks like there is still ongoing discussion here ... let me know when there is agreement on this being ready to merge.

@Yarikx I looked into the robolectric implementation of the Application shadow (https://github.com/xtremelabs/robolectric/blob/master/src/main/java/com/xtremelabs/robolectric/shadows/ShadowApplication.java) and indeed it does not implement the call you use to register the receiver. With that said, the test you have in the pull request fails?

Would you be interested in contributing to robolectric with a fix for it so the test can pass?

Yes. I would like.
Just let me day or two to setup environment, and start digging it.
On Jul 22, 2014 4:56 PM, "David Sobreira Marques" notifications@github.com
wrote:

@Yarikx https://github.com/Yarikx I looked into the robolectric
implementation of the Application shadow (
https://github.com/xtremelabs/robolectric/blob/master/src/main/java/com/xtremelabs/robolectric/shadows/ShadowApplication.java)
and indeed it does not implement the call you use to register the receiver.
With that said, the test you have in the pull request fails?

Would you be interested in contributing to robolectric with a fix for it
so the test can pass?

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

Actually I think it's already fixed in current version of robolectric (2.3) https://github.com/robolectric/robolectric/blob/afeb7321f3/src%2Fmain%2Fjava%2Forg%2Frobolectric%2Fshadows%2FShadowApplication.java, this project use 2.2.
I tried to increase version of it, but stuck with robolectric dependency to android-support lib, which gradle can not resolve. And actually I don't know how to resolve it without android gradle plugin.
Can anyone help with this test ?

@mttkay: If I will add tests for OperatorBroadcast, will it be candidate to be merged?

Sure.

By the way, anyone having problems building under IntelliJ lately? Something must have changed w.r.t. Gradle dependency configs, since anything in provided scope isn't recognized by IntelliJ as a compile time dependency anymore. I saw #1394 but it looks harmless to me, as it merely touches test dependencies?

Rebased it to #1528