Building fork help about rxandroidble

[dariuszseweryn]

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

[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.

[dariuszseweryn]

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.

[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

[dariuszseweryn]

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 *

[dariuszseweryn]

Closing due to lack of information and inactivity of the original poster.

When more data will be available—feel free to add that information and reopen this issue.

Best Regards