Expose `ld_device` ID via a Dart API method

[Azzeccagarbugli]

Currently, the LaunchDarkly Flutter SDK stores a device-level unique identifier (the ld_device context) using SharedPreferences, but this value is not accessible through the public API. I have resorted to manually reading shared preferences to retrieve it, which is brittle and relies on internal key formats that may change.

💡 Motivation

• The device ID is essential for correlating evaluations or analytics across devices and backend systems.
• There’s currently no safe, stable alternative to manually parsing shared preferences, which risks breaking in future versions.
• Offering official access would improve developer experience and support valid use cases like debugging, analytics, or correlating logs.

❌ Actual implementation

/// Encoder method
String _encodePersistenceKey(String input) {
  final bytes = utf8.encode(input);
  final digest = sha256.convert(bytes);
  // This will be the hex encoded digest.
  return digest.toString();
}

final _preferences = await SharedPreferences.getInstance();

final _deviceIdLaunchy = _preferences.getString(
  'LaunchDarkly_AutoEnvContextKey.${_encodePersistenceKey('ld_device')}',
);

debugPrint('deviceId: $_deviceIdLaunchy');

✅ Desired API

Expose a new asynchronous method on LDClient, such as:

Future<String?> getDeviceId();

That returns the same ld_device UUID stored internally. It could be available once the client has been started.

🛠️ Proposed Implementation

1. Dart-side: add getDeviceId() to LDClient in launchdarkly_flutter_client_sdk.dart, exposing the value.
2. Testing: Add unit tests that confirm the device ID matches across calls and persists across restarts.
3. Documentation: Include usage in README and CHANGELOG.

---

I’d be happy to draft a PR implementing this feature, including all necessary code, tests, and documentation.

Please let me know if this aligns with the project’s goals, I can begin right away 🙏

[tanderson-ld]

Hi @Azzeccagarbugli , I will bring this topic to our next technical discussion and get back to you.

[Azzeccagarbugli]

Perfect, thanks a lot @tanderson-ld, looking forward to that ✨

[tanderson-ld]

Discussed on team, we think Hooks may be a feature that would meet your needs here and it doesn't impose any constraints around the lifecycle of the ld_device identifier. We don't currently have support for Hooks in Flutter, but we do have plans to add it.

Here's our documentation for Hooks, so you can look over that and let us know if it seems like it would work for your use case.

Here are some links to the Hooks implementation in our Android SDK so you can see a concrete API.

Base Hook class

Evaluation hook implementations can get a reference to the LDContext used during evaluation, and that will have the ld_device context in which you could pull the identifier out.

[Azzeccagarbugli]

Hey @tanderson-ld, first of all thanks a lot for the quick reply!

It would be super nice to see Hooks being added to the Flutter SDK, especially because it seems like the perfect way to access the ld_device ID without leaking internal implementation details.

I took a look at the Hooks docs and the Android example API that you mentioned and it all makes total sense, the afterEvaluation or other Hook callbacks giving access to LDContext (which includes ld_device) seems like exactly what the Flutter SDK needs.

Would you happen to have a rough ETA or roadmap for when Hooks support might land in Flutter?

I'd love to follow along or help test it out 🧑‍💻

[tanderson-ld]

Hi @Azzeccagarbugli, I was out and just got back. We don't have an ETA at the moment unfortunately.