You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on open sourcing a Kotlin Multiplatform feature flagging abstraction library which my team at work has used happily for 2+ years. Until now, it's had a tight coupling to Android and iOS clients, but in the library release I'm hoping to generalize my JVM implementation across both server and client.
The java-sdk-common library is the exact thing I need, but it does not offer a LDClientInterface for which I can write common code against. Instead, both the Android and the java server clients choose to declare these API surfaces in their respective package namespaces. They differ slightly, but offer some common API which could be shared across SDK clients.
My proposal is to offer an interface named CommonLDClientInterface with the following functionality.
My motivation for this feature is that the Kotlin Multiplatform Android integration is in a slight amount of flux. Ownership of the android multiplatform target is being transferred from the Kotlin team at Jetbrain to the Android team at Google. The benefit of this request is not just code de-duplication between JVM and Android, but also API stability in my library since I am not required to use the Android target.
Currently, it doesn't look like the JVM server client API supports registering feature change change listeners like the Android client does, but perhaps this is possible. It seems like a hook into InMemoryDataStore#upsert could be written to notify listeners similar to how the Android client works. Aside from my use case, this could be useful for persistent server endpoints, like websockets and HTTP server sent events.
I want to reiterate though that this request is limited to simply offering an interface with the above functionality.
The text was updated successfully, but these errors were encountered:
Hi @kevincianfarini, thank you for reaching out. We plan to migrate our Java based SDKs into a monorepo in the future and that is likely when we would consider doing this work. In the mean time we will discuss this on team and let you know the outcome.
I am working on open sourcing a Kotlin Multiplatform feature flagging abstraction library which my team at work has used happily for 2+ years. Until now, it's had a tight coupling to Android and iOS clients, but in the library release I'm hoping to generalize my JVM implementation across both server and client.
The
java-sdk-common
library is the exact thing I need, but it does not offer aLDClientInterface
for which I can write common code against. Instead, both the Android and the java server clients choose to declare these API surfaces in their respective package namespaces. They differ slightly, but offer some common API which could be shared across SDK clients.My proposal is to offer an interface named
CommonLDClientInterface
with the following functionality.And then have each respective platform's interface extend the common one:
Android:
Server:
My motivation for this feature is that the Kotlin Multiplatform Android integration is in a slight amount of flux. Ownership of the android multiplatform target is being transferred from the Kotlin team at Jetbrain to the Android team at Google. The benefit of this request is not just code de-duplication between JVM and Android, but also API stability in my library since I am not required to use the Android target.
Currently, it doesn't look like the JVM server client API supports registering feature change change listeners like the Android client does, but perhaps this is possible. It seems like a hook into InMemoryDataStore#upsert could be written to notify listeners similar to how the Android client works. Aside from my use case, this could be useful for persistent server endpoints, like websockets and HTTP server sent events.
I want to reiterate though that this request is limited to simply offering an interface with the above functionality.
The text was updated successfully, but these errors were encountered: