Skip to end of metadata
Go to start of metadata

Introduction

Accengage technology allows the sending of push notifications on mobile applications, Websites and Facebook Messenger.

Available in SAAS mode, it offers a large panel of functionalities in order to help advertisers to accelerate their mobile users engagement :

  • Notifications with Buttons, Images, Videos, GIFs, Sounds ...
  • In-Apps messages
  • Inbox Messages
  • Real time segmentation
  • Dynamic customization (templates, messages) 
  • Geomarketing via Geofencing and Beacons,
  • Advanced automation with real-time triggers,
  • Connectors with leading CRM & DMP solutions on the market
  • APIs for sending and retrieving data etc.. 

You will discover them gradually, by reading this documentation. If needed, do not hesitate to contact our friendly support team (http://ticket.accengage.com)

Section 1 - Getting Started

1.1 Requirements

Login Information

You'll need an Accengage Partner Id and a Private Key.

These id are available for registered customers at accengage.com

If you want to enable push notifications in your app, you need a SenderId (also called Google API Project Number) This SenderId must match the Google API Key you use in the Accengage Interface

 

You can then follow our tutorial to get to know more about how to use the application.

Cloud Messaging

Accengage Android SDK (A4SSDK)  supports different cloud messaging solutions for push notifications: FCM (Firebase Cloud Messaging), GCM (Google Cloud Messaging) and ADM (Amazon Device Messaging). For each solution there is a corresponding plugin used by the SDK to receive push notifications:

Cloud Messaging solution
Accengage Plugin
Dependecy
FCMplugin-firebase-messagingfirebase-messaging:11.4.2
GCMplugin-play-services-pushplay-services-gcm:11.4.2
ADMA4SSDK-Plugin-Amazonamazon-device-messaging-1.0.2

Check out our pages to get started with:

 

1.2 Activate push notifications

1.2.1 FCM (Firebase Cloud Messaging)

FCM is the new version of GCM. For this reason it's recommended to use plugin-firebase-messaging plugin instead of plugin-play-services-push

Add Firebase to your app

Before integrating the SDK and plugin-firebase-messaging plugin into your Android application to receive push notifications you need to create a Firebase project first. You can do it either by using Firebase Assistant in Android Studio or by using Firebase console. Check this page for more details.

Once a new firebase project and an Android app of this project are created, you need to move the google-services.json file into your Android app module root directory and modify your build.gradle files to use google-services plugin. This plugin handles automatically the google-services.json file and adds necessary information about the Firebase project into your Android Studio project while building it.

 

 

Use Firebase Assistant in Android Studio to connect your project to Firebase and update the google-services.json file.

Note! You don't need to click on the button 'Add FCM to your app' to add FCM library firebase-messaging. It will be added later.

If you have already added FCM to your project please check that the version of firebase-messaging library is 11.0.4 to avoid conflicts with the version that Accengage plugin-firebase-messaging plugin uses.

app-level build.gradle

Also you may simply remove the line above with firebase-messaging because the FCM library is added automatically with the correct version number when Accengage plugin-firebase-messaging plugin is integrated in the project.

Add Accengage SDK and plugin-firebase-messaging to your app

To integrate the SDK, add the dependency for A4SSDK to your app-level build.gradle file:

app-level build.gradle

Then, you should add Accengage plugin-firebase-messaging plugin to be able to receive FCM/GCM push notifications:

app-level build.gradle

The plugin depends on the firebase-messaging:11.0.4 library, so you don't need to add it by your self.

Add Firebase Server key and Sender ID to Accengage dashboard

Accengage servers need Server API key and Sender ID of your FCM/GCM project to send push notifications. Copy and paste them from Firebase console to Accengage dashboard.

Integrate the SDK into your code

Modify your activities

To work properly Accengage SDK needs information about activities states, intents starting activities and bundles of these intents. For this reason, all of your activities should be slightly modified. There are two ways to do it:

  • by adding a few lines of code into Activity methods defining the lifecycle of the activity

    Modifying Activity methods
  • by inheriting A4SActivity 

    Changing the parent class on A4SActivity

In case you want to use another Android standard activity, the Accengage SDK provides modified activities :

  • A4SExpandableListActivity
  • A4SListActivity
  • A4SPreferenceActivity
  • A4SNativeActivity
  • A4SAccountAuthenticatorActivity

Modify you application class

If you are using the Application class, we recommend you to extend A4SApplication instead of the standard Application.

Application class
Since our SDK is running on its own process, your methods may be executed twice (once in your app, once in the SDK process). By extending the A4SApplication, you prevent unwanted interactions between the SDK and your App (the SDK process will not execute the code of your Application class).

In case you can not extend A4SApplication, see Sub Classing any Application Type.

Add credentials to your app

A4SSDK must be authenticated and authorized by Accengage servers. That's why you need to add application credentials (Partner ID and Private key) into strings.xml resource file:

strings.xml

The last two parameters presented in the code snippet are used to activate logs and disable geolocation. If you want to use geolocated In-Apps and Pushs, please check out our Geolocation section.

If you need to use different credentials, for example one pair of Partner ID / Private key per country which you would like to target, you should use localized strings: How to localize strings? 

To be able to dynamically provide Partner ID and Private key with code, please check out Custom Credentials Integration section.

Sample

The sample application receiving push notifications from Accengage dashboard and Firebase console is available on github.

1.2.2 GCM (Google Cloud Messaging)

GCM is the old Google Cloud Messaging solution. It's strongly recommended to replace it by FCM (check out our Getting Started for FCM), in order to benefit from the new FCM features.

Add Accengage SDK and plugin-play-services-push

To integrate the SDK, add the dependency for A4SSDK to your app-level build.gradle file:

app-level build.gradle

Then, you should add Accengage plugin-play-services-push plugin to be able to receive GCM push notifications:

app-level build.gradle

The plugin depends on the play-services-gcm:11.0.4 library, so you don't need to add it by your self.

 

The Accengage SDK will take care of all the GCM events (including Registration, Retrieving Token, ...). You don't need to handle anything by yourself.

You need to include the following lines inside your <application> tag:

Do not forget to replace “your-package” used in this example with your own application package

Integrate the SDK into your code

Modify your activities

To work properly Accengage SDK needs information about activities states, intents starting activities and bundles of these intents. For this reason, all of your activities should be slightly modified. There are two ways to do it:

  • by adding a few lines of code into Activity methods defining the lifecycle of the activity

    Modifying Activity methods
  • by inheriting A4SActivity 

    Changing the parent class on A4SActivity

In case you want to use another Android standard activity, the Accengage SDK provides modified activities :

  • A4SExpandableListActivity
  • A4SListActivity
  • A4SPreferenceActivity
  • A4SNativeActivity
  • A4SAccountAuthenticatorActivity

Modify your application class

If you are using the Application class, we recommend you to extend A4SApplication instead of the standard Application.

Application class
Since our SDK is running on its own process, your methods may be executed twice (once in your app, once in the SDK process). By extending the A4SApplication, you prevent unwanted interactions between the SDK and your App (the SDK process will not execute the code of your Application class).

In case you can not extend A4SApplication, see Sub Classing any Application Type.

Add credentials to your app

A4SSDK must be authenticated and authorized by Accengage servers. That's why you need to add application credentials (Partner ID and Private key) into strings.xml resource file:

strings.xml

The last two parameters presented in the code snippet are used to activate logs and disable geolocation. If you want to use geolocated In-Apps and Pushs, please check out our Geolocation section.

If you need to use different credentials, for example one pair of Partner ID / Private key per country which you would like to target, you should use localized strings: How to localize strings? 

To be able to dynamically provide Partner ID and Private key with code, please check out Custom Credentials Integration section.

Add sender ID to your app

The last thing you need to do is to add your sender ID to strings.xml as shown on the code snippet presented below.

strings.xml
Note that your_sender_id must be replaced with the real sender ID of your project (for instance, gcm:993056754350).

You can find more information about the sender IDs on this page.

Multiple push providers

If you have another push system integrated into your app that is using GCM too, here is how to proceed in order to get them working as well:

Create your own GCM receiver which extends com.ad4screen.sdk.GCMHandler and overrides the onPushReceive method

MyGCMHandler.java

OnPushReceive will ONLY be called for push notifications that do not come from our Web Interface.

Finally, declare your receiver inside AndroidManifest.xml:

AndroidManifest.xml

Do not forget to replace “your-package” used in this example with your own application package

1.2.3 ADM (Amazon Device Messaging)

To implement ADM (Amazon Device Messaging) you need to use A4SSDK-Plugin-Amazon.

Get credentials from Amazon

To be able to receive notifications on Amazon products (like Kindle Fire), you need to retrieve the OAuth Credentials and API Key.

To do this, please follow these instructions Getting Your OAuth Credentials and API Key.

 

When this is done, go to Security Profiles and choose the Security Profile associated with your application. In the General tab, get the Client ID and Client Secret:

Go to the Android/Kindle Settings tab and store your key in a file named api_key.txt. This will be used later.

 

Configure ADM with Accengage User Interface

  1. Go to Accengage User Interface, and to Settings > Manage Application and find your application
  2. Edit your application's settings, and check Amazon checkbox. Then, fill Amazon Client ID with your own Client ID and Amazon Client Secret with your own Client Secret :

Configure ADM with your app

Add Amazon Plugin with Gradle

To be able to receive ADM Notifications, you need to integrate our Amazon Plugin with Gradle.

Add API Key

To be able to receive ADM Notifications, you need to add a valid API Key in your application. To do this, just add the api_key.txt file from Get credentials from Amazon part and place it in the assets folder.

More information here.

1.3 Configure the Accengage dashboard for push notifications

1.3.1 Add Firebase Server key and Sender ID to Accengage dashboard

Accengage servers need Server API key and Sender ID of your FCM/GCM project to send push notifications. Copy and paste them from Firebase console to Accengage dashboard.

1.3.2 Configure GCM with Accengage User Interface

Get API Key and Sender ID from Google

  1. Go to the Google Services Interface (you will need a gmail account).
  2. Press the "Pick a platform" button.
  3. Follow the instructions and fulfill the requiered info.
  4. Select the cloud messaging service and hit "Generate configuration files"
  5. Congratulations, the next screen will provide you with your Google API Key as well as with the sender ID
  6. Go to Accengage User Interface, and to Settings > Manage Application and find your application
  7. Edit your application's settings, and fill the Google API Key box with your own API Key

Configure the Accengage SDK

Requirements

You need a GCM Sender ID (its format looks like this: 670330094152)

Understand the push notification data flow.

Adding Push Notifications

If you want to add push notifications to your app, just add your senderID in the A4SService <service> tag:

Do not forget to add “gcm:” before your senderID

If you need to use a gcm sender id for each country you are targeting, use localized resources.

Adding required permissions

 

The Accengage SDK will take care of all the GCM events (including Registration, Retrieving Token, ...). You don't need to handle anything by yourself.

You need to include the following lines inside your <application> tag:

Do not forget to replace “your-package” used in this example with your own application package

Manual GCM Registration

If you do not want the SDK to register to GCM,remove the senderId's meta-data com.ad4screen.senderid in the A4SService <service> tag.

Then send us your GCM Registration token with the following method:

Make sure to send us your GCM Registration token everytime your application is launched.

Configuring Accengage interface

In the Accengage interface, you will need to update your application by going to Settings > Manage your applications and edit your app.
You will need to enter your Google API Key (see here: Access Key) in the right field. This key -also called Key for Server apps-has a format that looks like this: "AIzaxxxxx...."

Using GCM with Google Play Services

If you use Google Play Services in your app, and/or if you want our SDK to use Google Play Services library to register/unregister to GCM (which is a new method recently added by Google), Please take a look at our Google Play Services plugin

Sample

A sample is available on Github : https://github.com/Accengage/accengage-android-sdk-samples/tree/master/AccSample

1.3.3 Configure ADM with Accengage User Interface

Get credentials from Amazon

To be able to receive notifications on Amazon products (like Kindle Fire), you need to retrieve the OAuth Credentials and API Key.

To do this, please follow these instructions Getting Your OAuth Credentials and API Key.

 

When this is done, go to Security Profiles and choose the Security Profile associated with your application. In the General tab, get the Client ID and Client Secret:

Go to the Android/Kindle Settings tab and store your key in a file named api_key.txt. This will be used later.

 

  1. Go to Accengage User Interface, and to Settings > Manage Application and find your application
  2. Edit your application's settings, and check Amazon checkbox. Then, fill Amazon Client ID with your own Client ID and Amazon Client Secret with your own Client Secret :

Configure ADM with your app

Add Amazon Plugin with Gradle

To be able to receive ADM Notifications, you need to integrate our Amazon Plugin with Gradle.

Add API Key

To be able to receive ADM Notifications, you need to add a valid API Key in your application. To do this, just add the api_key.txt file from Get credentials from Amazon part and place it in the assets folder.

 

More information here.

 

1.4 Configure URL Schemes

Deep links are URLs that take users directly to specific content in your app. These URLs are used by Accengage dashboard to specify Push actions and InApp actions. Check out this Android page to get to know more about creating deep links. You may also find this Codelab useful.

Here is an example of declaring two URL schemes testapp://p1 and testapp://p2 in your app

AndroidManifest.xml

If you want, you can retrieve data (custom parameters, for instance) from URL scheme using the code below:

Section 2 - SDK Integration

2.1 Basic and mandatory steps

2.1.1 Android Sample

If you want to see how our SDK is integrated and used in some demo apps, you can check our samples apps.

All our samples are available on Github.com

2.1.2 Add the SDK to your app

To integrate the SDK, add the dependency for A4SSDK to your app-level build.gradle file:

app-level build.gradle

2.1.3 Integrate the SDK into your code

Modify your activities

To work properly Accengage SDK needs information about activities states, intents starting activities and bundles of these intents. For this reason, all of your activities should be slightly modified. There are two ways to do it:

  • by adding a few lines of code into Activity methods defining the lifecycle of the activity

    Modifying Activity methods
  • by inheriting A4SActivity 

    Changing the parent class on A4SActivity

In case you want to use another Android standard activity, the Accengage SDK provides modified activities :

  • A4SExpandableListActivity
  • A4SListActivity
  • A4SPreferenceActivity
  • A4SNativeActivity
  • A4SAccountAuthenticatorActivity

Modify your application class

If you are using the Application class, we recommend you to extend A4SApplication instead of the standard Application.

Application class
Since our SDK is running on its own process, your methods may be executed twice (once in your app, once in the SDK process). By extending the A4SApplication, you prevent unwanted interactions between the SDK and your App (the SDK process will not execute the code of your Application class).

In case you can not extend A4SApplication, see Sub Classing any Application Type.

2.1.4 Add credentials to your app

A4SSDK must be authenticated and authorized by Accengage servers. That's why you need to add application credentials (Partner ID and Private key) into strings.xml resource file:

strings.xml

The last two parameters presented in the code snippet are used to activate logs and disable geolocation. If you want to use geolocated In-Apps and Pushs, please check out our Geolocation section.

If you need to use different credentials, for example one pair of Partner ID / Private key per country which you would like to target, you should use localized strings: How to localize strings? 

To be able to dynamically provide Partner ID and Private key with code, please check out Custom Credentials Integration section.

2.1.5 Activate Logs 

Something doesn't work? You can enable logging in order to see what is going on.

To do so, simply add the following string:

strings.xml

Plus, you can disable the toast displayed when application is started (because of UI Automation for example):

strings.xml


2.2 Recommended configurations

With Android 8.0, a new feature called Notification Channels has appeared. An application targeting API Level 26 or higher needs to add support to notifications channels or notifications will not be displayed. The Accengage SDK supports this feature in versions 3.5.4 and 3.6.1.

Our SDK includes 6 presets of channels to use our notifications without any efforts. For more informations, please follow our User Documentation. Our presets of channels are created only when receiving a corresponding notification. If you do not want to display our presets of channels, create your own channel and do not use ours.

Add a new Notification Channel

Just follow the Android documentation. You will need to use the correct channel identifier when configuring messages in Accengage User Interface.

Edit an exisintg preset

You can edit existing presets of channels by overriding correct strings in resource file. For each channel you can edit following options:

OptionResource name suffixDescription

Name

*_nameName of the channel, string
Description*_descDescription of the channel, string
Importance*_importance

Importance of the channel, integer

Min: 1 / Low: 2 / Default: 3 / High: 4

Enable Led*_led

Enable or disable Led display, boolean

true or false

Led Color*_led_color

Color of the Led

Format #RRGGBB

Enable Vibration*_vibration

Enable or disable vibration, boolean

true or false

Lockscreen Visibility*_lockscreen_visibility

Visibility of the lockscreen, integer

Secret: -1 / Private: 0 / Public: 1

Sound*_sound

Sound when notification is displayed

none, default or resource name in raw folder

Bypass Do Not Disturb*_bypass_dnd

Bypass the Do Not Disturb option, boolean

true or false

Enable Badge*_badge

Enable or disable badge for this channel, boolean

true or false

Use the following prefix for corresponding channels:

Channel nameResource name prefix
General Informationacc_channel_general
Service Messagesacc_channel_service
News Messagesacc_channel_news
Urgent Messagesacc_channel_high
Low priority Messagesacc_channel_low
Minimum priority Messagesacc_channel_min

For exemple, our configuration of the General Information channel:

strings.xml

2.3 Updating the SDK version

    Migrate an existing application using Accengage SDK 3.5.x (or earlier) to the SDK 3.6.x

    SDK migration

    AndroidManifest.xml

    You need to remove the A4SService and all meta datas inside it from your application AndroidManifest.xml. This section is already defined for you in AndroidManifest.xml of the SDK.  

    AndroidManifest.xml

    Strings.xml

    Now the SDK configuration parameters (partnerId, privateKey, senderId, etc...) are located in the strings.xml file. So you need to move them from AndroidManifest.xml to strings.xml 

    strings.xml

    In the table presented below you can find string names of SDK parameters:

    Previous Meta-Data
    String name
    Default Value
    com.ad4screen.webview.script_url acc_webview_script_url  
    com.ad4screen.unsecurepush acc_unsecure_push true
    com.ad4screen.tracking_mode acc_tracking_mode normal
    com.ad4screen.senderid acc_sender_id  
    com.ad4screen.privatekey acc_private_key  
    com.ad4screen.partnerid acc_partner_id  
    com.ad4screen.notifications.icon acc_notification_icon  
    com.ad4screen.notifications.accent_color acc_notification_accent_color  
    com.ad4screen.no_geoloc acc_no_geoloc false
    com.ad4screen.logging acc_logging false
    com.ad4screen.location.priority acc_location_priority normal
    com.ad4screen.idsprovider acc_ids_provider  
    com.ad4screen.cache.delay acc_cache_delay 10
    com.ad4screen.advertiser_id acc_advertiser_id true

    Inbox

     Starting with 3.6.x version, Inbox tracking needs to be implemented by your self. If you already use Inbox feature and do nothing, no more statistics will be available. Please see our Inbox documentation.

    Plugins migration

    Beacons

    The new version of Accengage SDK 3.6.x is not compatible with the older version of Accengage Beacon Plugin 1.0.x plugin version. You need to upgrade the plugin to the version 1.1.0 or higher:

    build.gradle

     

     

    Upgrade from version 3.4.x to 3.5.x

    The version 3.5.x Android min-SDK is now 9 (2.3).

    build.gradle

    In your build.gradle, upgrade the android.defaultConfig.minSdkVersion to 9 if necessary:

     

    Using Google Play Services plugin

    The 3.0.1 Google Play Services Plugin is now splitted in 4 parts. AdvertiserId, Location and Push parts do not need any modification.

    If you use Geofences and upgrade from 2.x.x to 3.x.x you need to remove the following lines from your AndroidManifest.xml:

    Previous lines are now in the plugin manifest and will be automatically merged in your own AndroidManifest.

    Using custom notifications template

    If you use custom notifications template, widgets IDs changed:

    • com_ad4screen_sdk_logo -> com_ad4screen_sdk_notification_logo
    • com_ad4screen_sdk_title -> com_ad4screen_sdk_notification_title
    • com_ad4screen_sdk_body -> com_ad4screen_sdk_notification_body
    • com_ad4screen_sdk_picture -> com_ad4screen_sdk_notification_big_picture

     

    Upgrade from version 3.3.x to 3.4.x

    The version 3.4.x now supports only Android Studio. If you are still using Eclipse, please migrate to Android Studio. If it is not possible, please use an older version (like the 3.3.x).

    build.gradle

    Verify the applicationId is set in the project’s build.gradle file:

    Using GCM Push Notifications

    Remove the following lines from your AndroidManifest.xml:

    Previous lines will be automatically merged in your AndroidManifest.xml using the Manifest Merger.

    Using Google Play Services plugin

    The 3.4.x version is not compatible with older 1.6.x plugin versions. You need to upgrade to version 2.0.0. For this, add the following dependency:

    This version uses the InstanceID feature instead of deprecated GCM APIs. It means that you can register yourself to another Sender ID using InstanceID without conflicts with the Accengage Sender ID registration process.

    Using ProGuard

    If you are using ProGuard, the 3.4.x version includes Proguard rules in the AAR. You do not need to include them in your own rules.

    Using Beacons

    The 3.4.x version is not compatible with older 1.0.3 plugin version. You need to upgrade to version 1.0.4. For this, add the following dependency:

    Using Geofences

    Add the following lines in your AndroidManifest.xml file:

    2.4 Send a basic push

    To test your integration, activate logs and start your application. You will see the following lines in the logcat, meaning the SDK is correctly launched:

    Android Monitor

    You can then follow our tutorial to get to know more about how to use the application.

    Section 3 - Advanced push configuration

    3.1 Rich Push

    The Rich Push for Android is a push notification on which a click opens the SDK activity with a webview to display a content of the Rich push URL

    It is possible to customise some widgets of the Rich Push Activity. Below you can find its default template:

    You can customise each element but you need to keep the type of the widget (Button, ToggleButton, etc...) and the same id. You can also remove widgets from the layout but the WebView widget is mandatory.Below you can find it's default template

    For more details, check out the use case "Removing the control panel for Rich Push".


     

     

    3.2 Notification Sound

    If you want to add a custom sound for your notifications, please add your mp3 file in the res/raw folder of your application. Then, provide the file name (without the extension) in the Accengage User Interface.


    3.3 Push Actions

    Push actions are actions the SDK executes after clicking on the notification. They must be chosen via Accengage dashboard on the page editting push notifications. Push actions can be classified by three categories:

    • By click zone
    • By action type
    • By opening way

    This classification is needed to better understand how the SDK handles This method prevent the displayactions of push notifications.

    With the action you can also pass custom parameters. Please check out the section Retrieving Message Parameters to get to know how to obtain your custom parameters in the application.

    By click zone

    Depending on the click area (content or buttons) of notification, push actions can be divided into two types:

    Content Action

    Button Action

    By action type

    There are 7 different action types available for push notifications:

    • Webview
    • Browser
    • URL-scheme (deeplinking)
    • Click-to-mail
    • Click-to-phone
    • Click-to-Play store
    • Click-to-SMS

    All of these 7 types you can use as a Button Action and only the first 3 as a Content Action.

    By opening way

    An activity handling corresponding action type (webview activity, browser activity, deeplinking activity, etc) can be launched by two different ways:

    • attached to the application
    • detached from the application

    "Attached" means that after clicking on the Back button from the goal activity you will be returned to your application even if it was in background or not started. For "Detached" action you will be returned to the previous place (activity) which you had before at the moment by clicking on the push notification. In this case the SDK doesn't resume the app activities from background or launch the main activity if the app wasn't started.

    Note!

    1. Content actions are all "attached".
    2. Button actions are all "detached" except the action type Webview.

    Attached Actions

    The SDK before handling an "attached" action resumes the last activity or the main one if the app is not launched. If for some reasons after resuming the activity you don't want to display immediately an another one executing your attached action, you may use the SDK method:

    This method prevents the display of activities executing the attached actions. To enable the processing of the attached actions you need to call:

    Check out our advanced use case - "Display rich push after splash screen" for more details.

    3.4 Notifications Templates

    Default templates

    The SDK provides 3 default templates which you can use for your notifications. 

    Big text

    Use this template when you have short or long text to display without an image. You can also use buttons for it.

    Android 4.1+

     

    Collapsed

     

    Expanded

    Android 5+

     

    Collapsed

     

    Expanded

    Android 7+

     

    Collapsed

     

    Expanded

    BigText uses default Android notification templates. They could be found on android.googlesource.com. For instance, collapsed and expanded templates for Android 7.1.1_r9 are presented on the table below:

    Big picture

    Use this template when the notification contains a short text and a pictureSizes for Big Picture are minimum - 512x256, balanced - 1024x512 and maximum - 2048x1024. You can also use buttons for it.

    Android 4.1+

    Collapsed

    Expanded

    Android 5+

    Collapsed

    Expanded

    Android 7+

    Collapsed

    Expanded

    BigPicture uses default Android notification templates. They could be found on android.googlesource.com. For instance, collapsed and expanded templates for Android 7.1.1_r9 are presented on the table below:

    Big text Big picture

    With the last default template you can use a long text and a picture the same time. Buttons are disabled for this template.

    Android 4.1+

    Collapsed

    Expanded

    Android 5+

    Collapsed

    Expanded

    Android 7+

    Collapsed

    Expanded

    BigTextBigPicture uses default Android templates for a collapsed view and the custom SDK template for an expanded view.

    ViewTemplate
    Collapseddefault Android templates for collapsed view
    Expanded

    for API less than API16 default Android templates for Big Text will be used

    Custom templates

    Among the default templates you can also create your own ones to use them for Accengage push notifications. For this you need:

    1. Create collapsed and expanded templates in Android Studio for your project
    2. Add names of created templates on the Settings page of Accengage dashboard
    3. Select corresponding templates on the page editing your push notification
    1) Creating collapsed and expanded templates

    To display notification content (title, messages, pictures, etc) your custom collapsed/expanded templates should contain such views:

    View IDTypeViewDescriptionCustomized by (Accengage Dashboard controls)
    iconImageViewCollapsed/ExpandedLarge Icon before Android7, Small Icon after Android7Thumbnail (<Android7)
    app_name_textTextViewCollapsed/ExpandedName of the app (Android7+)Custom parameters: a4sappname
    header_textTextViewCollapsed/ExpandedHeader (Android7+)Custom parameters: a4sheadertext
    timeDateTimeViewCollapsed/ExpandedTime of the reception 
    titleTextViewCollapsed/ExpandedNotification titleTitle
    text_line_1TextViewCollapsed/ExpandedAdditional text located on the right side of the title (Android7+)Custom parameters: a4scontentinfo
    infoTextViewCollapsed/ExpandedAddional Information (before Android7)Custom parameters: a4scontentinfo
    textTextViewCollapsed/ExpandedNotification textShort/Expanded message
    right_iconImageViewCollapsed/ExpandedRight Icon (Small Icon before Android7, Large Icon after Android7)Thumbnail (Android7+)
    big_pictureImageViewExpandedBig picturePicture
    big_picture_2ImageViewExpandedSecond big picture (twitter style)Custom parameters: a4sbigpicture2
    actionsLayoutExpandedAction areaButtons
    action0ButtonExpandedInteractive buttoncurrently not supported by the dashboard

    Below there are custom collapsed and expanded layouts extracted from Android Open Sources demonstrating where normally should be located these views.

    These layouts are already presented in the SDK. To test them you just need to add layout names (acc_notification_template_material_base and acc_notification_template_material_big_picture) on the Settings page of Accengage dashboard. If you want to modify certain elements (for instance, background color or position), copy these templates to the project and change its names, then you can customize layouts views according to your needs.

    2) Add names of created templates on the Settings page of Accengage dashboard

    Once your custom templates have been added into your project. It's necessary to add names of expanded and collapsed templates on the Settings page.

    3) Select corresponding templates on the page editing your push notification

    Now you can use the custom collapsed and expanded templates added previously on the Settings page for your push notification.

    Collapsed template

    Expanded template

    3.5 Interactive Buttons

    Since the SDK 3.3.0 and Android 4.1 (API 16), you can add interactive buttons for notifications with BigText and BigPicture templates.

    Predefined button icons

    The list of predefined icons which you can use in Accengage dashboard without integrating them into your app is presented below:

    Icon nameIcon 16+ (Holo)Icon 21+ (Material Design)
    com_ad4screen_sdk_notification_icon_call
    com_ad4screen_sdk_notification_icon_later
    com_ad4screen_sdk_notification_icon_less
    com_ad4screen_sdk_notification_icon_man
    com_ad4screen_sdk_notification_icon_more
    com_ad4screen_sdk_notification_icon_no
    com_ad4screen_sdk_notification_icon_rate
    com_ad4screen_sdk_notification_icon_share
    com_ad4screen_sdk_notification_icon_thumb_down
    com_ad4screen_sdk_notification_icon_thumb_up
    com_ad4screen_sdk_notification_icon_women
    com_ad4screen_sdk_notification_icon_yes

    Add your own icons

    For other icons you would like to use please add them in drawable folders of the app for each density (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi).

    • For Android 16+, the icon needs to be white and should be placed in drawable-density-16 folders (where density can be mdpi, hdpi, xhdpi, ...)
    • For Android 21+, the icon needs to be grey and should be placed in drawable-density-21 folders (where density can be mdpi, hdpi, xhdpi, ...)

    To find more icons, click on the following link: http://icons4android.com/

     

    3.6 Notifications Icons

    By default, we are using your launcher icon as a logo for your notifications. Since Android 4.4, Google guidelines require   white and transparent flat icon . If you don't follow the guide lines your notification icon may look like on the images below (Android 4.4+ and Android 7+).

    Android <4.4

    Android 4.4+

    Android 7+

     

    Android 4.4+

    To fix this you need to add a notification icon compliant with Google guidelines in your drawable resources and specify it in your strings.xml file:

    strings.xml

    Please note that "your_icon_name" is the name of the icon without extension and/or path. For instance, if you want to use drawable/ic_action_search.png, please replace "your_icon_name" by "ic_action_search".

    Try notification icon generator to create your Material Design Notification icons.

    Example of white and transparent notification icon

     

    Android 4.4+

     

    Android 5+

    From the version Android 5 (Lollipop) you may:

    • change an accent color in a circle behind your icon image
    • use a large notification icon

    Accent Color

    There are two ways to set an accent color:

     

    Android 5+

    Android 7+

    1. Statically, in the strings.xml file:

      strings.xml
    2. Dynamically, via Accengage dashboard in custom parameters of push notification 

    Your accent color can be set in ARGB/RGB format, or in a color name format, for instance bleu.

    Large Notification Icon

    If you want to use a large notification icon as shown on the images below, you need:

    • either add a thumbnail via Accengage dashboard

    • or set programmatically by overriding getLargeIcon or getLargeIconUrl methods of NotificationClientCreator class. 
    Android versions lower than Android 5 can also support large notification icons by using com.android.support:appcompat-v7.

    Android <5

     

    Android 5+

     

    Android 7+

     

    Note that the small icon is added automatically and the image source is:

    • either your launcher icon
    • or the icon specified in the strings.xml file in the acc_notification_icon parameter.

    3.7 Back Stack

     


    This part shows how activities of your application can be organised on the task's back stack while handling notifications (pushes and alarms) by the SDK. The position of your activities on the task's back stack depends on the launchMode, flags, and other parameters described here and as a result it also depends on the pushs, the way they are going to be openedattached or detached to/from the app.

    1. Attached push actions

    Attached push actions are handled by using application activities (inheriting A4SActivity or integrating directly A4S API methods). The actions are normally handled in an existing task of the application but if it is not existed (the application is not started or closed) a new task will be created, where the main activity is launched on the top of it to handle notification action. 

    Ex.1.1 Back stack and webview

    In this example the back stack contains a task with 3 activities before clicking on a notification. After clicking on a notification with a rich push URL the SDK starts the internal webview activity in the same task.

    Ex.1.2 Back stack and deeplink (case 1)

    This example shows how the SDK launches an activity (Activity B) using a deeplink.

    Ex.1.3 Back stack and deeplink (case 2)

    This is the same example as the previous one but the activity we are going to launch using a deeplink is the last activity in the task. If the launchMode for this activity in your manifest file is "standard", a new instance of the activity will be created.

    Ex.1.4 Back stack and deeplink (case 3)

    This is the same example as the previous one but the launchMode for deeplinking activity is "singleTop".

    The procedures of handling notifications with rich push URL or deeplinks demonstrated above are the same for the empty back stack. There is only one difference: the SDK launches the main activity (launcher activity) instead of resuming the last activity in the task.

    2. Detached push actions

    Detached push actions are handled in a new task (see FLAG_ACTIVITY_MULTIPLE_TASK) by internal activity provided by the SDK. Since an action is handled in a new task, application's activities (if they are existed) won't be resumed. It allows to return quickly to the place where the notification was opened without popping recent activities of the application from the back stack.

    Ex.2.1 Back stack and Browser or deeplink (case1)

         

    Ex.2.3 Back stack and deeplink (case 2)

    In case if a notification starts an activity with a launchMode 'singleTask' or 'singleInstance' using a deeplink and there is no such activity in the back stack, the activity will be started in a new task.

     

    Ex.2.4 Back stack and deeplink (case 3)

    In case if a notification starts an activity with a launchMode 'singleTask' or 'singleInstance' using a deeplink and the activity is already existed in the back stack, this activity will be resumed by calling onNewIntent.

     

    3. Customizing the back stack

    Since the version 3.5.1 of the SDK you can also customize the back stack at runtime. There are two additional callbacks in NotificationClientCreatorgetTaskStackBuilder and getTaskStackBuilderForButton. Using these two methods you can specify activities you would like to have in the back stack after opening a notification. 

    3.8 Customising notifications at Runtime

    Starting with the Accengage SDK 3.5.0, you can customise notifications at runtime.

    For this, create a class that implements com.ad4screen.sdk.service.modules.push.NotificationClientCreator:

    Implement methods like you want. If you want to keep the default values used by the SDK, just return null.

    When your class is implemented, add in your Application's onCreate the following line:

    The class needs to have a public parameterless constructor.

    The class is instanciated and executed in the SDK Process, some of your class' instances may not be initialized.

     

    Section 4 - In-App Messages

    The Accengage SDK provides you with notifications display without any additional code to write in order to support them.

    There are five different kinds of In-App notifications:

    • Text: an In-App notification that appears as a view with a height of 50 containing a title and a text body.
    • WebView: an In-App notification that appears as a view with a height of 50. It contains a webView that displays the content of a URL.
    • Text Interstitial: appears in full screen and contains a title and a text body.
    • WebView Interstitial: it appears in full screen and contains a webView that displays the content of a URL which is clickable.
    • WebView Interstitial with NavBar: appears in full screen and contains a webView that displays the website target of a URL. It also displays a navigation bar and can be browsed.
    • Popup: appears on the screen and interrupts the user. It can also contains two buttons to lead to different events.

    Below you can find examples of these types of In-App messages, and their layout (used for customization, see the next part for more details)

     

    Banner

    Interstitial

    Popup

    4.1 Basic display

    In-App actions are actions the SDK executes after clicking on the In-App message. They must be chosen via Accengage dashboard on the page editting an In-App message. 

    Besides 6 default actions:

    • Browser
    • Click-to-mail
    • Click-to-call
    • Click-to-Play Store
    • Click-to-SMS
    • URL-scheme (deeplinking)

    there are also Webview and Text actions opening the content (web page of the selected URL or message text) on the specified templates - Landing Pages. The default Landing page layouts for Text and Webview are listed below:

    They contain:

    • A fake ActionBar with 2 ImageViews (logo and back), a TextView (title) and a button (close)
    • A TextView for the Landing Page body
    • A WebView for the Landing Page URL
    • A button Bar with a ProgressBar, a ToggleButton (reload) and 3 buttons (browse, back, forward)

    Display and Click parameters

    In Advanced Options for In-App message on the dashboard you may add display and click parameters. Visit the section  Retrieving Message Parameters  to get to know how to obtain these parameters in the application.

    Custom Landing Page

    If you need to modify the default templates you can add your own Landing page layouts to In-App templates on the Settings Page. After adding a new Landing Page template, the new action will be available on the page editing an In-App message.

    Webview Landing Page

    Text Landing Page

    Close In-App from In-App's content

    You can close the In-App with a specific URL inside the In-App. I n your HTML content, add the  bma4sclose  key in the closing URL, for example:


    4.2 Advanced display customization

    Notification display customization

    In order to match the Google guidelines for Android, we advise you to customize the behavior and appearance of the pop-up notifications.

    Please see Customizing Pop-up.

    If you want to position this banner at a custom position, you simply have to include the layout com_ad4screen_sdk_banner where you want the banner to be displayed in your layout

    Custom Banner Position

    Text or Webview banner

    By default, banners are created on the bottom or your activity layouts. If you want to customize a position of the banner, you need to include  com_ad4screen_sdk_banner into your layout. The com_ad4screen_sdk_banner is a FrameLayout inside which your banner will be inflated. Below there is an example of activity template containing com_ad4screen_sdk_banner:

     

     

    Multiple banners

    You can also display several banners of different types (webview and text) on the same layout in different places. For this, instead of including layout com_ad4screen_sdk_banner you will need to add empty layouts with banner template IDs you would like to use. For instance, in order to show two text banners and two webview banners, you activity layout may look something like this:

     

     

     

     

     

     

     

     

     

     

     

    Custom In-App Templates

    If you want to use your own template, you have to add it in the Accengage dashboard and create a new xml layout with the same name as the value you specified. To display inapp content (message, close button and webiew) your custom templates should contain such views:

    View IDTypeDescription

    com_ad4screen_sdk_webview

    ScrollableWebView/Webview

    Banner web view

    com_ad4screen_sdk_body

    TextViewBanner text view

    com_ad4screen_sdk_closebutton

    ButtonClose button

    Custom Webview Banner

    my_banner.xml

    Adding a custom webview banner template

    Selecting the custom template

     

     

    Custom Text Banner

    Custom text banner layout:

    my_text_banner.xml

     

    Adding a custom text banner template

    Selecting the custom template

     

     

    Customizing a position of custom banners

    If you want to customize a position of your custom banner you may use:

    • either com_ad4screen_sdk_banner
    • or directly FrameLayout with desired template ID 

    as described in the previous section. Below there is an example of the activity layout containing the custom text banner my_text_banner by using FrameLayout:

    activity_main.xml

    Custom Interstitials

    Like banners, interstitials can also be customized. To do this you need to:

    1. Create your own layout based either on default text interstitial or on default webview interstitial
    2. Add it's name to the Settings page of Accengage dashboard
    3. Select corresponding template on the page editing your In-App message (message format)
    1. Create a custom interstitial template

    To display inapp content (message, close button and webiew) your custom templates should contain such views:

    View ID
    Type
    Description

    com_ad4screen_sdk_webview

    ScrollableWebView/Webview

    Banner web view

    com_ad4screen_sdk_body

    TextViewBanner text view

    com_ad4screen_sdk_closebutton

    ButtonClose button
    my_intersitial.xml

     

     

     

     

    2. Add a custom template name on the Settings page

    According to the type (Webview or text) of your interstitial, create your In-app template on the Settings page with the layout name.

    Custom Webview interstitial template

    Custom text interstitial template

    3. Select corresponding template on the page editing your In-App message

    Custom Popups

    You can fully customize pop-up messages of InApp and Push notifications. For this, it's necessary to redefine a default theme of A4SPopup activity in AndroidManifest.xml:

    Please note that the “tools:replace” line is required in order to indicate to the ManifestMerger that it must use your theme instead of the library default one’s. The corresponding XML namespace xmlns:tools="http://schemas.android.com/tools" must also be added in AndroidManifest.xml:

    A new theme you would like to create must inherit the pop-up Accengage theme  com_adscreen_sdk_theme_popup :

    theme.xml

    The com_adscreen_sdk_theme_popup  theme is based on default android dialog theme. A list of default themes inherited by the com_adscreen_sdk_theme_popup is shown in the table below.

    Android versionAndroid parent theme
    v4-v10Theme.Dialog
    v11-v13Theme.Holo.Dialog
    v14 - ...Theme.DeviceDefault.Dialog

    You can customize a dialog by redefining the properties of default android dialog theme:

    To achieve a possibility to fully customize a pop-up dialog there are additional properties:

    Property
    Default value
    Description
                     com_ad4screen_sdk_popup_inapp_title_layout 
                  
    @null
    Custom layout for InApp Pop-up title (not specified by default)
                    com_ad4screen_sdk_popup_notif_title_layout
                  
    @null
    Custom layout for Notification Pop-up title (not specified by default)
                    com_ad4screen_sdk_popup_inapp_layout
                  
                    @layout/com_ad4screen_sdk_popup_inapp
                  
    Custom layout for InApp Pop-up content (message)
                    com_ad4screen_sdk_popup_notif_layout
                  
                    @layout/com_ad4screen_sdk_popup_notif
                  
    Custom layout for Notification Pop-up content (message)
                    com_ad4screen_sdk_popup_inapp_buttons_layout
                  
                    @layout/com_ad4screen_sdk_popup_inapp_buttons
                  
    Custom layout for InApp Pop-up buttons
                    com_ad4screen_sdk_popup_notif_buttons_layout
                  
                    @layout/com_ad4screen_sdk_popup_notif_buttons
                  
    Custom layout for Notification Pop-up buttons
                    com_ad4screen_sdk_popup_inapp_primary_button
                  
                    @style/com_ad4screen_sdk_popup_inapp_primary_button_style
                  
    Custom style for the primary button of InApp Pop-up
                    com_ad4screen_sdk_popup_inapp_secondary_button
                  
                    @style/com_ad4screen_sdk_popup_inapp_secondary_button_style
                  
    Custom style for the secondary button of InApp Pop-up
                    com_ad4screen_sdk_popup_inapp_other_button
                  
                    @style/com_ad4screen_sdk_popup_inapp_other_button_style
                  
    Custom style for other buttons of InApp Pop-up
    com_ad4screen_sdk_popup_notif_primary_button
                    @style/com_ad4screen_sdk_popup_inapp_primary_button_style
                  
    Custom style for the primary button of Notification Pop-up (Cancel)
                    com_ad4screen_sdk_popup_notif_secondary_button
                  
                    @style/com_ad4screen_sdk_popup_inapp_secondary_button_style
                  
    Custom style for the secondary button of Notification Pop-up (OK)
                    com_ad4screen_sdk_popup_notif_other_button
                  
                    @style/com_ad4screen_sdk_popup_inapp_other_button_style
                  
    Custom style for other buttons of Notification Pop-up (Not used)

    Examples

    Customizing Popup title (by layout)

      In case if you want to modify the whole title (and not just the title font, text style, etc by redefining  android:windowTitleStyle ) you will need to create a custom layout for the title and specify it in your theme.

    my_popup_notif_title.xml
    themes.xml

    Customizing Popup content (by layout)

    To modify InApp/Push Pop-up content you need to redefine corresponding layouts in your theme:  com_ad4screen_sdk_popup_inapp_layout  /  com_ad4screen_sdk_popup_notif_layout

    themes.xml

    and add a custom layout:

    popup_notif_content.xml

    Customizing Popup buttons (by styles)

    Redefine default button styles by your own ones:  

    themes.xml
    styles.xml

    Customizing Popup buttons (by layout)

    This approach is more powerful than previous one. It allows to replace default button layout (with buttons) by custom one. Here is an exemple:  

    themes.xml
    popup_notif_buttons.xml

    Note that custom layouts should contain default views with its original ids to display pop-up properly. The list of default title, content and button layouts is presented below.

    Customizing In-App At Runtime

    To customize an In-App message (Banner or Interstitial) at runtime, you need to register a callback by setInAppInflatedCallback method. When the SDK adds an In-App message to a parent view the registered callback will be called. At this moment, in the callback, you can obtain the parent view containing an in-app template (either predefined or  custom ) and modify it to your needs. 

    The following example demonstrates how to add two additional buttons at runtime.

    In this callback you can also obtain display parameters.

    In-App Actions

    In-App actions are actions the SDK executes after clicking on the In-App message. They must be chosen via Accengage dashboard on the page editing an In-App message.

    Besides 6 default actions:

    • Browser
    • Click-to-mail
    • Click-to-call
    • Click-to-Play Store
    • Click-to-SMS
    • URL-scheme (deeplinking)

    there are also Webview and Text actions opening the content (web page of the selected URL or message text) on the specified templates - Landing Pages. The default Landing page layouts for Text and Webview are listed below:

    They contain:

    • A fake ActionBar with 2 ImageViews (logo and back), a TextView (title) and a button (close)
    • A TextView for the Landing Page body
    • A WebView for the Landing Page URL
    • A button Bar with a ProgressBar, a ToggleButton (reload) and 3 buttons (browse, back, forward)

    Here are the views' Ids:

    • com_ad4screen_sdk_logo
    • com_ad4screen_sdk_closebutton
    • com_ad4screen_sdk_backbutton
    • com_ad4screen_sdk_forwardbutton
    • com_ad4screen_sdk_title
    • com_ad4screen_sdk_body
    • com_ad4screen_sdk_webview
    • com_ad4screen_sdk_progress
    • com_ad4screen_sdk_reloadbutton
    • com_ad4screen_sdk_browsebutton

    Display and Click parameters

    In Advanced Options for In-App message on the dashboard you may add display and click parameters. Visit the section  Retrieving Message Parameters  to get to know how to obtain these parameters in the application.

    Custom Landing Page

    If you need to modify the default templates you can add your own Landing page layouts to In-App templates on the Settings Page. After adding a new Landing Page template, the new action will be available on the page editing an In-App message.

    Webview Landing Page

    Text Landing Page

    Close In-App from In-App's content

    You can close the In-App with a specific URL inside the In-App. I n your HTML content, add the  bma4sclose  key in the closing URL, for example:

    Sample

    A sample is available on Github : https://github.com/Accengage/accengage-android-sdk-samples/blob/master/AccSample/app/src/main/res/layout/my_template_landing.xml

    In-App Lifecycle

    Your application can be notified when In-App messages change its states. The following diagram shows the states of In-App message (only Banners and Interstitials).

    To receive callbacks about state changes there are 5 corresponding methods:

    MethodDescription

    setInAppReadyCallback

    In-App message is ready for display
    setInAppInflatedCallback In-App view hierarchy is inflated and added to the parent layout (for more details, see Customising In-App TODO)
    setInAppDisplayedCallback In-App is currently displayed

    setInAppClickedCallback

    In-App has been clicked
    setInAppClosedCallback In-App is closed and not displayed anymore
    All the callbacks are reset on A4S.stopActivity() launch, so the callbacks should be initialized while resuming activities.

    Ready state

    If you need to receive events about the ready state of In-App message you should register a callback by the method setInAppReadyCallback. It might be useful, for example, to obtain additional information about the In-App which will be displayed, like message ID, template, custom parameters, etc.

    Also setInAppReadyCallback can be used in conjunction with displayInApp to control a moment when a ready In-App message should be displayed. For this, you need to use true for the first parameter manuallyAllowDisplay of setInAppReadyCallback and then call displayInApp at the moment you want to display the In-App message.

    Inflated state

    Registering a callback for inflated state could be useful:

    Prevent In-App display

    If you don't want to display any inapp message temporarily, you can use:

    This function allows you to enable or disable any In-App notification display. By default, its value is false which means that InApp display is enabled.

    Once Inapp is locked, no In-App visual element will be displayed until unlocked. Please use this function with care!

    Templates filter

    For all callbacks, you can pass templates of In-App messages in the setInApp*Callback() methods for which you need to listen state changes. For instance, if you want to be notified that an In-App message is closed for In-Apps using  com_ad4screen_sdk_template_banner_fullscreen   (Intersitial Banner) or  com_ad4screen_sdk_template_banner_fullscreen_nobuttons  ( Intersitial Banner without the close button ) templates you need to pass these templates as arguments of the corresponding setInApp*Callback() method:

    In-App Force Update

    The SDK updates In-App messages from the server at the beginning of new session.

    In case if you need to force the In-App message update you can do it by updating a custom field of the Device Information by random value. Note that the custom field must be created before via Accengage dashboard.

    In-App Tracking Zones

    To track clicks from several zones (buttons, layouts, views, etc) of the In-App message (only Banners and Interstitials),  InApp  class provides three methods:  setClickZone handleClick  and  dismiss . The first method sets the name of the zone and two others handle clicks by closing the in-app and sends a tracking information to the server. There is only one difference between handleClick and dismiss. The  handleClick  sends a track information about a click event and  dismiss  sends it about a close event. For both methods setting a name of the zone is optional. If you don't need to track different zones, you can call  handleClick / dismiss  without  setClickZone . In this case the tracking information won't contain the name of the zone and the server wont be able to distinguish clicks/closes from different zones.

    Setting tracking zones

    Tracking zones must be set on the Inflated state of In-App message, when In-App view hierarchy is already created but not yet shown on the screen. For this, you need to register a callback by the method setInAppInflatedCallback. In the callback, add your click/touch listeners to the views the click on each you need to track. Then in your click listeners, set the name of your tracking zone by setClickZone method and call handleClick/dismiss in order the SDK could process the click and send a tracking information to the server.

    For more details, see the example below adding 4 tracking zones for different views and opening a web page in a Browser by clicking on the "Zone1". An URL of the page is passed in the custom parameters.

    Please note, that click action must be set to "No Action" in order to prevent the SDK executes the set action on any click. If the action is not set to "No Action", clicks on the In-App content will be intercepted by the SDK and you will not be able to set click listeners for them.


      

    The example is available on github:  InAppMultiAction .

    4.3 Handling actions

    Update Device Info using In-App

    There are two ways to update Device Information using In-App messages:

    • by In-App action
    • by In-App content

    Update Device Information by In-App action

    By executing an In-App action (WebView or URL Scheme) you can also update the device profile (Device Information) the same time. For this, you need to add your key/value parameters packed in URL encoded JSON format as bma4sudi GET parameter to your URL.

    For example, if you want to update values of two fields 'First Name' and 'Gender' of the server database on Kevin and Male correspondingly 

     

     

    you need to:

    1. create a JSON with 2 key/value pairs, where the key is the field name in DB

    2. apply URL encoding for the JSON

    3. add the output as bma4sudi GET parameter to your http or custom URL scheme link
      • HTTP link

      • Deeplink

     

    Then after clicking on your In-App message while opening a web page or doing a deeplink redirection, your server DB fields will be updated for new values.

    Update Device Information by In-App content

    By displaying an In-App content on a webview of banners or interstitials you can update the Device Information. As in the previous section, you need to add your key/value parameters packed in URL encoded JSON format as bma4sudi GET parameter to your URL.

     

    Prevent In-App message display

    If you don't want to display any In-App message temporarily, you can use:

    This function allows you to enable or disable any In-App notification display. By default, its value is false which means that InApp display is enabled.

    Once Inapp is locked, no In-App visual element will be displayed until unlocked. Please use this function with care!

    Section 5 - Scheduled Alarms (Local Notifications)

    To the user, there is no difference between a local and remote push notification when presented on a given device. Both types of notifications have the same default appearance, which is provided by the system. 

    With local notifications, Accengage SDK configures the notification details locally and passes those details to the system, which then handles the delivery of the notification. With remote push notifications, a server is used to push data to user devices. This means that local notifications can be scheduled and delivered to the device even if there's no internet connection which is not the case with remote push notifications. To schedule a local notification even when there's no internet connection, you'll need to mark it as persistent on the Accengage dashboard.

    All the methods are already handled by our SDK so you don't have to write anything.

    If you want to trigger In-App messages or scheduled alarms after tracking events (lead, cart, purchase or custom), these events must be created first via Accengage dashboard (Settings -> Settings -> section Events), and then selected as inclusion/exclusion events in your messages.

     

    Section 6 - Inbox

    The inbox feature lets you store targeted Inbox messages inside an Inbox within your app, in a similar way that a mailbox stores emails. With this Inbox, your users can retrieve messages over time, browse through the list of inbox messages and interact with them. Inbox messages are a good complement to push notifications or in-app messages.

    These Inbox messages can be a text, a webpage, a landing page, ... with or without buttons and interact directly with the Accengage SDK. E.g. your message can include an event button, trigger an URL Scheme, or display a banner/interstitial when the user opens a message.

    If you want to use this feature, the Accengage servers will send all the messages information to your app, but you will need to handle the display yourself.

    Sample

    A sample is available on Github : https://github.com/Accengage/accengage-android-sdk-samples/tree/master/AccInbox

    This example contains 2 activities:

    • InboxList → A list displaying the Title, Extract, Date, etc.. of each message, with all status options (Read, Unread, Archive)

    • ShowMessage → An activity which displays a message including buttons

    6.1 Basic configuration

    With Accengage Inbox you can:

    • Subscribe/Unsubscribe to Inbox Messages on a device
    • Get messages and display them in your own template
    • Update messages on the Accengage servers (Read/Unread/Archive)

    Get Messages

    Use the following method to retrieve your messages:

    You need a callback to be notified when messages are received. Here is an example of how to define it:

    List Messages

    Now that you have your inbox object filled with messages, it's time to list your messages. In this example, we will just display a toast with the title of each message

    Display a message

    Now that our messages are downloaded, we can safely display them. Then according to the message format, the SDK will either open it itself or give it to you. If the message is returned to your application, a callback will be triggered and you will have to handle the message's display.

    Work with Message Buttons

    A message can have several buttons and here is an example of how to display and interact with them.

    Note: Don't forget to add each button to your layout.

    Update a message

    You can change the status of a message, here is how to do it

    Last step, you need to send all the changes made on this inbox to the Accengage Servers:

    6.2 Advanced configuration

    Messaging with Firebase

    Introduction

    By adding Accengage open source library A4SSamples which uses Firebase AuthenticationRealtime Database and Analytics to your application you can easily integrate Inbox Messaging service with a few lines of code. The library allows you to:

    • authenticate users (with different auth providers - google, email, etc) 
    • work with Inbox messages on several devices the same time (messages are synchronised between devices with Firebase Realtime Database)
    • have an access to archived and expired messages (you don't need to care about storing messages that Accengage doesn't provide any more)
    • filter messages by their categories
    • have Gmail look like UI


    MainActivity.java

    Gmail

     

    Integration

    Adding Firebase to your Android project

    Create Firebase project and add a config file google-services.json to app folder. Fore more details please go here.

    Then, include google-services plugin to the top-level build.gradle:

    and apply it by modifying the app/build.gradle:

    Adding A4SSamples library

    Add maven repositories to top-level build.gradle:

    Modify the app/build.gradle by adding the SDK, A4SSamples and some additional dependencies which are not mentioned in the .pom files:

    Modifying the code

    Multidex support

    Modify the module-level build.gradle file configuration to include the support library and enable multidex output, as shown in the following code snippet:

    app/build.gradle

    In your manifest add the MultiDexApplication class from the multidex support library to the application element

    AndroidManifest.xml

    NoActionBar theme

    The Accengage InboxNacActivity, which we are going to launch, uses DrawerLayout with its own Action Bar. For this reason check that your app theme doesn't use the action bar: android:theme="@style/AppTheme.NoActionBar".

    AndroidManifest.xml

    Where NoActionBar style is declared in styles.xml:

    styles.xml

    Accengage credentials

    As mentioned in the Integration section the A4SSDK must be authenticated and authorised by Accengage servers. That's why you need to add application credentials ( Partner ID  and  Private key ) into  strings.xml  resource file:

    strings.xml

    Starting Inbox

    To launch Inbox with Firebase we need to start InboxNavActivity. In this example we start it directly from the MainActivity:

    MainActivity

    Authentication

    Enable sign-in provider

    Once InboxNavActivity is started a user will need to be authenticated. For that you need to enable sign-in provider via Firebase console.

         

    Audience and Segments

    After signing-in a user name and its email will be sent to Firebase by using User Properties and to Accengage by using Device Information . For this you need to add two user properties for Firebase and two fields of database for Accengage: acc_user_name and acc_user_email.

     

    Firebase user properties will allow your to create different filters for inbox events and to  analyse the audience. While a  user name  and/or  email address  sent by updating Device Information to Accengage will allow to create segments to which you will send Inbox messages.

     

    Users in Firebase DB

    Authenticated users are added to Firebase realtime database. The structure of JSON tree for users you can see in the picture below. It contains user tokens where inside of each there are two fields: email and username.

    Users json tree in the database

    Authenticated users and their tokens

    Messages

    Labels

    There are 4 static labels listed in the Navigation Drawer: Primary, Archive, Expired and Trash. All incoming messages are placed in Primary label. By archiving or deleting a message it will be placed into corresponding label. If a message is expired (Expiration date is set via the dashboard), Accengage server will not send it any more. In this case it will be moved to Expired label.

    There are also dynamic labels. A4SSamples library will create a dynamic label (category) if Category field is specified for the message via the dashboard. A message with a dynamic label always has a static label. In other words, a message with a category will always belong either to Primary or Archive or Expired or Trash. However if a message is removed (located in Trash) and it has a category, the category won't be visible. A4SSamples ignores categories (dynamic labels) of deleted messages.

       

    Messages are stored in the realtime database. It's JSON tree structure is shown below. Node user-inbox-messages contains user tokens where inside of each can be two childs: inbox and trash. Inside of these childs we store messages (removed or not). If a message is not deleted it will be located inside inbox node, if it's deleted it will be located inside trash node. The value of JSON message object under the parent (inbox or trash) is Accengage message ID. The message object has childs describing an Inbox message (title, text, sender, label, etc). 

    Categories

    As we mentioned above, for A4SSamples message categories are dynamic labels. In order to provide the amount of messages for specific categories in the Navigation Drawer there is additional JSON tree: user-inbox-categories. The structure of this node looks like the structure of user-inbox-messages node but instead of JSON message objects there are JSON category objects. Their values correspond to category names and their childs containt message IDs. So the number of childs of JSON category object corresponds to the number of messages with this category.

    By clicking on a category, A4SSamples filters messages by the value of this category and display the result in a new fragment.

     

    Database rules

    In order to prevent that a user has an access to messages of another one it's necessary to determine read and write access to your database. For this you need to grant read and write access only for authenticated users.

    Also we need to index label and category fields to optimise access time to your data.

    So the whole rules may look like this:  

    Rules

    More information you can find here: https://firebase.google.com/docs/database/security/

    Sample

    You can also find a sample application on github: https://github.com/Accengage/accengage-android-sdk-samples/tree/master/AccInboxFirebase 

    The demo application requires Android Studio 3.0. Its architecture is presented below. 

    6.3 Tracking integration

    Tracking integration

    Starting with Accengage SDK 3.6.x, Inbox tracking needs to be manually implemented to match perfectly your own Inbox feature integration in your application.

    If you do not implement the Inbox tracking, no statistics will be available in Accengage User Interface

    Display Tracking

    You can track when a message is displayed. You can choose to display only at the first display or each time the message is displayed. Use the following method:

    Or, if you want to track only for the first display:

    Click Tracking

    You can track when a message is clicked. Use the following method:

    Button Click Tracking

    You can track when a message's button is clicked. Use the following method:


    Section 7 - User profile and behaviour tracking

    Tagging relevant information regarding your user profiles and their behaviours is crucial to send personalized and valuable messages.

    Although the Accengage SDK collects by default certain useful information (such as install date, last open date, number of visits, device model ...), it also offers a number of advanced tagging and tracking features for app developers, that will allow you to target notifications, trigger messages at the right time, customize the user experience and analyze your campaign and application performance.

    It is important that you check with the product or marketing team what type of actions they would like to perform, so that you can determine which information needs to be tagged. Most of the time they will provide you with a "tagging plan" which lists all of these.

    However, a strategy could be to first implement a minimal version of Accengage in order to speed up the process and learn faster, then implement the tagging plan at a later stage for more relevant messages.

    In the following section, we will look at the various options that you can enjoy to collect and use the right information:

    • enrich user profile, thanks to custom device information (or User Attributes), which are very useful for targeting and message personalization
    • tag user location, for geolocation targeting
    • tag user behaviours, thanks to events which offer many benefits (targeting, triggering and measurement), as well as views
    • register users to static lists, in order to manage preferences

    If the information you would like to track is inside a webview, please see the Advanced section here

    7.1 User profiles

    In order to send well-targeted and personalized messages, Accengage lets you enrich your user profiles with additional relevant information, called custom device information.

    These are very important for campaign targeting, as well as message personalization.

    For instance, if you tag and update the first name of a user, you will be able to personalize a message with "Hello ${firstname}".

    Traditional usage of custom device information for instance include first name, account ID (to match with external systems), total number of purchases, last purchased product, last purchase date, favorite product... They can be numeric values (set values, or incremental), strings, dates...

    Note

    Unlike events, the values of these custom device info are unique per user. This means the user's associated fields are single-value type fields and each update will erase currently stored values except when it's an incrementation (or decrementation).


    By implementing the library in your app, you will automatically gather certain information about your app users: their device model, OS version, language, country, time zone, app version, install date, the number of visits and more.

    The Accengage library lets you also collect additional custom device information, which can be attached to the user profile through custom database fields.

    If the information you would like to enrich is inside a webview, please see the Advanced section here.

    Device Information

    The Device Information is a profile qualifying a user device. It contains standard fields filled by the SDK and may contain custom fields that developers can add (for instance, to register whether a user is opt in or opt out for some categories of notifications). The standard fields are sent to the server in different moments: some of them at the beginning of new session, other after 5 minutes timeout if a device location is changed, etc...


     

    Custom fields

    The custom fields are sent to the server after calling the method  updateDeviceInfo() if they contain new values. Old values which are already sent will be ignored to avoid spamming the server. In order to use custom fields they must be created first via Accengage dashboard (for more details, see t he User Guide ). Once custom fields are created you can set/update its values. The following example shows how to set/update two custom fields First Name and Last Name:

     


    Date Format

    You can send a date using the updateDeviceInfo method.

    Your date has to be in the following format: “yyyy-MM-dd HH:mm:ss zzz”

    Please use the code below to format your date before sending it to Accengage servers:

     

     

    Logcat Output

    Error logs

    • Profile update failed = No internet connection or server is unreachable

    • Request succeeded but parameters are invalid = some of the parameters sent are invalid, please read carefully the log to understand what is wrong

    • Some fields do not exist = You tried to update fields that do not exist inside your app's database scheme. Verify your app configuration and please note that fields are case sensitive

    Static Lists

    After creating Static Lists via Accengage dashboard, your application can:

    • get static lists for which the device is subscribed
    • subscribe to static lists
    • unsubscribe from static lists
    • get the status of particular static lists

    Get Static Lists for which the device is subscribed

    A static list contains information defining devices subscribed to the list. The device can be subscribed to a static list either by the Device ID (IDFV) or Client ID. You need to specify it in your .csv file before uploading it to the server. 

    One device can be subscribed to several static lists, i.e. several .csv files with the same DeviceID/ClientID must be uploaded to the server. To check for which static lists the device is subscribed you need to create a callback and pass it to the method getListsOfSubscriptions:

    Subscribe to static lists

    The device can also be subscribed dynamically to static lists via the SDK without specifying it in the .csv file. In order to add the current device to a Static List, create a new StaticList object. Two constructors are available: with and without an expiration date.

    Then pass your static lists for which the device must be subscribed to the method subscribeToLists

    Note that listId#1 and listId#2 are External ID of your static lists.

    Unsubscribe from static lists

    Like for subscription, the device can be unsubscribed dynamically from static lists. In order to remove the current device from a Static List(s), create a new  StaticList  object(s) from which the device must be unsubscribed and pass them to the method unsubscribeFromLists


    Get the status of particular static lists

    If you know ExternalIDs of Static Lists you may check if a device is subscribed or not for them.

    Create a List of StaticLists:

    Create a Callback to get the result or errors (for instance : no network, invalid id, ..) and pass it to the getSubscriptionStatusForLists:

     

    7.2 Behaviour tracking

    Views

    Views are quite similar to States:

    • they are not transmitted to the server
    • they allow to trigger In-App messages ou scheduled alarms

    The main goal of views is to define on which Android activities, fragments or tabs Accengage messages can be displayed.

    In order to use views they must be declared also via Accengage dashboard.

    Then you can select the view for which you need to activate or deactivate triggering a message.

    Set a view

    There are two ways to bind your activities with views:

    • by tag
    • by method

    Binding by tag

    Binding by method

    If you want to tag each Fragment/Tabs and be able to target it, you can use the following code as soon as a view is displayed:

    Log output

    Events

    There are 4 types of events:

    • Lead
    • Cart
    • Purchase
    • Custom

    They differ in the fields sending to the server but they all have same roles:

    • passing analytic information to the server (tracking events)
    • triggering in-app messages or scheduled alarms (inclusion/exclusion events)

    Tracking events

    Lead

    Lead event is an event containing two fields: label and value. To track a lead event you need to create a corresponding object and pass it to the method trackLead:

    Log output:

    After tracking a lead you can check it via Accengage dashboard: 

    Cart

    Cart event is an event containing a cartID and Item. To track a cart event you need to create an Item object, then a Cart one and pass it to the method trackAddToCart:

    Note: Currency should be a valid 3 letters ISO4217 currency (EUR,USD,..) and the 2 last arguments are price and quantity

    Log output:

    After tracking a cart you can check it via Accengage dashboard:

    Purchase

    Purchase event is an event containing an information about the purchase (purchase id, currency and price). The event can also contain items of the purchase. To track it, create a purchase object (with or without items) and pass it to the method trackPurchase:

    Log output:

    After tracking a purchase you can check it via Accengage dashboard:

    Possible reasons of errors:

    • Failed to send purchase events to server = No internet connection or server is unreachable

    • Request succeeded but parameters are invalid = some of the parameters sent are invalid, please read carefully the log to understand what is wrong

    • Error with this purchase = purchase id you tried to send already exists (already sent). Please note that each purchase event sent should have a distinct purchase id

    Custom event

    To track a custom event you need to call trackEvent and pass your eventId and value. You can also add additional parameters to the method. 

    Log output:

    After tracking a custom event you can check it via Accengage dashboard:

    Each event needs to be defined in the Accengage User Interface. Go to Settings > Advanced Settings, and add a new event of type Custom with the code used in trackEvent method. The label is only used for a display purpose.

    SDK 3.7.0+ :

    Please be aware that the maximum length allowed for a custom event is 1024 characters.

    SDK 3.6.5 and inferior versions :

    Please be aware that the maximum length allowed for a custom event is 255 characters.

    If you exceed the maximum length, the event value will be ignored.

    Tracking events from a web page

    If you need to track events from a web page you must open it with A4SWebView which provides JavaScript interface to handle tracking calls on JavaScript from web pages. Below there is JavaScript API for A4SWebView:

    States

    States like events allow you to trigger In-App messages or scheduled alarms. However for states there are two differences:

    1. states are not transmitted to the server
    2. you can trigger messages by state values and not just by state ID (event ID).

    As for events, states must be declared firstly via Accengage dashboard.

    Then you can select a state value for which you need to activate or deactivate triggering a message.

    Set a State

    In order to set/update the state value you need to call putState:

    Where "search" is the state name and “hot to chose a gift” is the value you want to set for this state.

    Clear a State

    In order to clear a state, just set it's value to null:  

    Log output

    Session

    The Accengage SDK sends analytic information (tracking) to the server at the beginning of each session. A new session is created:

    1. at the application startup (if the application process wasn't started before)
    2. or after 5 minutes of SDK API inactivity

    Session analytic information contains a part of Device Information and other fields linked with the session:

    • current session date and time 
    • sessions count
    • app installation date and time 
    • connection type (wifi / cell)
    • android version
    • language
    • country code
    • timezone
    • the SDK version
    • and other technical information

    7.3 Embedded web content tracking

    Accengage webview A4SWebView  contains JavaScript interface to be able to handle calls on JavaScript from web pages.  Below there are methods of JavaScript A4S object which you can use to:

    A4S Javascript Methods

    A4S.trackLead(data)

    Tracks a lead event. The  data  is json containing the lead information. For example:


    A4S.trackAddToCart(data)

    Tracks a cart event. The data is json containing the cart information. For example:


    A4S.trackPurchase(data)

    Tracks a purchase. The data is json containing the purchase information. For example:


    A4S.trackEvent(eventId, data)

    Tracks an event (lead, cart, purchase or custom event). The eventId is an ID of the event (10 - Lead, 30 - Cart, 50 - Purchase, etc) and the data is either json for lead, cart, purchase or value for custom event.

    A4S.setView(view)

    Sets a view for the page you would like to target. The view is a view name value.

    A4S.updateDeviceInfo(data)

    Updates Device Information. The data is json containing fields and it's values to update. For example:


    Javascript Injection

    When an A4SWebview is started, it will automatically run a javascript file added by Accengage as soon as the page is fully loaded. You can replace this script by your own. For this, set your js URL in ad4_webview_script_url parameter:

    strings.xml


    Custom WebviewClient

    If you want to modify a behaviour of A4SWebview methods, you may use your own WebviewClient :


    Close WebView from WebView's content

    You can close the WebView with a specific URL inside the WebView. First, you need to manage the close action.


    Next, in your HTML content, add the 
     bma4sclose  key in the closing URL, for example: http://www.google.com?bma4close=true

    JavaScript Sample

    For quick tests of A4S methods, check out our simple project on node.js rendering an html page with JavaScript code:


    To start the webservice call:


    Section 8 - Geofences and Beacons

    With Accengage, you are able to trigger notifications based on your users real-time location, as they enter (or exit) a specific zone, even if the application is closed and the device locked.

    Real-time notifications based on beacons or geofencing can be setup thanks to Scheduled Alarms or In -App Messages within the Accengage dashboard (Actions > Scheduled Alarms (or In-App messages) > Triggers)

    Attention

    This is not to be confused with the user geolocation, which is only tracked when the user launches the application, and which can be used for push notification targeting in the Accengage dashboard (Targeting > Segments/Lists or Targeting > Search).

    In order to benefit from these features, the Accengage library provides two location-aware technologies : Geofences and iBeacons.

    To get more information about Geofencing and iBeacons, you can also check out the User Guide.

    8.1 Principles

    The Geofencing uses the GPS, and doesn't need any hardware deployment, which is making it very easy and quick to setup.

    The iBeacons, however, use Bluetooth devices but allow to locate your users even more precisely, and are perfect for indoor targeting. You can send them personalized Push Notifications in the right context.

    If you want to discover Geofencing, a sample is available on Github: https://github.com/Accengage/accengage-android-sdk-samples/tree/master/AccGeofences

    And for the iBeacons too : https://github.com/Accengage/accengage-android-sdk-samples/tree/master/AccBeacons

    Take advantage of geolocation to broadcast messages based on users' real-time location data. The library provides two location-aware technologies: Geofencing and Beacons.

    8.2 Permissions

    For the Geofences, the geolocation permission is already asked in the Plugin Google Play Services so it's not necessary to write it again in the AndroidManifest.

    For the iBeacons, the Bluetooth permission is already asked in the plugin, but if for some reasons you don't use our iBeacons plugin, you need to use Bluetooth permissions :

    AndroidManifest.xml

    Region's monitoring (limit the number of regions)

    This functionality allows you to customize the number of geofences region’s that would be monitored by the SDK. It’s useful if you have your own geofences to supervise. Note that by default the SDK monitors all the 100 regions allowed by Android system, and in these 100 regions, 1 region is inevitably dedicated to the global monitoring.

    From version 3.7.0

     

     

    Here you can see the current number of regions monitored by the SDK.

    From version 3.7.0

     

     

     

    8.3 Geofences

    To get to know more about Geofencing check out the User Guide.

    Integration

    To integrate Geofencing, add the dependency for  google-play-services-geofence  to you app-level build.gradle  file:

    Retrieve Geofences from BroadcastReceiver

    Each time a user enters or exits a geofence zone defined in the Accengage User Interface, your app may receive their specific information (like latitude, longitude, etc).

    Create a BroadcastReceiver

    To receive them, you should first create a BroadcastReceiver:  

    GeofenceReceiver.java

    Modify your AndroidManifest.xml

    Now, we have to add our “GeofenceReceiver” class to the AndroidManifest.xml in order to allow the SDK to trigger it when needed:

    AndroidManifest.xml

    Retrieving Geofences from ContentProvider

    Since version 3.5.0 geofences can be retrieved from ContentProvider using A4SContract with specified URI. The code snippet instantiating a CursorLoader is shown below:

    From version 3.5.0

    For more details please see A4SGeofences sample (v3.5.0 is required) allowing to list geofences and sort them by name, distance, radius, detected count,... in ascending/descending order.

        

    Region monitoring

    This functionality allows you to customize the number of geofences region’s that would be monitored by the SDK. It’s useful if you have your own geofences to supervise. Note that by default the SDK monitors all the 100 regions allowed by Android system, and in these 100 regions, 1 region is inevitably dedicated to the global monitoring.

    From version 3.7.0

    Here you can see the current number of regions monitored by the SDK.

    From version 3.7.0

    Sample

    A sample is available on Github: https://github.com/Accengage/accengage-android-sdk-samples/tree/master/AccGeofences 

    8.4 iBeacons

    Beacons are Bluetooth Low Energy  (BLE) devices that broadcast their identifier to nearby portable electronic devices using iBeacon protocol.

    The beacon technology enables you to deliver hyper-contextual content based on location, whether it is indoor or outdoor. These small bluetooth proximity sensors communicate with mobile devices to locate users from a few centimeters to a 30-meter radius.

    Before using the beacon service, make sure that all of your beacon devices share the same UUID.

    Note

    Only iBeacon devices are supported. The library doesn't support Eddystone.


    To be able to listen beacons and trigger specific actions, like displaying an InApp message or scheduling Local Notifications, by detecting a programmed beacon you need to use Beacons plugin.

    Don't forget to add the Bluetooth permissions in your AndroidManifest, look at the section Permissions for more details.

    Retrieving Beacon information with a BroadcastReceiver

    Each time our SDK detects a beacon defined on the Accengage dashboard, your app may receive their specific information.

    Create a BroadcastReceiver

    To receive them, you should first create a BroadcastReceiver: 

    BeaconReceiver.java

    Modify your AndroidManifest.xml

    Now, we have to add our “BeaconReceiver” class to the AndroidManifest.xml in order to allow the SDK to trigger it when needed:

    AndroidManifest.xml

    Section 9 - Useful commands

    Welcome to the useful commands section

    Here, we suggest you some methods in order to quickly and efficiently perform certain actions within the SDK. 

     

    9.1 Restrict SDK connection

    You can temporarily restrict the connections in order to tell our SDK to stop flushing network requests.

    All requests will be locked until you use setRestrictedConnection(false). In order to know if the connection is restricted for our SDK, please use:


    9.2 Set a tracking mode

    If you need it, tracking can now be restricted in order to be compliant to the most severe privacy rules. This is not needed for most integrations

    Add the following string:

    strings.xml

    The default mode is “Normal” and you don't need this meta-data if you want to use Normal mode. But, if you want our SDK to be more respectful of the users privacy, you can set the value to “Restricted”

    Please note that if you use “Restricted” mode, some advanced targeting functionalities may not be available

    9.3 Set cache delay

    If you want the SDK network requests to be executed more or less often, you can set a custom delay for our cache system.

    Add the following string:

    Where 15 represents the delay in seconds before each execution of cached requests.

    9.4 Stopping the SDK

    If a user wants to opt-out from tracking, you can use this static method:

     

     

    Where "this" is any Android context like: Application, Activity, BroadcastReceiver...

    The "do not track" mode, while activated, will disable all SDK functionalities (tracking, push notification reception, in-app messages, notification statistics...).

    If you want to know whether the user is being tracked or not, use the following static function:

     

    9.5 Custom Credentials Integration

    If you need to provide programmatically partner Id and private Key to the SDK, you can implement our com.ad4screen.sdk.AccIdsContentProvider interface in your class and provide your credentials. Both getPartnerId() and getPrivateKey() must return values as fast as possible, so never do any long running operations in the methods.

    Usage

    Implement the AccIdsContentProvider interface:

    MyAccIdsContentProvider.java

    Don't forget to replace the strings shown above by your own Partner Id and Private Key

    Please note that if your provider returns null values, SDK will not start and will retry to get a partner id/private key by calling your provider every 10 sec

    Note that if your code is obfuscated, you have to add a proguard rule for this class : -keep class your.package.MyAccIdsContentProvider { *; }

    Add the provider tag to your AndroidManifest.xml file: 

    AndroidManifest.xml

    Remove strings acc_partner_id and acc_private_key from your strings.xml file.

    Warning

    Please don't forget to set android:multiprocess to false, because we need to create only one instance of AccIdsContentProvider, otherwise it will be created in two processes : in the app and the SDK. (Reminder that the SDK run in another process)

    Update credentials

    Two instances of your class implementing AccIdsContentProvider are created at the first access to the SDK by calling A4S.get() method. At the same time the SDK call getPartnerId() and getPrivateKey() to obtain credentials. These credentials will be used by the SDK until the application will not be restarted (killed and relaunched).

    To apply new values at runtime, for example, if you need to change a country with another partner ID and private key without restarting the app, you need to use A4S.get(context).reinitPartnerId(). The method will call getPartnerId() and getPrivateKey() of your class to obtain new credentials, and then reinitialize the SDK.

    9.6 FCM/GCM Sender IDs

    On the table below you can find different combinations of FCM/GCM plugins and Sender IDs:

    acc_sender_idacc_firebase_app_idplugin description

    -

    -- 
    --firebaseDefault FirebaseApp instance uses a Sender ID from google-services.json. A token will be sent to Accengage servers. The firebase plugin will listen messages from the FCM Sender ID.
    fcm:YOUR_SENDER_ID-firebaseDefault FirebaseApp instance uses a Sender ID from google-services.json and another Sender ID from strings.xml. A token of the Sender ID from strings.xml will be sent to Accengage servers. The firebase plugin will listen messages from 2 FCM Sender IDs.
    fcm:YOUR_SENDER_IDYOUR_APP_IDfirebaseDefault FirebaseApp instance uses a Sender ID from google-services.json and a new Accengage FirebaseApp instance uses another Sender ID from strings.xml. A token of the Sender ID from strings.xml will be sent to Accengage servers. The firebase plugin will listen messages from 2 FCM Sender IDs.
    gcm:YOUR_SENDER_ID-firebaseDefault FirebaseApp instance uses a Sender ID from google-services.json and another Sender ID from strings.xml. A token of the Sender ID from strings.xml will be sent to Accengage servers. The firebase plugin will listen messages from 2 Sender IDs (FCM and GCM).
    gcm:YOUR_SENDER_IDYOUR_APP_IDfirebaseDefault FirebaseApp instance uses a Sender ID from google-services.json and a new Accengage FirebaseApp instance uses another Sender ID from strings.xml. A token of the Sender ID from strings.xml will be sent to Accengage servers. The firebase plugin will listen messages from 2 Sender IDs (FCM and GCM).
    fcm:no_registration or gcm:no_registration-firebaseDefault FirebaseApp instance uses a Sender ID from google-services.json. A token will not be requested and sent to Accengage servers. The firebase plugin will still listen messages from the FCM Sender ID but you wont be able to send them via Accengage dashboard since the token wasn't obtained and sent to Accengage servers.
    gcm:YOUR_SENDER_ID-pushDefault GMS InstanceID uses a Sender ID from strings.xml. A token will be sent to Accengage servers. The SDK will listen messages from GCM Sender ID.
    gcm:no_registration-pushDefault GMS InstanceID doesn't uses a Sender ID from strings.xml. A token will not be sent to Accengage servers.

    9.7 Retrieving Message Parameters

    Broadcast Intents

    Via Accengage dashboard you can specify some additional parameters for Push, In-App or Inbox messages and retrieve them in the app by a BroadcastReceiver.

    The following table describes which broadcast intents contain message parameters:

     PushInAppInbox
    Intent Categorycom.ad4screen.sdk.intent.category.PUSH_NOTIFICATIONScom.ad4screen.sdk.intent.category.INAPP_NOTIFICATIONScom.ad4screen.sdk.intent.category.INBOX_NOTIFICATIONS
    Intent Actions
    • com.ad4screen.sdk.intent.action.DISPLAYED
    • com.ad4screen.sdk.intent.action.CLICKED
    • com.ad4screen.sdk.intent.action.CLOSED
    • com.ad4screen.sdk.intent.action.DISPLAYED
    • com.ad4screen.sdk.intent.action.CLICKED
    • com.ad4screen.sdk.intent.action.CLOSED
    • com.ad4screen.sdk.intent.action.DISPLAYED
    • com.ad4screen.sdk.intent.action.CLICKED
    Parameters
    • Custom Parameters (sent with the action DISPLAYED and CLICKED)

     

    • Display Parameters (sent with the action DISPLAYED)
    • Click Parameters (sent with the action CLICKED)
    • Custom Parameters (sent with the action DISPLAYED and CLICKED)
    Screenshot

    InApp

    BroadcastReceiver Example

     To receive Accengage broadcast intents, add a BroadcastReceiver to your project:

    AndroidManifest.xml

    and retrieve your display/click parameters

     

    The url1 is the key of the custom parameter you set in the dashboard, where customParam1 contains its value. 

    Retrieving In-App Custom Parameters from callbacks

    For In-App messages (Banners and Interstitials) you can also retrieve custom parameters from In-App state callbacks. The following example shows how to retrieve custom display and click parameters from Inflated callback:

    You can in the same way retrieve the custom parameters from other InApp states as follow : 

    This way you're able to access your custom param at every single step of your In-App state callbacks, providing you with a great flexibility.

    Push

    BroadcastReceiver Example

     To receive Accengage broadcast push intents, add a BroadcastReceiver to your project just like you would do for an InApp:

    AndroidManifest.xml

    and retrieve your message parameters when the push is opened

    Push Handler

    The cp1 is the key of the custom parameter you set by the dashboard, where customParam1 contains its value. 

    Get Message Parameters from Activity

    You also can retrieve your message parameters from your activity

    Push Handler

    Intercept the push

    You can also retrieve your Custom Parameters directly from the Push itself when it's received by the app

    First of all you should intercept the GCM push using a custom "GCMHandler".

    Then you can add a method to get the intent and receive the custom params

    processPush


    9.8 Removing the control panel for Rich Push

    To remove the controls (back, forward, reload and open with browser) of the WebView Activity, you need to create a custom layout based on the default one but without the control panel com_ad4screen_sdk_buttonbar. Then on the page editing a push notification you must specify the name of the new layout in the custom parameters.

    Below there is an example of the template without the control panel.

    my_richpush_without_controls.xml
    1. Add this layout in your Android Studio project 
    2. Specify its name without the file extension .xml on the Settings page in section the RICHPUSH TEMPLATE
    3.  Then chose the name of the template on the page editing a notification

    9.9 Request Manager Behaviour

    Task Flushing Delays

    Why ?

    In case of an error in sending any request to the APIs, the request will not be lost. Instead it will be saved and we will keep on trying to send it later on to make sure that none of your data is ever lost. The reason is in the event of a problem within the app preventing the request to be successfuly sent. Since we keep on sending the request over and over again, there is a risk of flooding our servers. Therefore we setted up a system that will keep sending the requests at a more reasonnable rate as well as keep making sure your data is safe an never lost.

    How ?

    When the request returns an error, we will stock in on our side and try again in 10 seconds by default. In case the next request fails again, we double this delay meaning we will try sending again in 20 seconds and so forth until we reach 320 seconds or until the request is a success. Please have a look at this pseudo code scheme :

    You now understand why in your app's logs you can sometimes find this : 

    Delays Logs

    9.10 JavaScript and WebView

    Accengage webview A4SWebView  contains JavaScript interface to be able to handle calls on JavaScript from web pages.  Below there are methods of JavaScript A4S object which you can use to:

    A4S Javascript Methods

    A4S.trackLead(data)

    Tracks a lead event. The  data  is json containing the lead information. For example:

    A4S.trackAddToCart(data)

    Tracks a cart event. The data is json containing the cart information. For example:

    A4S.trackPurchase(data)

    Tracks a purchase. The data is json containing the purchase information. For example:

    A4S.trackEvent(eventId, data)

    Tracks an event (lead, cart, purchase or custom event). The eventId is an ID of the event (10 - Lead, 30 - Cart, 50 - Purchase, etc) and the data is either json for lead, cart, purchase or value for custom event.

    A4S.setView(view)

    Sets a view for the page you would like to target. The view is a view name value.

    A4S.updateDeviceInfo(data)

    Updates Device Information. The data is json containing fields and it's values to update. For example:

    Javascript Injection

    When an A4SWebview is started, it will automatically run a javascript file added by Accengage as soon as the page is fully loaded. You can replace this script by your own. For this, set your js URL in ad4_webview_script_url parameter:

    strings.xml

    Custom WebviewClient

    If you want to modify a behaviour of A4SWebview methods, you may use your own WebviewClient :

    Close WebView from WebView's content

    You can close the WebView with a specific URL inside the WebView. First, you need to manage the close action.

    Next, in your HTML content, add the  bma4sclose  key in the closing URL, for example: http://www.google.com?bma4close=true

    JavaScript Sample

    For quick tests of A4S methods, check out our simple project on node.js rendering an html page with JavaScript code:

    To start the webservice call:

    9.11 Crash Monitoring

    In order to enhance and monitor its quality of service, Accengage has implemented a feature to detect app crashes and quantify any suspicious surge. The goal is for our support to be very reactive in case of any issue affecting our SDKs.

    Accengage provides a way to disable this feature if you do not want Accengage to be notified. You need to add additional line to your strings.xml file to disable the crash monitoring by Accengage:

    strings.xml

    Workaround for version 3.6.4

    If you are using the version 3.6.4 of the SDK (in which the feature was first introduced), we strongly recommend to add a few lines in your AndroidManifest.xml, which will prevent some rare conflicts which may occur.

    AndroidManifest.xml

    Otherwise, you can update directly to version 3.6.4.1 of the SDK, which fixes this rare issue.

    Section 10 - Troubleshooting

    10.1 Check the SDK logs using our ACC info app

    Our Acc info app can be used to check our SDK logs and find your device ID.

    This article explain how to download this app, connect it to your application and find your device ID.

    We offer the possibility to activate our SDK logs. Two levels of logs are available. Once activated, you can click on the 'LOGS' button in order to activate the logs tracking.

    In order to see the logs directly on a Desktop, you can type the URL

     

    Desktop logs : 

     

    From the app, you can press the 'SEND' button to automatically send us the logs file within a mail : 

    10.2 DeviceInfo doesn't contain IDFV

    You are facing to those logs repeating again and again ?

    This issue can be due to the use of the annotation @UseA4S. Indeed, we noticed that this plugin may not work with the new Android compiler versions.

    This feature will be removed in the further versions of the SDK. Please, use a manual integration instead of the annotation pluging integration.

    10.3 Disable Badges (3.5.0+)

    If you want to disable Badges feature (because too many permissions are asked for example), exclude our Badge plugin from the Accengage SDK dependency:

    10.4 Find your A4SID (or Device ID or Mobinaute ID)

    If you need to get the Accengage Device ID (or "Mobinaute Id") of the user, use the following method:

    10.5 Fullscreen Activity with notification and navigation bar

    Your InApp appears under your notification bar and your navigation bar ? Here are two solutions :

    1°) You can use the InApp display customization to include your inapp into a specific view in your layout.

    2°) You can use our method A4S.setOverlayPosition(layoutParams) to add margin to the inapp like that :

     

    10.6 How to avoid a double splashscreen display with a rich push?

    Sometimes it happens that a double splashscreen is launched during the sending of a rich push parameters with an URL Scheme as a deeplink.

    Please find here the technical solution to solve this point : 

    • The URL Schemes (intent-filter) are manage by your SplahScreen
    • The SplashScreen integrate the SDK
    • Lock only the in-apps display on your SplashScreen (in the method onCreate) : getA4S().setInAppDisplayLocked(true);
    • Your SplashScreen needs to detect that he is launched by a push Accengage and in this case : DO NOT effectuate action (even close it)

    In the method onResume(), you can use this code for instance :
    Bundle bundle = getIntent().getExtras();
    //

    • We recover the Payload in case if you would treat custom params at this level.

    Bundle payload = bundle.getBundle(Constants.EXTRA_GCM_PAYLOAD);
    if(payload == null) {
    }
    getA4S().startActivity(this);

    • Your SplashScreen has to be in lauchMode singleTask or singleTop to do not launch it again during the launching of the URL Scheme by the SDK.
    • Unlock in-apps messages on the destination activity.

    If this answer do not solve your problematic, do not hesitate to contact us via our form.

    10.7 How to find Sender ID and API Key for FCM/GCM?

    Add Firebase Server key and Sender ID to Accengage dashboard

    Accengage servers need Server API key and Sender ID of your FCM/GCM project to send push notifications.

    Find GCM Sender ID

    Find GCM Server key

    10.8 How to find the SDK version you're using?

    There are two main ways to find the sdk version you're using and the first one is programmatically. You can access the static variable "SDK_VERSION" in the Constants Class like this:

     

    The second way is to find the version directly inside the Logs of the app. To do so, make sure that you activated them, launch your app and read the logs.

    The very first line will look like this:

    Of course, "A3.1.2" is an example and the value you will get here is the version number of the SDK you integrated

    10.9 How to incorporate Accengage with others CRM tools?

    If you use several CRM tools (and the GCM recording is already done several times), this could explain why some devices do not receive push messages.

    Indeed, a conflict can happen when it comes to the recording and the token recovered by the SDK could be invalid.

    To resolve this problem, you can :

    • Leave our SDK records to GCM and no longer do it yourself 

    or

    • Send us the token after the recording from GCM 

    Regarding the second issue, please find the process below :

    It is necessary to remove the following metadata in the Manifest : 

    <meta-data android:name="com.ad4screen.senderid" android:value="gcm:yoursenderid" />

    Thus, the SDK won't be recorded automatically to GCM.

    In this case, you have to record the application yourself to GCM and give us the token through this method :

    sendGCMToken: http://wiki.accengage.com/android/javadoc/reference/com/ad4screen/sdk/A4S.html#sendGCMToken(java.lang.String)

    10.10 How to make a deeplink for a path in a mapping application?

    If you want to use a deeplink referring to a pre-selected path in a mapping application, here are the different URL to use:

    - Google maps:

    • Address: google.navigation:q=31+rue+du+quatre+septembre,+Paris
    • GPS cordinates: google.navigation:q=latitude,longitude

    You will have to choose the action URL scheme for in-app or browser for push.

    Note that when you use spaces in your URL, you have to replace them by "+".

    10.11 How to manage the icon display into a push notification?

    On Android, there are several ways to select the icon for a push notification. 

    First of all, there are three types of icons on Android with Accengage:

    1. The first one is the default "ic_launcher" icon.

    This icon is defined at the beginning of the app creation. 

    The logic is that the default icon is sent into a push notification, from Android 2.3 to 5.1.

    However, from Android 4.4, Google has changed its criteria for the icon.

    Indeed, the OS implements a filter (white color) on the icon.

    The problem that you can encounter is that the icon has no transparency, which means that when a notification appears, the icon is not displayed. (cf. below)

     

    2. In order to get around this change from Android 4.4, you have to make a change into your Android Manifest.

    The icon has to be with white color and transparency.

    Please have a look to our documentation: Android Manifest changes

    After that, when you send a push:
    --> users under Android 4.4 will receive the icon number 1
    --> users above 4.4 will receive the second icon

    3. The third one is the icon that you could add in a push message on the dashboard.

     

     

    Finally, the third point will be taking in priority even if the first and the second point are integrated.

    10.12 How to recover your Device ID (IDFV) on Android?

    The Device Id is our unique identifier, it allows you to identify for sure the Accengage device profile that represent your own device. For test segments it is recommended to use this data as criterion. It is also necessary to get your device information from our Test Tools.

    You will find below the methodology in order to recover your Device ID (A4SID) on Android :

    • Download the A4SID application on your Android device using the link below or using our QR Code: 

    http://wiki.accengage.com/android/downloads/A4SID.apk

    • Make sure your app has been opened at least one time.
    • Open the A4SID application and check your deviceID.

     

    Here is an example for the creation of your test segment

     

    10.13 How to use the geolocation minimizing battery consumption?

    When the geolocation is active on the application and on the SDK, the SDK will constantly use the GPS which will need battery.

    To avoid this, you can desactivate the automatic geolocation and activate the "manually mode" only when you wish.

    For further information, do not hesitate to consult our documentation : 

    Documentation Accengage - Geolocation

    10.14 How to visualize network requests from Accengage SDK ?

    Since SDK 3.1.8 and 3.2.2, we added tags to network requests to be able to visualize them through DDMS Network Statistics, for example :

    The Accengage SDK uses the 0x00413453 tag.

     

    10.15 Import Android token history requirements

    If you already used to send push notifications before integrating the Accengage SDK, you may want to import the history of push tokens in order to reach your existing app owners with Accengage messages even if they did not update/open the app having our SDK integrated yet.

    In order to make sure your token base will be compatible with our solution, it's important to check the following points :

    1- Continuity of your Sender ID

    On Android, the push token (mandatory information to deliver a push notification on Android devices) is linked to the Sender ID & the Google API Key of your Project. It's also unique to a device. Changing your Sender ID means that the previous tokens will no longer be valid. In that case, if the user re-open the app a new token will get generated.

    In order to make sure that your app owners will not get a new token generated after integrating the Accengage SDK, you need to check if your previous push solution manages the Sender ID itself. It can happen that if you stop using this solution you may need to generate a new Sender ID. If it's the case, Import your Token base is useless because these won't be valid once the user update their apps and there will be no possible matching with the Accengage device profiles.

    2- Push notifications display

    On Android, it is the app itself that manages the push notification display. This is why each solution will use its own parameter in the push notification payload that will be handled by the app and manage the push notification on the user device.

    If you create and send push notifications from the Accengage dashboard, this is the Accengage payload that will be sent on the device. It will automatically manage the push display for the apps that have been updated with our SDK, but for the other devices you will need to ensure that the previous notification handler will also understand and read the payload.

    Depending on how your push notifications were managed previously, it may be possible to attach Custom parameters that would reflect the expected push parameters of your previous provider. This would ensure the display of the notification for all your app owners.

    In order to check this compatibility, please request the full push notification payload of your previous solution and send it to us. Note that it can also be tracked using the Android Studio logs. Once you have the payload, you can send it to your Accengage contact or our technical support and we will get back to with our feedback.

    10.16 I do not receive push notifications. What could be the causes?

    If you do not receive push notifications or if the sending summary show 0 push sent, it is important to verify several points which can help you to understand and solve quickly the point on your side.

    1. Ensure that your segment and an up-to-date device ID

    Regarding the segment, it is possible that the added criteria have not been saved. In this case, the segment is empty because he doesn't content criteria. Using it as a sending target is comparative as sending the push to 0 user. When you create a segment, it is necessary to click first on "add criterion" and then "save segment".

    If your segment is correctly complete, you need to verify that it include your correct IDFV.

    You can check this by looking at the last open date (see below). If it is not the right one, you have to update your device ID.


    This is how you can recover your device ID:
    Android : How to recover your device ID?

    2. Check that you have valid device profile in your segment and which is the one linked to a token and have a feedback counter lower than 3. The current system optin status is also visible in the 'system optin notif' field.

    Check your profile on the Accengage platform via Test Tools

    3. Check the uploaded GCM/FCM Key in the platform.

    The key has to be set up as "server key" and should have no IP filters. 

    Here is our guide to check your Google API Key.

    4. Check your connection and test with several wifi networks and in 3G/4G. We also notice that wome Corporate Wifi have restrictions that can affect the push reception.

    5. Check your sending summary

    You can check that our service has successfully sent the message to Google's servers directly from the message (see below).


    If the sending summary is equal to zero, please check points 1 and 2 (device ID & Token).
    If the sending summary is not equal to zero, the message has been successfully sent. Please check point 4 and 5. If the certificate status is not rejected, it means that the key is not well set up or is not equal to the right sender ID. 

    6. Check the App credentials status

    If it shown wrong or missing credentials, please check your API Key & Sender Id.

    7. Check the marketing pressure

    If you send your final push notifications none of them are received, please check the marketing pressure. 

     

    In some cases, the quota for push notifications might have been reached, which would explain why you do not receive the push notification.

    8. Check the push configuration

    If you do not receive a push notification, check the configuration of your push message. Be careful to make sure, if you’re in the open application, to “show the notification”.

    10.17 My push action does not work. What could be the causes?

    On Android, it could happen that the push action does not work when you send a push either when the app is killed, or when the app is in the background or in the foreground.

    In order to understand why it happens, it is necessary to first understand our SDK functioning when we receive a push.

    In each Activity (view or app page), three methods are integrated and called:

    - The startActivity (in the onResume) : Allows to handle the Activity intent with the notification params.

    - The setIntent (in the onNewIntent) : Allows to indicate to the SDK that a screen, which was already launched, is launched again through a notification.

    - The stopActivity (in the onPause) : Allows to indicate to the SDK that we leave the Activity (not used for the notification management).

    • Please find below the possible explanations if the push action does not work when the app is killed:

    1. The SDK is not integrated into the SplashScreen.

    In this case, please find the scenario which could happen:

    - You send a push with a rich push (webview, browser or URL schemes),

    - You click on the push,

    - You arrive on the SplashScreen

    - You arrive on the HomePage,

    - No action is done, so you stay on the HomePage.

    If there is no action, the SDK could be not integrated into the SplashScreen. For Android, it is necessary that for each Activity, the SDK is launched. If the SDK is not launched into the SplashScreen, the push information could not be handled by the SDK.

    2. There is no lock on the SplashScreen.

    In this case, please find the scenario which could happen:

    - You send a push with a rich push (webview, browser or URL schemes),

    - You click on the push,

    - You arrive on the SplashScreen,

    - You arrive on the HomePage,

    - No action is done, so you stay on the HomePage.

    - When you click on "Back", you arrive on the attended page.

     

    In this specific case, this is what happens with the system and the SDK:

    - The information are handled on the onResume: the action is well executed,

    - The SplashScreen loading ends in the background and launches the action towards the HomePage.

    As there is no lock on the SplashScreen, the HomePage is launched directly after the action. This is why, the HomePage is over the action page.

    It is necessary that a lock is set up on the SplashScreen in order to trigger the action only when you arrive on the main page of the app. 

    3. The redirection towards the HomePage is executed too soon.

    In this case, please find the scenario which could happen:

    - You send a push with a rich push (webview, browser or URL schemes),

    - You click on the push,

    - You arrive on the SplashScreen,

    - You arrive on the HomePage,

    - No action is done, so you stay on the HomePage.

     

    In this case, the explanation is simple:

    - The redirection towards the HomePage is triggered on the onCreate method, thereby, the push information do not have time to be handled by the SDK (through the onResume StartActivity). In this case, the push information are lost.

    This is why, no action is executed.

    • Please find below the possible explanations if the push action does not work when the app is in the background or in the foreground:

    1. A push lock is activated on the actual page. 

    In this case, please find the scenario which could happen:

    - You send a push with a rich push (webview, browser or URL schemes),

    - You receive the push,

    - You click on the push,

    - No action is done, so you stay on the actual page.

    If a push lock is activated on the actual page, it will block the push execution until we arrive on an unlock page. 

    It is necessary to verify that no push lock is activated on the actual page. 

    2. The SDK is not integrated in the actual page.

    In this case, please find the scenario which could happen:

    - You send a push with a rich push (webview, browser or URL schemes),

    - You receive the push,

    - You click on the push,

    - No action is done, so you stay on the actual page.

     

    Like the action push when the app is killed, if the SDK is not integrated on an Activity, the push action will never be handled by our SDK because the information will be lost.

    3. The SetIntent method is not integrated. 

    In this case, please find the scenario which could happen:

    - You send a push with a rich push,

    - You receive the push,

    - You click on the push,

    - No action is done, so you stay on the actual page.

     

    What happens in this case, is that the SetIntent method is not integrated on the onNewIntent, thereby, the push information are not handled by our SDK.

    This is why, the push is well received but the push action is not executed. 

    To avoid that, it is necessary to verify that the SetIntent method is well integrated on the onNewIntent.

    10.18 Which ratio you need to use with the BigPicture template?

    If you are using BigPicture for your push notifications, we advice you to choose a ratio of 2 (width) X 1 (height).

    It correspond to an average height. Each device could have different dimensions.

    But, the ratio 2 is the adviced ratio to have a correct display on a large sample of devices.

    The image would be reduce only on the height. That's why it is advice to center the information on the image.

    Do not forget : more the push content text ligns more the image will be reduce.

    10.19 SplashScreen

    Please note that the Accengage SDK must be integrated in the SplashScreen like other Activities.

    The Activity after the Splash Screen have to be launch after the A4S.startActivity() to be able to process the Push Action. For exemple, you cannot redirect directly in the onCreate() method.

    You also have to use setPushNotificationLocked(true) and setInAppDisplayLocked(true) in the OnCreate() method of your SplashScreen and use setPushNotificationLocked(false) et setInAppDisplayLocked(false) on your next Activity.

    Some RichPush issues are du to mistakes in the SplashScreen

     If you have some trouble with your SplashScreen or your RichPush, please take a look at this documentation: https://accengage.freshdesk.com/fr/support/solutions/articles/19000022600-android-l-action-de-mon-push-ne-fonctionne-pas

    10.20 Activate logs

    Something doesn't work? You can enable logging in order to see what is going on.

    To do so, simply add the following string:

    strings.xml

    Plus, you can disable the toast displayed when application is started (because of UI Automation for example):

    strings.xml

    10.21 Crash because of Kotlin dependences

    If you are facing this Exception, that's means you haven't add yet the kotlin dependences in your project. 

     

    To do so, we recommend you to proceed as below :

    Add the SDK to your app

    build.gradle (project)
    build.gradle (app)

    As the SDK contains some Kotlin classes, you must configure Kotlin in your project to avoid SDK Service crashes by adding the kotlin dependences below in your project build.gradle and your app build.gradle.

    You also can add Kotlin to you project with Android Studio by selecting Tools | Kotlin | Configure Kotlin in Project from the main menu.

     

     

    • No labels