Kotlin SDK

Install from GitHub

The SDK source is public on the main branch. These instructions use Git or a locally built package; package registry releases are a separate step.

git clone --branch main https://github.com/pubbio/sdk-kotlin.git
cd sdk-kotlin
./gradlew publishSdkPublicationToLocalBuildRepository

# Add to your application's build.gradle.kts:
# repositories {
#   maven { url = uri("/absolute/path/to/sdk-kotlin/build/repository") }
#   mavenCentral()
# }
# dependencies { implementation("io.pubb:pubb-kotlin:0.2.0") }

The local Maven repository contains the built library. Its dependencies resolve from Maven Central. The repository README includes the full Gradle configuration and a runnable JVM example.

Subscribe to events

Use your public app key from the Pubb dashboard. Subscribe before publishing a matching event from your trusted backend.

import io.pubb.Pubb
import kotlinx.coroutines.CoroutineStart
import kotlinx.coroutines.coroutineScope
import kotlinx.coroutines.launch

suspend fun listenForMessages(pubb: Pubb) = coroutineScope {
    val channel = pubb.subscribe("notifications")
    launch(start = CoroutineStart.UNDISPATCHED) {
        channel.events.collect { event ->
            if (event.name == "message.sent") println(event.data)
        }
    }
    pubb.connect()
}
// Launch in your lifecycle scope with Pubb("YOUR_PUBLIC_APP_KEY").
// On teardown, cancel the scope and call pubb.close().

connect, disconnect, subscribe and unsubscribe are suspending functions. Collect flows before connecting. disconnect allows later reuse; close permanently releases the client. Events are not replayed and slow collectors can drop buffered events, so recover durable state from your backend.

Private and presence channels

Use io.pubb.HttpAuthorizer with your backend URL, an OkHttpClient, and a callback for current session headers. Pass it as authorizer to Pubb. Presence channels expose a members StateFlow. The owner remains responsible for an injected OkHttpClient's resources.

Your backend receives socket_id and channel_name, checks the authenticated user’s access, and returns auth plus channel_data for presence. Derive the presence user ID from the session and forward the signed channel_data unchanged.

Keep the app secret on your trusted server. Public channels must not carry personal or restricted data. Read the channel access reference for the protocol.

Verify your integration

1. Subscribe to notifications in your app or the dashboard’s Live console.
2. Publish message.sent to the same application and channel from your backend.
3. Check the event payload, connection cleanup and recovery after a disconnect. Test denied access as well as successful private subscriptions.

The repositories include automated tests and examples. Verify end-to-end delivery with your own application before sending production traffic. Refetch durable state after reconnecting; missed events are not replayed.

Legacy pusher:* and pusher_internal:* control names are retained where required by the protocol. Their presence alone does not imply drop-in compatibility with every Pusher client or server.