Initial support for scheduling on Android Handler threads #318
Conversation
Should this be shared with other contribs through the parent module? Lots of copy and paste here.
Forwards to "schedule later" with delay of 0 now.
|
RxJava-pull-requests #196 FAILURE |
| apply plugin: 'eclipse' | ||
| apply plugin: 'idea' | ||
| apply plugin: 'osgi' | ||
|
|
There was a problem hiding this comment.
I basically copied this file over from the Swing contrib module. There's a lot of cruft in here which I think can be remove or at least shared with the parent modules? I'm thinking about IDE project file generation and JavaDoc setup.
There was a problem hiding this comment.
Yes that's probably the case, I have not yet attempted doing that as I'm not the most comfortable with Gradle.
|
RxJava-pull-requests #197 FAILURE |
|
Unit testing in Android land is a bit tricky as the sources for android are all stubs which throw exceptions. There are quite a few final methods that exist as well in many components making mocking not possible with libraries like mockito. As a result a framework which is popular called Robolectric has tried to help developers by providing a barebones implementation of the android sdk (using some classloader magic) which is helpful when wanting to write unit tests (Other option is to write integration tests which run on device which is slow and not useful in this instance). Why is this relevant in this case? To get robolectric up and running we need some default folders and files along with a custom test runner. To be consistent with the rest of rx core we have to put these in the main src package but really we should be not shipping these folders/files with the release artifact. So one solution is to have a custom build step to strip these out (which is probably preferred) and the other is to break convention and have a separate test directory. @benjchristensen would be good to get your thoughts on how you would want to move forward with this. |
|
@mustafasezgin go ahead and put the unit tests in /src/test if that's what makes sense for this module. I mix and match as needed. The RxJava build files should pick up tests in both /src/main and /src/test and run them via the ./gradlew build scripts already. Also, we should be stripping *UnitTest files from the published artifacts but aren't right now because of an odd issue with Scala. That will be solved when we start publishing different artifacts for different languages once this pull request finally hits: #304 In short, put your tests where you need/want in this rxjava-android module. |
|
@mttkay and @mustafasezgin Is there anything else needed before merging and releasing this? @prabirshrestha Since you had a similar pull request can you weigh in on whether this is meeting your needs and functions correctly? Anyone else with Android experience able to comment? |
|
Looks good to me. |
|
@benjchristensen Just to respond to your comments, to keep close to existing convention I will keep the tests where they are but will try to move the test driver and empty R file into the test package so they are not bundle with the release artifact. Will try to get that in tonight and then we should be good to go .We actually have a few more components to add but they need a little more cleanup before they are ready... |
|
Sounds good, I'll await your final go ahead before merging. |
Excluded the test support package from being included when building a jar or generating javadoc Javadoc comments added
|
RxJava-pull-requests #198 FAILURE |
|
@benjchristensen I have modified the build script to exclude the test support package at jar build time and doc generation time by adding the exclude option to the gradle tasks. If this looks good to you then happy to have it merged. |
…generation from the projects root folder
|
RxJava-pull-requests #199 FAILURE |
|
RxJava-pull-requests #200 FAILURE |
|
@benjchristensen Just to let you know this is all ready to be merged from my perspective. |
|
Great, thank you @mustafasezgin I will aim to have this done this week. Also working on getting #319 out the door which will benefit Android. |
|
This builds successfully and unit tests pass on my machine so I'm merging this. |
Initial support for scheduling on Android Handler threads
|
I'm held up on releasing this while dealing with an internal build issue (that posts to Maven Central) handling the new com.google.android and org.roboelectric dependencies. |
|
Do you need help with this? What's the problem? |
|
No, it's an internal issue ... it's related to how the Netflix build system supports multiple different repos and expects the dependencies from Maven Central to also be available in the internal repo ... which is a headache for this type of thing as these dependencies have never been seen by it before. I know what I need to do, just ran out of time last night ... will try to deal with it today. |
|
This is released in 0.10.1 making its way to Maven Central now. |
|
Announced on Twitter at https://twitter.com/RxJava/status/371124391590887424 |
|
I've added a README at https://github.com/Netflix/RxJava/blob/master/rxjava-contrib/rxjava-android/README.md It would be helpful to show people usage examples and some documentation. Can one of you contribute any of that? Here are examples of contrib modules in the Hystrix project with README files if you want to model after any of them:
Would probably make sense to have something on the wiki as well that at least links to the README. |
|
Great, thanks Ben! I'll look after the documentation. |
Initial support for scheduling on Android Handler threads
To add to the discussion in #317, this is pretty much what we're using in our production app since a few weeks now. It used to live in our app project, but since we've already started talking about adding to rxjava-contrib, I've pulled out the code in question and integrated it into RxJava under rxjava-android.
This comprises:
Schedulerimplementation which schedules work on Android'sHandlerthreads, including the main UI thread.AndroidSchedulersclass which provides factory methods to instantiate Handler schedulers, especially the main thread schedulerThere is some discussion needed around both test support and build integration. @mustafasezgin will want to weigh in on this. In order to write Android unit tests, you're unfortunately required to take a few obstacles, so we had to add some cruft to the production code (an empty Android
Rclass and a custom test runner.)