Alright, nothing that couldn't be fixed bringing some generics to the Builder class (f6fb9f9). Now the API for Rx looks similar the non-Rx one:

MapboxDirectionsRx clientRx = new MapboxDirectionsRx.Builder()
  .setAccessToken(Utils.getMapboxAccessToken(this))
  .setCoordinates(positions)
  .setProfile(DirectionsCriteria.PROFILE_DRIVING)
  .setSteps(true)
  .setOverview(DirectionsCriteria.OVERVIEW_FULL)
  .build();
clientRx.getObservable()
  .subscribeOn(Schedulers.newThread())
  .observeOn(AndroidSchedulers.mainThread())
  .subscribe(new Action1<DirectionsResponse>() {
    @Override
    public void call(DirectionsResponse response) {
      DirectionsRoute currentRoute = response.getRoutes().get(0);
      Log.d(LOG_TAG, "Response code: " + response.getCode());
      Log.d(LOG_TAG, "Distance: " + currentRoute.getDistance());
    }
  });

(Working sample in DirectionsV5Activity.)

If this looks good to @mapbox/android we just need to bring in some test and adapt the same approach to the other clients (distance, geocoding, mapmatching, staticimage).

Would it make sense to also have a libandroid-rx module for our geocoding widget and other future widgets/UI elements?

Would it make sense to also have a libandroid-rx module for our geocoding widget and other future widgets/UI elements?

Yes, but let's wait to have some content before we create the module. For example, #4 should closed for now as it's unclear that the benefits of the Rx approach in the widget outbalance the weight of the dependency.

@cammace PR is ready, care to review please?