Skip to content

Introduce vendor namespace support#5

Merged
brionmario merged 5 commits into
thunder-id:mainfrom
brionmario:flexible-vendor-config
Jul 16, 2026
Merged

Introduce vendor namespace support#5
brionmario merged 5 commits into
thunder-id:mainfrom
brionmario:flexible-vendor-config

Conversation

@brionmario

@brionmario brionmario commented Jul 10, 2026

Copy link
Copy Markdown
Member

Purpose

ThunderID is hardcoded in some SDK components, making it hard for adopters to white-label the SDK. Mirrors the approach landed in thunder-id/javascript-sdks#24.

Approach

  • Added a vendor option to ThunderIDConfig (defaults to ThunderIDConfig.defaultVendor, 'thunderid'), included in toMap() so it's sent over the MethodChannel.
  • Wired vendor through both native handlers (ios/Classes/ThunderIDMethodHandler.swift, android/.../ThunderIDMethodHandler.kt) into the native ThunderIDConfig(vendor:) constructor.
  • On Android, the EncryptedSharedPreferences file name is now derived from the resolved config.vendor instead of a hardcoded string.
  • Added vendor-naming guidance to AGENTS.md so future changes keep runtime keys/names vendor-aware.

Note

The native handler wiring targets the vendor field being added to the native SDKs in thunder-id/ios-sdks#7 and thunder-id/android-sdks#6. Until those land in published releases and this plugin's native dependencies (dev.thunderid:android, ThunderID pod) are bumped, the native build may not pick up vendor support — the Dart-side API and MethodChannel plumbing are unaffected either way.

Related Issues

Related PRs

Checklist

  • flutter analyze passes with 0 issues.
  • flutter test passes (20/20).

Summary by CodeRabbit

  • New Features

    • Added configurable vendor/brand names through ThunderIDConfig.
    • Vendor settings now flow consistently across Android, iOS, and Dart configuration.
    • Configuration exports now include the selected vendor value.
    • Storage namespaces can reflect the configured vendor, helping prevent naming conflicts.
  • Documentation

    • Added guidance for using vendor-aware names while preserving fixed SDK identity labels.

@coderabbitai

coderabbitai Bot commented Jul 10, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@brionmario, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 4 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 88888960-bf1f-4b69-9ac5-a0bd4ad46cb0

📥 Commits

Reviewing files that changed from the base of the PR and between 28de7be and 382ecff.

📒 Files selected for processing (3)
  • android/build.gradle
  • android/gradle.properties
  • samples/quickstart/android/settings.gradle.kts
📝 Walkthrough

Walkthrough

Adds a configurable vendor namespace to ThunderIDConfig, forwards it through Android and iOS handlers, uses it for Android encrypted storage naming, and adds documentation and automated review rules for vendor-aware runtime names.

Changes

Vendor namespace configuration

Layer / File(s) Summary
Vendor configuration contract
lib/src/models/thunderid_config.dart
Adds the default vendor, vendor field, constructor parameter, and serialized map entry.
Native vendor propagation
android/src/main/kotlin/dev/thunderid/flutter/ThunderIDMethodHandler.kt, ios/Classes/ThunderIDMethodHandler.swift
Reads vendor values when building native configuration; Android derives encrypted preferences naming from the configured vendor.
Vendor naming review guidance
AGENTS.md, .coderabbit.yaml
Documents vendor-aware runtime naming and configures automated checks, review behavior, and excluded paths.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant FlutterApp
  participant ThunderIDConfig
  participant NativeMethodHandler
  participant EncryptedStorageAdapter
  FlutterApp->>ThunderIDConfig: set vendor
  ThunderIDConfig->>NativeMethodHandler: serialize vendor
  NativeMethodHandler->>EncryptedStorageAdapter: derive vendor-scoped prefsName
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: adding vendor namespace support for the SDK.
Description check ✅ Passed The description includes the required Purpose, Approach, Related Issues, Related PRs, and Checklist sections with relevant implementation notes.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@brionmario
brionmario force-pushed the flexible-vendor-config branch from 565d271 to 28de7be Compare July 11, 2026 18:48

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
.coderabbit.yaml (1)

10-24: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Consider adding path_instructions for native file patterns.

The vendor naming rules in AGENTS.md are written generally, and the Android handler already derives storage names from config.vendor. However, the automated review instructions only cover lib/**/*.dart. Adding similar path_instructions for android/**/*.kt and ios/Classes/**/*.swift would ensure consistent automated detection of hardcoded brand literals in native code. This can be deferred if native SDK changes are still pending.

