3.4.14

Added

• IterableInAppManager.setRead now accepts IterableHelper.FailureHandler failureHandler

Fixed

• Fixes an issue where IterableInAppManager.removeMessage caused build failure in React Native SDK pointing to legacy method calls.
• Fixes an issue where custom action handlers were not invoked when tapping on push notification when the app is in background.

3.4.13

Added

• IterableInAppManager.setRead now accepts IterableHelper.SuccessHandler successHandler.
• IterableApi.inAppConsume now accepts IterableHelper.SuccessHandler successHandler and IterableHelper.FailureHandler failureHandler.

3.4.12

Added

• setEmail and setUserId now accepts IterableHelper.SuccessHandler successHandler and IterableHelper.FailureHandler failureHandler.

Changed

• OTT devices (FireTV) will now register as OTT device instead of Android under user's devices.

3.4.11

Added

• Custom push notification sounds! To play a custom sound for a push notification, add a sound file to your app's res/raw folder and specify that same filename when setting up a template in Iterable.

  Some important notes about custom sounds and notification channels:

  • Android API level 26 introduced notification channels. Every notification must be assigned to a channel.
  • Each custom sound you add to an Iterable template creates a new Android notification channel. The notification channel's name matches the filename of the sound (without its extension).
  • To ensure sensible notification channel names for end users, give friendly names to your sound files. For example, a custom sound file with name Paid.mp3 creates a notification channel called Paid. The end user can see this notification channel name in their device's notification channel settings.
  • Be sure to place the corresponding sound file in your app's res/raw directory.

• To help you access a user's email address, userId, and authToken, the SDK now provides convenience methods: getEmail(), getUserId(), and getAuthToken().

Changed

• Updated the Security library and improved EncryptedSharedPreferences handling.

  To work around a known Android issue that can cause crashes when creating EncryptedSharedPreferences, we've upgraded androidx.security.crypto from version 1.0.0 to 1.1.0-alpha04. When EncryptedSharedPreferences cannot be created, the SDK now uses SharedPreferences (unencrypted).

  If your app requires encryption, you can prevent this fallback to SharedPreferences by setting the encryptionEnforced configuration flag to true. However, if you enable this flag and EncryptedSharedPreferences cannot be created, an exception will be thrown.

• Improved JWT token management. This change addresses an issue where null values could prevent the refresh of a JWT token.

Fixed

• Fixed an issue which could prevent in-app messages from respecting the Position value selected when setting up the template (top / center / bottom / full).

• Fixed crashes that sometimes happened during in-app message animations.

3.4.10

Warning
Some users have reported crashes in apps built with version 3.4.10 of
Iterable's Android SDK. We're investigating the issue. In the meantime, please
test thoroughly. If you see crashes, revert to version 3.4.9.

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
However, no data is lost.

Android upgrade instructions

If your app targets API level 23 or higher, this is a standard SDK upgrade, with
no special instructions.

If your app targets an API level less than 23, you'll need to make the following
changes to your project (which allow your app to build, even though it won't
encrypt data):

1. In AndroidManifest.xml, add <uses-sdk tools:overrideLibrary="androidx.security" />
2. In your app's app/build.gradle:
   • Add multiDexEnabled true to the default object, under android.
   • Add implementation androidx.multidex:multidex:2.0.1 to the dependencies.

3.4.9

Added

• Added new methods for setEmail, setUserId and updateEmail which accepts authToken, providing more ways to pass authToken to SDK
• Added two interface methods - onTokenRegistrationSuccessful and onTokenRegistrationFailed. Override these methods to see if authToken was successfully received by the SDK.

Changed

• setAuthToken method is now public allowing additional way to provide authToken to SDK.

3.4.8

Removed

• Removed collection of advertising ID.

Fixed

• Fixed an issue where disableDevice would get called with no device token.

3.4.7

Added

• This release makes offline events processing available to all Iterable customers who'd like to use it — just ask your customer success manager to enable it for your account. Offline events processing saves a local copy of events triggered in your app while the device is offline (up to 1000 events). When a connection is re-established and your app is in the foreground, the events will be sent to Iterable. For more information, read Offline events processing.