Building fork help

[Brandon Fraune]

I've forked the RxAndroidBle library and would like to experiment with making some changes.

Unfortunately, I could not build the forked package with jitpack. It failed with this error:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':dagger-library-shadow:signMavenPublication'.
> Cannot perform signing task ':dagger-library-shadow:signMavenPublication' because it has no configured signatory

Does someone here have any quick thoughts on how I can build this package either locally or with jitpack?

Your help would be appreciated!

[Dariusz Seweryn]

Unfortunately I am no expert when it comes to project configuration but you could remove signing completely if you do not intend to distribute your package at all

[Brandon Fraune]

Maybe I should back up a little. While I'm comfortable working in Android, I'm still a beginner with working on packages. Disabling signing might be a helpful step, but I need some more guidance.

I didn't see anything in the readme under "Contributing" for how to build the library locally or how people usually experiment with their changes to this library before they make a PR. Do you have any advice on how to do so?

For some context: I have an app where my UI lags when I'm scanning, and I'd like to learn if I can do anything to improve that. I noticed the scanBleDevices() method observes on the main thread, and I'd like to see if my app behaves differently if I choose to add the ability to observe the scan with an IO thread pool.

[Dariusz Seweryn]

You can switch on which thread you observe an Observable by mixing in .observeOn() in the operator chain — no need to changing the library.

For prototyping you can build/deploy to your phone one of the sample applications which use the library source code. You can also checkin the library module into your app and depend on the module instead of the maven package.

[Brandon Fraune]

I understand I can switch the thread I observe on, but I guess I would like to try changing the upstream subscription to see if that may help alleviate UI lag in my circumstance.

For example, I have some test code that looks like this:

rxBleClient.scanBleDevices(scanSettings)
    .doOnNext { println("###1 Scanning on ${Thread.currentThread().name}") }
    .subscribeOn(Schedulers.io()) // I would expect this to affect upstream threading
    .doOnNext { println("###2 Scanning on ${Thread.currentThread().name}") }
    .observeOn(Schedulers.io()) // Only affects downstream operators
    .doOnNext { println("###3 Scanning on ${Thread.currentThread().name}") }
    ...

When I perform a scan with that code, I will get output that looks like this.

I/System.out: ###1 Scanning on main
I/System.out: ###2 Scanning on main
I/System.out: ###3 Scanning on RxCachedThreadScheduler-3

And yes, I think testing with the sample applications is a good smoke test, but it may be difficult for me to build the sample app up enough to simulate the same issue I'm experiencing on my other app. I'll keep that in mind though.

Do you know how I can checkin the library module into my app? I tried importing the local module, but I get a gradle error when trying to sync project files that I'm not sure how to resolve. I added all the repositories to the project-level build.gradle that I could think of, so I'm not sure what repository is missing/undefined.

A problem occurred configuring project ':dagger-compiler-shadow'.
> Could not resolve all files for configuration ':dagger-compiler-shadow:classpath'.
   > Cannot resolve external dependency gradle.plugin.com.github.johnrengelman:shadow:7.1.2 because no repositories are defined.
     Required by:
         project :dagger-compiler-shadow

[Dariusz Seweryn]

dagger-compiler-shadow is a regular dagger-compiler but shadowed for this project — that needs some additional configuration to work.
You can rename all the code references from import bleshadow.* to import *