digia_webengage_plugin 2.0.0
digia_webengage_plugin: ^2.0.0 copied to clipboard
Digia Engage CEP plugin for WebEngage — bridges WebEngage in-app campaigns into Digia's rendering engine.
Changelog #
2.0.0 - 2026-10-08 #
New Features #
- Campaigns held until Digia is ready — in-app campaigns that WebEngage delivers after the plugin is attached but before Digia has finished initializing are now held, one copy per experiment, and delivered once Digia is ready. A campaign that Digia answers with "not ready" is held again rather than lost. If initialization fails or the plugin is detached, held campaigns are discarded and WebEngage's in-app queue is released.
- Variables in the campaign's custom data — campaign variables can now be authored as a top-level
variablesobject, or the olderargsobject, alongside the campaign key. The object may arrive already parsed or as JSON text, which WebEngage's string-only custom fields require. Values with no plain-text form (lists, nested objects, empty strings) are omitted. Campaigns that carry their key and variables in a<template id="digia-config">block keep working as before.
Improvements #
- Native WebEngage SDK versions pinned — the plugin now depends on exactly WebEngage Android SDK 5.1.2 and WebEngage iOS SDK 7.1.0. It previously accepted any Android SDK from 4.0 and any iOS SDK from 6.10.0.
- WebEngage App In-line (Personalization) support removed — the plugin no longer handles App In-line campaigns and no longer depends on
we_personalization_flutter; apps that use that package directly must now declare it as a dependency themselves.registerPlaceholderandderegisterPlaceholderare deprecated and do nothing (registerPlaceholderreturns null). - Less reliance on WebEngage's private iOS APIs — every call into WebEngage's private iOS APIs is now guarded, so a renamed or missing symbol skips the call instead of crashing the host app. The plugin also no longer writes to WebEngage's private session-close record when a campaign closes.
- Diagnostics through Digia's logger — plugin logs are now written through Digia's own logger, tagged
[DIGIA-WE], and narrate the plugin's lifecycle: attach, campaign received, impression, click and close marked, WebEngage-initiated dismissal, and detach. Lines use the same wording as the other CEP plugins. - Documentation — the README now documents the required iOS setup step of passing a
DigiaDelegateProxyas WebEngage's in-app notification delegate, and links to an architecture guide covering the data flow and the WebEngage-specific behavior of the plugin.
Bug Fixes #
- A campaign is no longer blocked for the rest of the session — a campaign that Digia showed and the user closed, or that Digia declined, no longer stays blocked from being delivered again for the rest of the session. The plugin's duplicate-delivery gate is now released on every path, one second after the campaign's hold is released.
- Stuck WebEngage in-app queue on Android — later WebEngage in-app campaigns are no longer parked behind a Digia campaign that is delivered twice, arrives before the plugin is attached, or carries a payload the plugin cannot use. WebEngage's in-app render lock is now released in each case.
notification_closeonly for real dismissals — a campaign that Digia declines or never displays (frequency-capped, unknown key, invalid configuration) no longer sendsnotification_closeto WebEngage. The close event is now sent only when the user dismissed the campaign, so WebEngage's close counts no longer include campaigns the user never saw.- Host app's Personalization callback is no longer replaced — the plugin no longer registers its own WebEngage Personalization callback, so a callback the host app registers for itself is not replaced when the plugin attaches or overwritten with an empty one when it detaches.
- In-app lost on iOS screen change — a WebEngage in-app that is being prepared when the user navigates is no longer dropped. On iOS, the screen-change report now waits, for up to about a second, for the in-flight in-app to be handed to Digia.