search

PostHog / posthog-android

PostHog Android SDK
https://posthog.com/docs/libraries/android
MIT License
39 stars 22 forks source link

Kotlin Multiplatform Library #8

Open Legion2 opened 2 years ago

Legion2 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 8 months ago

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

ar-g commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

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