feat(SDK-557): bridge Android decryption failure handler to JS - #906
jferrao-itrbl merged 4 commits into
Conversation
Expose IterableConfig.decryptionFailureHandler so RN apps can react when Android keychain PII decryption fails, matching native IterableConfig parity.
|
|
Coverage Impact Unable to calculate total coverage change because base branch coverage was not found. Modified Files with Diff Coverage (1)
🛟 Help
|
Avoid RN debug RedBox when apps set decryptionFailureHandler on iOS. Assert listenerCount in the omitted-callback test.
…cryption-failure-handler
| if (configReadableMap.hasKey("decryptionFailureHandlerPresent") && configReadableMap.getBoolean("decryptionFailureHandlerPresent") == true) { | ||
| configBuilder.setDecryptionFailureHandler(this); |
There was a problem hiding this comment.
This only registers the handler on the first native keychain construction. Android SDK 3.10.1 caches IterableKeychain, whose handler is fixed at construction, so initializing once without this callback and later re-initializing with it leaves the native handler null even though JS installs a listener.
Suggest registering the bridge handler unconditionally while keeping the JS listener conditional, or otherwise refreshing the native keychain handler, and adding a regression test that enables the callback across initializations.
IterableKeychain caches decryptionFailureHandler at first construction. Register the RN bridge unconditionally; keep the JS listener conditional.
34a55a9
into
feature/SDK-548-feature-parity
2 participants
Summary
IterableConfig.decryptionFailureHandler(Android-only) and bridge nativeIterableDecryptionFailureHandlerviahandleDecryptionFailureCalled.Iterable.ts,decryptionFailureHandlerPresentintoDict(), tests, CHANGELOG, and publicIterableDecryptionFailuretype.Test plan
yarn typecheckyarn testcompileDebugJavaWithJavac— may fail until SDK-749 implementsIterableEmbeddedUpdateHandlersync callbacks (see Jira comments on SDK-557 / SDK-749)Jira
https://iterable.atlassian.net/browse/SDK-557