Android Messaging SDK — Version 3.1
These are the main feature releases available in the Mobile App Messaging SDK version 3.1 for Android.
Version 3.1 planned roll-out: March 18h 2018
Please note the documentation on version-specific system requirements (PDF).
New functionalities
Campaigns for Messaging — Monitoring APIs
Type: Developer Experience Feature
Available to all customers? Yes.
The addition of campaigns for mobile app and web messaging will allow brands to manage their engagements easily and efficiently across these channels, targeting customers based on unauthenticated attributes or locations and routing them to a desired skill.
Being able to track customer activity in all areas of the brand app and provide information on these interactions to Conversational Cloud boosts agent efficiency and enables more accurate reporting.
Using the Monitoring APIs, brands can:
-
Report on the customer’s journey inside the app
-
Get engagements based on the reported SDEs
-
Route conversations to a specific skill (based on engagements)
Monitoring APIs
The below APIs enable brands to use Campaigns for Messaging inside the brand’s app
| New APIs | Description |
|---|---|
| Added to Liveperson.initialize() → InitLivePersonProperties contains new MonitoringInitParams object | Added new optional MonitoringInitParams object. Brands who wish to use Monitoring capabilities and campaigns should add the required parameters. The SDK can be initialized once without MonitoringInitParams and then have another initialize call using these params. |
| CampaignInfo was added to ConversationViewParams (used in showConversation() and getConversationFragment()) | Added new optional CampaignInfo object to be able to pass a new campaign information to conversation. Campaign includes Engagement info which allows to control the consumer's routing. |
| New BadArgumentException was added. | CampaignInfo has three mandatory members: campaignId, engagementId and engagementContextId. If constructing CampaignInfo with one of them null or empty BadArgumentException is thrown. |
| getEngagement(Context context, @Nullable String consumerId, MonitoringParams monitoringParams, EngagementCallback callback) | Use this API to get an engagement for a consumer in an appInstallationId context. When calculating eligibility the decision is based on the SDEs and other parameters. Based on messaging campaign concept As an optional parameter, you can pass MontoringParams which includes PageId, Entry Points and Engagement Attributes for routing the conversation. - Parameters: - context: application context - consumerID: an optional brand app consumer ID to get the engagement for - monitoringParams: an instance of includes optional PageId, JSONArray of Entry Points and a JSONArray of Engagement Attributes - EngagementCallback: operation callback: onSuccess() response with LPEngagementResponse that contains pageId, sessionId, visitorId and engagementDetailsList onError() response with the MonitoringErrorType |
| sendSde(Context context, @NonNull String consumerId, @NonNull MonitoringParams monitoringParams, SdeCallback callback) | Use this API to report an engagement attributes (SDEs) for a consumer in an appInstallationId context. - Parameters: - context: application context - consumerID: brand app consumer ID to get the engagement for - monitoringParams: an instance of LPMonitoringParams includes optional Array of Entry Points and an optional dictionary of Engagement Attributes. Additional optional parameter is PageID which is used for Page identification for sending events on the current engagement. PageID will be received in LPSdeResponse and in LPtEngagementResponse - SdeCallback: operation callback: onSuccess() response with LPSdeResponse that contains pageId, sessionId and visitorId onError() response with the MonitoringErrorType |
Please note: while the APIs are already available in the SDK, the backend will be available in mid-April. Please consult your account team before using the APIs.
The following additional conditions and configurations are required:
| Backend update | Backend enablement | Backend configuration | SDK enablement | SDK configuration |
|---|---|---|---|---|
| Yes | Yes | Yes | Yes | Yes |
Conversation History Control
Type: Developer Experience Feature
Available to all customers? Yes.
To enhance control of customer data retention, scalability and performance, and support the EU’s General Data Protection Regulation (GDPR), open conversations will be loaded from a real time service while closed conversations will be loaded from a history service.
The change will be seamless for brands who upgrade to SDK version 3.1. Brands choosing not to upgrade to SDK v3.1 will be able to view the conversation history from the last 14 days. The history stored on the consumer’s device will also be available.
The following additional conditions and configurations are required:*
| Backend update | Backend enablement | Backend configuration | SDK enablement | SDK configuration |
|---|---|---|---|---|
| Yes | Yes | Yes | Yes | Yes |
History and Active Conversation View
Type: Developer Experience Feature
Available to all customers? Yes.
New APIs will give brands control over the conversations presented in the conversation window. For example, brands can choose to present only the last 180 days of conversation history.
These APIs can be used together with getengagement (Monitoring APIs) to decide how to present conversations history according to whether there is an open conversation or not. For example, if there is no open conversation, brands can present a ‘View conversation history’ button which will present only the closed conversations from the last 180 days.
The new APIs allows:
-
Getting an indication if there is an open conversation or not (Monitoring APIs)
-
Controlling which conversations will be presented by status (open\closed)
-
Controlling the time frame of presented conversations (by days)
-
When using historyConversationsMaxDays, LPConversationHistoryMaxDaysDateType will decide if to filter by the conversations' start date or end date. When not providing a value, startConversationDate will be the default.
History and Active Conversation APIs
| New APIs | Description |
|---|---|
| ConversationViewParams -> mHistoryConversationsStateToDisplay | Allows to control which conversation will be presented when opening the conversation screen, by status (open or closed). (mHistoryConversationsStateToDisplay is of type LPConversationsHistoryStateToDisplay ENUM which has the following values: OPEN, CLOSE, ALL) |
| ConversationViewParams -> mHistoryConversationMaxDaysType | When using mHistoryConversationsMaxDays, LPConversationHistoryMaxDaysDateType will decide if to filter by the conversations' start date or end date. When not providing a value, startConversationDate will be the default. (mHistoryConversationMaxDaysType is of type LPConversationHistoryMaxDaysDateType ENUM which has the following values: startConversationDate, endConversationDate) |
| ConversationViewParams -> mHistoryConversationsMaxDays | Allows to control the amount of conversations history that will be presented when opening the conversation screen by days. (Default is -1 (no limit)) |
The following additional conditions and configurations are required:*
| Backend update | Backend enablement | Backend configuration | SDK enablement | SDK configuration |
|---|---|---|---|---|
| Yes | Yes | Yes | Yes | Yes |
New Strings Localizations
| New Strings Localization | Description |
|---|---|
| lp_history_control_api_empty_state | There are currently no conversations at this time |
New parameters
Branding and configuration parameters
Type: Parameters
Available to all customers? Yes
The Mobile App Messaging SDK v3.1 exposes additional branding configuration parameters.
The new parameters may control text, padding of conversation UI elements and more.
| Name | Description | Default | Screenshot |
|---|---|---|---|
| <color name="lp_brand_header_text_color">@android:color/black</color> | The configuration to change the Brand name / Agent name text color in the header | Black |  |
| <bool name="show_agent_typing_in_message_bubble">false</bool> |
This configuration is available as long as the announce_agent_typing configuration is on (set as true). |
false |  |
| lp_messaging_ui_typing_animation_frames.xml | In case the brand wants to present a different animation / different image resources. They may create a file named "lp_messaging_ui_typing_animation_frames.xml", this will override the SDK's original animation. | LivePerson animation |  |
| lpinfra_ui_ic_send_disabled.xml | In case the brand wants to display a different drawable to represent sending a message. The brand create a drawable file named "lpinfra_ui_ic_send_disabled.xml" which will override the SDK's default drawable. | The default image is the one from the screenshot to the to the right. Please notice that in order to display an image instead of a text the boolean use_send_image_button should be set to true |  |
| lpmessaging_ui_ic_gallery.xml | In order to replace the existing add image from library button (photo sharing). The brand may create a drawable file named "lpmessaging_ui_ic_gallery.xml" which will override the SDK's default drawable. | LivePerson image |  |
| lpmessaging_ui_ic_camera.xml | In Order to replace the add image from camera button (photo sharing), the brand may create a drawable file named "lpmessaging_ui_ic_camera.xml" which will override the SDK's default drawable. | LivePerson image |  |
| lpinfra_ui_ic_attach.xml | In case the brand wants to display a different drawable for opening the photo-sharing menu tab. They may create a drawable file named "lpinfra_ui_ic_attach.xml" which will override the SDK's default drawable. | LivePerson image |  |
| lpinfra_ui_ic_close.xml | In case the brand wants to display a different drawable for closing the photo-sharing menu tab. They may create a drawable file named "lpinfra_ui_ic_close.xml" which will override the SDK's default drawable. | LivePerson image |  |
| <dimen name="button_corner_radius">30dp</dimen> | Makes CSAT Yes/No and Submit buttons corner radiuses customizable (through dimens.xml). | 30dp |  |
Additional Features
Adding Support for Android O
Mobile App Messaging SDK v3.1 can be integrated into apps running on Android O (API 26 and API 27)
Wrapping Text in Edit Text Box
Parity with iOS in the Edit Text box. The max lines is declared at 3. meaning when the text suppresses the length fit for 3 lines the first line will be hidden.
List of certified and supported devices extended
The following devices are now also supported and/or certified to host our Mobile App Messaging SDK:
| Operating system | ||||
|---|---|---|---|---|
| Device | v5.X (Lollipop) | v6.X (Marshmallow) | v7.X (Nougat) | v8.X (Oreo) |
| Pixel XL | N/A | N/A | Supported | Certified |
A full list of supported and certified devices can be found in the Conversational Cloud System Requirements document.
Key for items as follows:
Backend update: This feature requires an update to the backend.
Backend enablement: This feature requires items to be toggled on in the backend.
Backend configuration: This feature requires configuration in the backend.
SDK enablement: This feature requires items to be toggled on in the SDK.
SDK configuration: This features requires items to be configured in the SDK.