My workplace no longer uses Firebase Remote Config to manage our feature flags, so this does not have as high of a priority as it once did. I am happy to accept PRs implementing this feature, but I see two major impediments:
The Firebase Android SDK is an Android library and offers no JVM API that can be used outside of Android. This means that our module will have to declare an androidTarget sourceset, which is in flux.
The Firebase Android SDK's main entrypoint -- FirebaseRemoteConfig.java -- offers no interface for us to program against. In effect this means that it would be impossible for us to test our integration with Firebase without having to perform IO and use a real firebase account. This is really gross.
Our implementation should strive to work solely on the JVM if possible, though not required. We will not accept tests which stipulate real network connections and a real firebase account. Overcoming this will likely require a feature request on the Firebase repo, an internal interface which we can control under test that's implemented with FirebaseRemoteConfig in production, or a clean-room implementation of the remote config SDK with the HTTP API.
My workplace no longer uses Firebase Remote Config to manage our feature flags, so this does not have as high of a priority as it once did. I am happy to accept PRs implementing this feature, but I see two major impediments:
androidTargetsourceset, which is in flux.Our implementation should strive to work solely on the JVM if possible, though not required. We will not accept tests which stipulate real network connections and a real firebase account. Overcoming this will likely require a feature request on the Firebase repo, an internal interface which we can control under test that's implemented with
FirebaseRemoteConfigin production, or a clean-room implementation of the remote config SDK with the HTTP API.