Improving the ergonomics of pbandk-runtime-android when used from unit tests

[garyp]

Continuing a discussion that was started on #131. Here are the relevant comments from that issue:

@JeroenMols said:

One nit: Switching over to android.util.Base64 did break all our tests. So in a way, the ease of use is impacted. 🤔

@garyp said:

@JeroenMols In what way did the switch break your tests?

The ease of use of this Android variant has definitely been worse than I anticipated. I'm wondering if it's worth trying to publish a normal Java library (i.e. a jar rather than an aar) that uses Android APIs instead... It's not an officially supported mechanism, but there are ways of doing that (e.g. https://stackoverflow.com/a/28311167/437415).

@JeroenMols said:

Using android.util.Base64 caused a not mocked exception and turning returnDefaultValues on didn't work for us as the base64 properties on our modules are non null.

@garyp said:

Using android.util.Base64 caused a not mocked exception and turning returnDefaultValues on didn't work for us as the base64 properties on our modules are non null.

Ah, that makes sense. I can't think of any good alternatives though 😞 Either (a) pbandk avoids all Android-specific APIs (e.g. it's not too hard to implement base64 support in pure Kotlin) and works in regular Android unit tests. Or (b) pbandk uses Android APIs to optimize performance on Android but then consuming projects can only use pbandk in their androidTest tests or have to use Robolectric from their regular unit tests. I think even my suggestion above of compiling pbandk-runtime-android as a jar rather than aar wouldn't avoid this problem, since the resulting jar would still require you to provide Android libraries when used from unit tests. Do you have any other ideas?

If you had to choose one of the above two choices for your project, which would you prefer?

@JeroenMols said:

Honestly I would pick the first option as that implementation would be unit testable.

I'm not very sure about the performance benefits that the Android specific version would provide. Haven't looked at the code (so huge disclaimer), but I did look at the Git history and that implementation has only been updated once or twice the last decade.

Rolling your own also doesn't feel like the right approach honestly, so I would look for open source alternatives. Though a quick search also didn't yield many promising options. (e.g. apache code, openJDK,...). This might be an option to productize with tests: https://gist.github.com/hrules6872/e2d4d02a1e8d3c6328ae5aeabc430b96 ?