Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kotlin Multiplatform Library #8

Open
Legion2 opened this issue Nov 26, 2021 · 8 comments
Open

Kotlin Multiplatform Library #8

Legion2 opened this issue Nov 26, 2021 · 8 comments
Labels
enhancement New feature or request KMP

Comments

@Legion2
Copy link

Legion2 commented Nov 26, 2021

Integrating Posthog in Kotlin multiplatform projects currently requires integrating the android and ios libraries separatly. With a multiplatform library the code for android and ios must not be duplicated and user must not themself create expect/actual declarations for PostHog. The kotlin library can also be used nativly in android only projects.

@Legion2
Copy link
Author

Legion2 commented Sep 3, 2022

We now internally maintain a basic multiplatform wrapper for posthog android and ios targets. If somebody is interested we can share it as open source.

@marandaneto marandaneto added enhancement New feature or request KMP labels Sep 22, 2023
@marandaneto
Copy link
Member

We're currently reworking the Android SDK and it's rewritten in Kotlin, still has Java dependencies e.g. Gson but it'd be much easier to write a KMP wrapper on top of it.

Stay tuned.

@marandaneto
Copy link
Member

A quick workaround, for now, is to just call the API directly until we provide first-class support for Kotlin Multiplatform.

@ar-g
Copy link

ar-g commented Feb 22, 2024

@marandaneto any eta on this?
btw would this support web clients, such as chrome-web-extension? or you'd suggest to implement it with an a api? i guess that would imply reimplementing batching, event storage and such?

@marandaneto
Copy link
Member

@ar-g We are not focused on that right now since there's not a lot of demand, usually we prioritize depending on the number of requests, very user-centric.

Instead of writing a new SDK, it might be easier to start with a wrapper SDK similar to https://github.com/postHog/posthog-flutter which just forwards the call to the Native SDKs (Android, iOS, and the JS SDK).

Would that help? Would you be willing to submit a PR? I'm happy to guide you and review it, let me know if that would be an alternative.

@ar-g
Copy link

ar-g commented Feb 23, 2024

@marandaneto our end goal is to use it in our own library that shipped to different clients, practically speaking we don't need any native bindings, screen tracking and such. Do we even need in that case to write a wrapper for other sdks, wouldn't it make more sense to implement own sender of events instead?

What we want to do is track transaction failure events that include versions and different metadata.
We also want to set up PagerDuty based on the threshold of these failures, is this possible?
Another thing is that there're a lot of failure events that need to be filtered, this is probably should be doable using query language. Do you think PostHog is the right tool for this purpose? We want to achieve something similar we have with grafana and backend tracking atm.

@marandaneto
Copy link
Member

marandaneto commented Feb 23, 2024

@ar-g most likely a pure client would make more sense, yes, more lightweight.

What we want to do is track transaction failure events that include versions and different metadata.

That is doable with the API, yes, if you don't need offline caching, that's easy.

We also want to set up PagerDuty based on the threshold of these failures, is this possible?

Let me check that.

Another thing is that there are a lot of failure events that need to be filtered, this is probably should be doable using query language

That is correct, filtering is fine.

Do you think PostHog is the right tool for this purpose? We want to achieve something similar we have with grafana and backend tracking atm.

I'd need to understand a bit more about what exactly you wanna track but dashboards and filtering should not be a problem.
If you're able to write your client library calling the API, all good, it should be super straightforward, you can probably borrow some code from the Android SDK which is Kotlin only.
About the alerting, will come back to you.

@marandaneto
Copy link
Member

@ar-g about alerting, unfortunately not yet, please upvote this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request KMP
Projects
None yet
Development

No branches or pull requests

3 participants