Support RxJava

[zugaldia]

/cc: @cammace @bleege

[bleege]

@zugaldia Can you provide a little more detail as to how this will work as well as to reassure people publicly that RxJava support is still going to be available? Thanks!

[zugaldia]

@bleege We're still trying to figure out the best plan of action here as there're a few different approaches that we can try (and we're open for feedback). Let's discuss this together.

In the meanwhile, I'm gonna remove RxJava support from master, and therefore from the SNAPSHOT. We'll provide an upgrade path for RxJava support before the next MAS release is published.

/cc: @ivovandongen

[zugaldia]

Just reopening until we decide on path forward for RxJava support.

[bleege]

@zugaldia Awesome! Just wanted to make sure implementing developers knew that they weren't being abandoned. Thanks!

[zugaldia]

We currently ship two different products as part of this project:

1. libjava aka mapbox-java-services (pure Java, no Android dependencies)
2. libandroid aka mapbox-android-services (Android dependencies).

With the change required by this ticket to extract RxJava from libjava we need to create a third package (pure Java too) providing the RxJava extensions. That'd be 3 packages, and I think it's one too many. I'd like to propose a different approach.

We make this repo and its products Java-only (as the name actually indicates) with no Android dependencies. It'd have two products:

1. libjava aka mapbox-java-services as it's today (pure Java, no Android dependencies)
2. (new) libjava-rx aka mapbox-java-rxjava-services (pure Java too, RxJava extensions)

The remaining code in this repo, the Android-specific code, is pretty minimal actually: one object replacing Android's Geocoder object, one geocoder autocomplete widget, and an utils file for permissions. Considering that libjava is now part of the map SDK (aka mapbox-gl-native) due to mapbox/mapbox-gl-native#5869 these classes could be easily moved to the map SDK with minimal impact (I suggest a services packages containing this functionality).

The end result would be that all Android-specific code would live in mapbox-gl-native while all pure Java code lives here.

@mapbox/android I'd love to hear your thoughts. Please 👍 this comment if this looks like a plan or leave a comment otherwise.

[ivovandongen]

I'd also suggest to make those pure java modules pure java. So no android manifest and maybe even maven instead of gradle? Makes it more flexible in my opinion.

[bleege]

I'd also suggest to make those pure java modules pure java. So no android manifest and maybe even maven instead of gradle?

@ivovandongen's on the right path with this IMHO. If it's a Java repo, it's 💯 pure Java. I'd suggest that we stick with Gradle though as it's what is used already on the other projects and there's no need to introduce yet another build system into the matrix.

Considering that libjava is now part of the map SDK (aka mapbox-gl-native) due to mapbox/mapbox-gl-native#5869 these classes could be easily moved to the map SDK with minimal impact (I suggest a services packages containing this functionality).

The only question I have about this is doesn't this prevent developers from using Mapbox Services independently from having to also use the much larger SDK or is this not a business concern anymore?

[ivovandongen]

I'd suggest that we stick with Gradle though as it's what is used already on the other projects and there's no need to introduce yet another build system into the matrix.

Agreed, if gradle can handle optional dependencies nicely.

[bleege]

The only question I have about this is doesn't this prevent developers from using Mapbox Services independently from having to also use the much larger SDK or is this not a business concern anymore?

Following up on this, @zugaldia clarified this for me in Slack a few minutes ago and confirmed that it's his intentions for libjava is now part of the map SDK to be done only as an external dependency in the SDK's Gradle file and not at the source code level. This means that MAS will remain as an independent library and usable sans the SDK as it always has been. 👍

Agreed, if gradle can handle optional dependencies nicely.

Yep, looks like Gradle just added this as of v2.12 so this should work out fine as Google is strongly recommending to use v2.14.1 at a minimum due to a security bug.

https://gradle.org/blog/compile-only-dependencies/