chore: bump iterableapi from 3.4.9 to 3.4.10

[dependabot]

Bumps iterableapi from 3.4.9 to 3.4.10.

Release notes

Sourced from iterableapi's releases.

3.4.10

This release includes support for encrypting some data at rest, and an option to store in-app messages in memory.

Encrypted data

In Android apps with minSdkVersion 23 or higher (Android 6.0) Iterable's Android SDK now encrypts the following fields when storing them at rest:

• email — The user's email address.
• userId — The user's ID.
• authToken — The JWT used to authenticate the user with Iterable's API.

(Note that Iterable's Android SDK does not store the last push payload at rest—before or after this update.)

For more information about this encryption in Android, examine the source code for Iterable's Android SDK: IterableKeychain.

Storing in-app messages in memory

This release also allows you to have your Android apps (regardless of minSdkVersion) store in-app messages in memory, rather than in an unencrypted local file. However, an unencrypted local file is still the default option.

To store in-app messages in memory, set the setUseInMemoryStorageForInApps(true) SDK configuration option (defaults to false):

Java

IterableConfig.Builder configBuilder = new IterableConfig.Builder()
   // ... other configuration options ...
  .setUseInMemoryStorageForInApps(true);
IterableApi.initialize(context, "<YOUR_API_KEY>", config);

Kotlin

val configBuilder = IterableConfig.Builder()
   // ... other configuration options ...
  .setUseInMemoryStorageForInApps(true);
IterableApi.initialize(context, "<YOUR_API_KEY>", configBuilder.build());

When users upgrade to a version of your Android app that uses this version of the SDK (or higher), and you've set this configuration option to true, the local file used for in-app message storage (if it already exists) is deleted

... (truncated)

Changelog

Sourced from iterableapi's changelog.

3.4.10

This release includes support for encrypting some data at rest, and an option to store in-app messages in memory.

Encrypted data

In Android apps with minSdkVersion 23 or higher (Android 6.0) Iterable's Android SDK now encrypts the following fields when storing them at rest:

• email — The user's email address.
• userId — The user's ID.
• authToken — The JWT used to authenticate the user with Iterable's API.

(Note that Iterable's Android SDK does not store the last push payload at rest—before or after this update.)

For more information about this encryption in Android, examine the source code for Iterable's Android SDK: IterableKeychain.

Storing in-app messages in memory

This release also allows you to have your Android apps (regardless of minSdkVersion) store in-app messages in memory, rather than in an unencrypted local file. However, an unencrypted local file is still the default option.

To store in-app messages in memory, set the setUseInMemoryStorageForInApps(true) SDK configuration option (defaults to false):

Java

IterableConfig.Builder configBuilder = new IterableConfig.Builder()
   // ... other configuration options ...
  .setUseInMemoryStorageForInApps(true);
IterableApi.initialize(context, "<YOUR_API_KEY>", config);

Kotlin

val configBuilder = IterableConfig.Builder()
   // ... other configuration options ...
  .setUseInMemoryStorageForInApps(true);
IterableApi.initialize(context, "<YOUR_API_KEY>", configBuilder.build());

When users upgrade to a version of your Android app that uses this version of the SDK (or higher), and you've set this configuration option to true, the local file used for in-app message storage (if it already exists) is deleted

... (truncated)

Commits

• edd13e8 Merge pull request #479 from Iterable/MOB-4206-version-3.4.10
• bd12b38 add changelog
• b2838e0 version 3.4.10
• 27e7df4 Merge pull request #469 from Iterable/jay/MOB-4549-keychain
• eab0e9f Revert "try using java 11 in build.yml"
• c6a69c3 try using java 11 in build.yml
• 667e963 remove tags
• f59530d app/src/androidTest sdk tag
• 184aca7 app/src/androidTest manifest library tag
• f4e4ce0 reset manifests
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #71.