Skip to main content

Altcraft mSDK features

The mobile SDK v.1 is implemented on Firebase for the Android platform and on Firebase and APNs for the iOS platform. Below you can familiarize yourself with the features the SDK has to date.

info

It is the responsibility of the developer to use the provided mobile SDK in the target application. We do not make any guarantees about the successful implementation of the SDK into your technological scheme. However, if you have any questions about its configuration please contact the platform's technical support. Also note the following restrictions::

*The SDK currently supports working with only one resource in the platform. Use scenarios if you need to subscribe to other resources.

  • Profiles imported into the platform via push notifications will be added to all databases related to that resource.

  • Access to matching when importing profiles is limited, only search mode by push subscription ID is available. You can read more about matching modes here.

  • There is no option to change the push message format when using the SDK, to use the full push functionality you will need to use the Silent Push format supported by the platform for notifications.

Translated with DeepL.com (free version)

Android SDK (Firebase)​

  • **Subscribe the user to Altcraft push notifications.**When the SDK is integrated and initialized, the Firebase Cloud Messaging device token will be transferred to the platform server and a subscriber profile will be created for further push notifications.

  • Support for text, images and buttons in notifications. Push notifications support text, images and buttons, for which you can set a push action (follow a URL link, deepLink or open an app).

  • Actualization of tokens on the device. SDK queries the current token from Firebase Cloud Messaging during app launch, push notification receipt, and checks it every 2 weeks via a periodic background task. This avoids Firebase token obsolescence (as recommended by Google).

  • Update tokens on Altcraft server. In case of FCM token changes, SDK performs token update on the platform server. This ensures that the token is up to date.

  • Registration of events. Events of notification receipt on the device and click on it (hubLink events) are registered by SDK, and their data are transmitted to the server and form statistics of push notification delivery and opening.

  • Repeat requests. SDK automatically repeats failed subscription requests, token updates, and hubLink events. In the case of an unsuccessful request, the data to fulfill the request is stored in the database and the request is repeated. The execution is repeated as follows:

    • Immediately after a failure, several repeated requests are executed at increasing time intervals using the system function of the ListenableWorker class (this class is used to execute subscription, update, and hubLink requests). If the system withdraws the internet connection from the application, e.g. after a shutdown, the request will be executed again as soon as the connection is granted.
    • Repeat using periodic tasks of the WorkManager class with a minimum interval of 3 hours between checks for failed requests (assuming internet connection is available).
    • Repeat while receiving a push notification with high priority. Even if the application is unloaded from memory, receiving a push notification will “wake up” the application and provide internet access to perform a retry of failed requests.
    • Rerun during application startup. Each time the application is launched, a check is performed to see if there are any failed queries in the database.

  • Working in background. If permission is granted to use front-end services, a subscription or token update request will continue to be executed even after exiting the application or going to background. These requests will take 1 minute to complete. This significantly increases the probability of successful request execution in case the user exits the application before its completion. However, it should be taken into account that, according to Android system requirements, while the foreground services are running, a message will be displayed in the notification panel that the application is still running.

  • Notification processing. SDK provides the ability to process the message and read push notification data in the app.

  • API events. The platform provides an API to receive SDK events in the application.

IOS SDK (APNs)​

  • Subscribe the user to Altcraft push notifications. Once the SDK is integrated and initialized, the APNs device token will be transferred to the platform server and a subscriber profile will be created to further send push notifications.

  • Support for text, images and buttons in notifications. Push notifications support text, images and buttons, for which you can set a push action (follow a URL link, deepLink or open an app).

  • Update tokens on Altcraft server. SDK performs automatic control of changing APNs-token of the device. If it changes, SDK will update the token on the platform server. This ensures that the token is up to date.

  • Registration of events. Events of notification receipt on the device and click on it (hubLink events) are registered by SDK, and their data are transmitted to the server and form statistics of push notifications delivery and opening.

  • Repeat Requests. SDK automatically repeats failed subscription requests, token updates, and hubLink events. In the case of an unsuccessful request, the data to fulfill the request is stored in the database and the request is repeated. The execution is repeated as follows:

    • Immediately after a failure, several repeated requests are executed at increasing time intervals using the functions of the SDK.
    • Repeat with tasks logged using the system framework BGTask, with a minimum interval of 3 hours between checks for failed requests (if the application is minimized).
    • Repeat at the time of receiving a push notification. Even if the application is unloaded from memory, receiving a push notification will “wake up” the application and provide access to the internet to perform a retry of failed requests.
    • Rerun during application launch. Each time the application is launched, a check is performed to see if there are any failed queries in the database.

  • Working in background. SDK supports the ability to terminate subscription and token update requests after transitioning to background (minimized state) for 29 seconds. This significantly increases the probability of successful execution of requests if the user exits the application before the request is completed.   

  • Notification processing. SDK provides the ability to process the message and read push notification data in the application.

  • API events. The platform provides an API to receive SDK events in the application.

IOS SDK (Firebase)​

  • Subscribe user to Altcraft push notifications. After SDK integration and initialization, the Firebase Cloud Messaging device token will be transferred to the platform server and a subscriber profile will be created to further send push notifications.

  • Support for text, images and buttons in notifications. Push notifications support text, images and buttons, for which you can set a push action (follow a URL link, deepLink or open an app).

  • Actualization of tokens on the device. SDK queries the current token from Firebase Cloud Messaging when the app is launched and a push notification is received. This avoids Firebase token obsolescence (as recommended by Google).

  • Update tokens on Altcraft server. In case of FCM token changes, SDK performs token update on the platform server. This ensures that the token is up to date.

  • Registration of events. Events of notification receipt on the device and click on it (hubLink events) are registered by SDK, and their data are transmitted to the server and form statistics of push notification delivery and opening.

  • Repeat Requests. SDK automatically repeats failed subscription requests, token updates, and hubLink events. In the case of an unsuccessful request, the data to fulfill the request is stored in the database and the request is repeated. The execution is repeated as follows:

    • Immediately after a failure, several repeated requests are executed at increasing time intervals using the functions of the SDK.
    • Repeat with tasks logged using the system framework BGTask, with a minimum interval of 3 hours between checks for failed requests (if the application is minimized).
    • Repeat at the time of receiving a push notification. Even if the application is unloaded from memory, receiving a push notification will “wake up” the application and provide access to the internet to perform a retry of failed requests.
    • Rerun during application launch. Each time the application is launched, a check is performed to see if there are any failed queries in the database.

  • Working in background. SDK supports the ability to terminate subscription and token update requests after transitioning to background (minimized state) for 29 seconds. This significantly increases the probability of successful execution of requests if the user exits the application before the request is completed.   

  • Notification processing. SDK provides the ability to process the message and read push notification data in the application.

  • API events. The platform provides an API to receive SDK events in the application.

Last updated on