As per coding guidelines, vendor naming rules apply to android/**/*.kt and ios/Classes/**/*.swift as well.

♻️ Suggested addition
     - path: "lib/**/*.dart"
       instructions: |
         Flag any hardcoded occurrence of the literal `thunderid`/`ThunderID`/`THUNDERID` (any casing) used to
         build a runtime key or name — platform-channel storage keys, log tags, and similar.

         Do not flag entry point file/package names (e.g. `thunderid_flutter.dart`, `thunderid_client.dart`,
         `thunderid_provider.dart`) or types whose purpose IS to represent the SDK itself (e.g.
         `ThunderIDClient`, `ThunderIDProvider`). That's a fixed identity, not a per-tenant value.

         For everything else, ask: **"Should this read from `ThunderIDConfig.vendor` instead of hardcoding the
         vendor name?"** The best fix is avoiding the vendor name entirely when the brand prefix isn't
         load-bearing. When a brand-scoped namespace is genuinely required, it should resolve through
         `config.vendor` (which already defaults to `'thunderid'`) rather than a literal string. If the same
         default-resolution logic starts appearing in more than one place, ask for it to be extracted into a
         shared helper instead of repeated inline.
+
+    - path: "android/**/*.kt"
+      instructions: |
+        Flag any hardcoded occurrence of the literal `thunderid`/`ThunderID`/`THUNDERID` (any casing) used to
+        build a runtime key or name — EncryptedSharedPreferences filenames, log tags, and similar.
+
+        Do not flag fixed SDK identity types or entry-point class names. When a brand-scoped namespace is
+        genuinely required, it should resolve from the vendor value received via the MethodChannel rather
+        than a literal string.
+
+    - path: "ios/Classes/**/*.swift"
+      instructions: |
+        Flag any hardcoded occurrence of the literal `thunderid`/`ThunderID`/`THUNDERID` (any casing) used to
+        build a runtime key or name — Keychain service identifiers, log tags, and similar.
+
+        Do not flag fixed SDK identity types or entry-point class names. When a brand-scoped namespace is
+        genuinely required, it should resolve from the vendor value received via the MethodChannel rather
+        than a literal string.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.coderabbit.yaml around lines 10 - 24, Extend the vendor-naming review
instructions in the configuration to cover native SDK files under
android/**/*.kt and ios/Classes/**/*.swift, applying the same hardcoded
ThunderID detection and config.vendor guidance already defined for
lib/**/*.dart. Preserve the existing Dart path instructions and exclusions.

Source: Coding guidelines

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.coderabbit.yaml:
- Around line 10-24: Extend the vendor-naming review instructions in the
configuration to cover native SDK files under android/**/*.kt and
ios/Classes/**/*.swift, applying the same hardcoded ThunderID detection and
config.vendor guidance already defined for lib/**/*.dart. Preserve the existing
Dart path instructions and exclusions.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: c917f155-5f29-4981-bd5d-b5accc844f1b

📥 Commits

Reviewing files that changed from the base of the PR and between 0c47688 and 28de7be.

📒 Files selected for processing (5)
  • .coderabbit.yaml
  • AGENTS.md
  • android/src/main/kotlin/dev/thunderid/flutter/ThunderIDMethodHandler.kt
  • ios/Classes/ThunderIDMethodHandler.swift
  • lib/src/models/thunderid_config.dart

…version

CI was failing quickstart apk builds because AGP 8.2.2 is below Flutter's
current minimum supported AGP version of 8.6.0.
…dency resolution

Composite builds don't inherit repositories from the including build;
without a project-level repositories block, Gradle can't resolve
kotlin-stdlib, flutter_embedding_debug, or kotlinx-coroutines-android.
io.flutter:flutter_embedding_debug is published only to Flutter's own
storage.googleapis.com/download.flutter.io maven repo, which is normally
auto-added for registered Flutter plugin projects but not for the
android module here since it's wired in via a manual includeBuild
substitution.
…omposite build

The quickstart's includeBuild("../../../android") substituted
dev.thunderid:android with project(":") of its own composite build,
which resolves to this same android/ module and created a circular
dependency (:android depending on itself). dev.thunderid:android was
also never actually published to any repository.

Point the dependency at the real released artifact via JitPack
(com.github.thunder-id:android-sdks:v0.1.0) instead, and drop the
broken includeBuild/substitution. Also add the missing
android.useAndroidX=true gradle.properties for the android module,
since composite/included builds don't inherit properties from the
including project.
@brionmario
brionmario merged commit bdf7ee0 into thunder-id:main Jul 16, 2026
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants