Every SDK, one page

Flutter

Published on pub.dev · drengr_flutter_sdk.

Before you start

Install

flutter pub add drengr_flutter_sdk

Start it

In lib/main.dart. Your publishable key is safe to ship in client code: it can only write.

01import 'package:drengr_flutter_sdk/drengr_flutter_sdk.dart';0203void main() {04  final sink = IngestSink(05    url: 'https://ziryfxrwrvnunwjupgfg.supabase.co/functions/v1/ingest',06    publishableKey: 'drengr_pk_YOUR_KEY',07    context: {'app_package': 'com.example.myapp'},08  );09  Drengr.start(onEvent: sink.addNetwork);10  runApp(const MyApp());11}1213// screen_view needs this observer — without it you get taps and network only.14// MaterialApp(navigatorObservers: [Drengr.navigatorObserver])

Add the navigator observer, or you get no screens

MaterialApp(navigatorObservers: [Drengr.navigatorObserver])

What arrives on its own

You do not instrument these. They are captured from the moment start() runs. The third column names the Flutter API behind each one, so you can check the claim against your own app.

IngestSink batches in memory and flushes on background, so a dropped connection costs nothing.

app_package is the identity the console groups by. Use your real bundle id, not a display name.

Labels are redacted and capped on device before they leave the app.

What never leaves the device

Emails, phone numbers, card numbers and government ids are detected and sealed on the device before the first byte is sent. Our servers hold ciphertext they cannot open. Labels and URLs are redacted and length-capped on the device too.

And what is never collected in the first place:

Most autocapture tools promise not to look. This is built so we cannot. Full design in Security and Privacy.

Consent and opt-out

Start paused behind a consent gate with Drengr.start(enabled: false), then resume once the user agrees. A persisted opt-out always wins over that argument, so an opted-out install stays paused across restarts.

Retention, deletion and what a GDPR or CCPA request maps to are on Privacy controls.

Check it worked

Run the app and use it for a few seconds, then open the console. Overview checks for your first event every 15 seconds on its own, so you do not need to keep reloading.

Nothing showing up

Where to go next

Once events are arriving, these are the things worth doing in order.

• Set up consent and opt-out before you ship to real users.
• Name your events. Drengr proposes names from the traffic itself; you accept or reject them in the console's review queue.
• Bring your history across from whatever you use today, so the numbers do not start at zero.

iOS

Published on Swift Package Manager · CocoaPods.

Before you start

Install

.package(url: "https://github.com/SharminSirajudeen/drengr-sdk.git", from: "0.3.0")

Start it

In AppDelegate.swift / your App struct. Your publishable key is safe to ship in client code: it can only write.

// Xcode → Add Package: https://github.com/SharminSirajudeen/drengr-sdk.git (from 0.3.0)
import Drengr

Drengr.start(
    publishableKey: "drengr_pk_YOUR_KEY",
    ingestURL: "https://ziryfxrwrvnunwjupgfg.supabase.co/functions/v1/ingest",
    appPackage: "com.example.app"
)

What arrives on its own

You do not instrument these. They are captured from the moment start() runs. The third column names the iOS API behind each one, so you can check the claim against your own app.

Call start() once, as early as you can — anything before it is not captured.

CocoaPods works too: add pod 'Drengr' and run pod install.

URLSession traffic is captured through a protocol hook; no swizzling of your own code.

What never leaves the device

Emails, phone numbers, card numbers and government ids are detected and sealed on the device before the first byte is sent. Our servers hold ciphertext they cannot open. Labels and URLs are redacted and length-capped on the device too.

And what is never collected in the first place:

Most autocapture tools promise not to look. This is built so we cannot. Full design in Security and Privacy.

Consent and opt-out

Start paused behind a consent gate with Drengr.start(startEnabled: false), then resume once the user agrees. A persisted opt-out always wins over that argument, so an opted-out install stays paused across restarts.

Retention, deletion and what a GDPR or CCPA request maps to are on Privacy controls.

Check it worked

Run the app and use it for a few seconds, then open the console. Overview checks for your first event every 15 seconds on its own, so you do not need to keep reloading.

Nothing showing up

Where to go next

Once events are arriving, these are the things worth doing in order.

• Set up consent and opt-out before you ship to real users.
• Name your events. Drengr proposes names from the traffic itself; you accept or reject them in the console's review queue.
• Bring your history across from whatever you use today, so the numbers do not start at zero.

Android

Published on Maven Central · dev.drengr:analytics-android.

Before you start

Install

implementation("dev.drengr:analytics-android:0.2.0")

Start it

In Application.onCreate(). Your publishable key is safe to ship in client code: it can only write.

01// build.gradle.kts: implementation("dev.drengr:analytics-android:0.2.0")02val client = OkHttpClient.Builder()03    .addInterceptor(04        Drengr.start(05            context = applicationContext,06            publishableKey = "drengr_pk_YOUR_KEY",07            ingestUrl = "https://ziryfxrwrvnunwjupgfg.supabase.co/functions/v1/ingest",08            appPackage = "com.example.app",09        )10    )11    .build()

What arrives on its own

You do not instrument these. They are captured from the moment start() runs. The third column names the Android API behind each one, so you can check the claim against your own app.

Drengr.start() returns an OkHttp Interceptor. Add it to the client your app already uses — requests made through other clients are not captured.

Screen and tap capture attach through the Application lifecycle, so no per-Activity wiring.

What never leaves the device

Emails, phone numbers, card numbers and government ids are detected and sealed on the device before the first byte is sent. Our servers hold ciphertext they cannot open. Labels and URLs are redacted and length-capped on the device too.

And what is never collected in the first place:

Most autocapture tools promise not to look. This is built so we cannot. Full design in Security and Privacy.

Consent and opt-out

Start paused behind a consent gate with Drengr.start(startEnabled = false), then resume once the user agrees. A persisted opt-out always wins over that argument, so an opted-out install stays paused across restarts.

Retention, deletion and what a GDPR or CCPA request maps to are on Privacy controls.

Check it worked

Run the app and use it for a few seconds, then open the console. Overview checks for your first event every 15 seconds on its own, so you do not need to keep reloading.

Nothing showing up

Where to go next

Once events are arriving, these are the things worth doing in order.

• Set up consent and opt-out before you ship to real users.
• Name your events. Drengr proposes names from the traffic itself; you accept or reject them in the console's review queue.
• Bring your history across from whatever you use today, so the numbers do not start at zero.

Web

Published on npm · drengr-js.

Before you start

Install

npm install drengr-js

Start it

In your app entry (or a root layout). Your publishable key is safe to ship in client code: it can only write.

// npm install drengr-js
import { Drengr } from 'drengr-js';

Drengr.start({
  ingestUrl: 'https://ziryfxrwrvnunwjupgfg.supabase.co/functions/v1/ingest',
  publishableKey: 'drengr_pk_YOUR_KEY',
  appPackage: 'com.example.myapp',
});

What arrives on its own

You do not instrument these. They are captured from the moment start() runs. The third column names the Web API behind each one, so you can check the claim against your own app.

fetch and XMLHttpRequest are both wrapped, so requests are captured regardless of which your app uses.

History routing is followed automatically — single-page navigations register as screen views.

Runs client-side only. In Next.js, call start() from a client component.

What never leaves the device

Emails, phone numbers, card numbers and government ids are detected and sealed on the device before the first byte is sent. Our servers hold ciphertext they cannot open. Labels and URLs are redacted and length-capped on the device too.

And what is never collected in the first place:

Most autocapture tools promise not to look. This is built so we cannot. Full design in Security and Privacy.

Consent and opt-out

Start paused behind a consent gate with start({ enabled: false }), then resume once the user agrees. A persisted opt-out always wins over that argument, so an opted-out install stays paused across restarts.

Retention, deletion and what a GDPR or CCPA request maps to are on Privacy controls.

Check it worked

Run the app and use it for a few seconds, then open the console. Overview checks for your first event every 15 seconds on its own, so you do not need to keep reloading.

Nothing showing up

Where to go next

Once events are arriving, these are the things worth doing in order.

• Set up consent and opt-out before you ship to real users.
• Name your events. Drengr proposes names from the traffic itself; you accept or reject them in the console's review queue.
• Bring your history across from whatever you use today, so the numbers do not start at zero.