`Almedia` — Events - Almedia Launchpad

All events are static. Subscribe before calling Initialize if you want to observe every change. Components that mount later can recover the current state by reading Status and then subscribing to OnStatusChanged for further changes. All events fire on the Unity main thread, so handlers can touch any Unity API (UI, GetComponent, transform, scene loading) directly. See Threading in the integration guide for the underlying mechanism. A handler that throws is reported through OnLog at Error. It does not stop the other subscribers or later SDK callbacks.

`static event Action<AlmediaStatus> OnStatusChanged`

Fires with the new status whenever Status changes. Status already holds the new value. The first emission after Initialize carries the first resolved status: Eligible, Linked, NotAvailable, Blocked or Disabled. Later emissions report every change:

What changed in the native update	`OnStatusChanged`
The status	fires
`CanShowRewardHub` or `CanShowOffer`, while the player stays linked	fires
The reason of `NotAvailable`	fires, unless both the old and the new reason read `Unknown`
Nothing (identical payload)	-

It also fires with NotInitialized when Initialize runs with a different configuration after the status had resolved. Use it both for one-shot setup that should happen once the SDK has resolved (skip NotInitialized and use your own guard flag) and for live UI that mirrors the current status. StartLinking, FetchNotifications, and StartNotificationPolling called before the first status are safe no-ops (a warning is logged), so a mistimed call is harmless rather than a crash.

`static event Action<string> OnLinkCompleted`

Fires when the player completes account linking flow. The argument is an ISO-8601 timestamp string from the backend, e.g. "2026-05-13T14:23:01Z". Does not fire for players who were already linked at Initialize time - they receive a Linked status via OnStatusChanged instead. Use this event when you need to distinguish a fresh link from an already-linked session (e.g. celebration UX, one-time analytics).

`static event Action<List<AlmediaNotification>> OnNotificationsReceived`

Fires when a polling tick or FetchNotifications() returns one or more notifications. Empty results do not fire the event. Notifications are delivered in arrival order (oldest first).

`static event Action<AlmediaInGameRewardGrant> OnInGameRewardGrantRequested`

Fires when the backend instructs the game to grant in-game rewards. Credit the player and celebrate here. One event per grant. A grant is a bundle of one or more rewards granted together (AlmediaInGameRewardGrant.Rewards): “250 gems and 3 spins for finishing the chapter” arrives as one event with one id and deserves one celebration. Three separate grants arriving in the same polling tick raise three events. Delivery is at-least-once. The same grant can arrive more than once. The server-to-server reward postback remains the authoritative record of what was granted; treat this event as the real-time convenience, not the ledger. Each grant has a unique Id that a redelivery repeats, so deduplicate on it when a repeat credit matters to your economy. A short memory of recent ids suffices:

private readonly HashSet<string> _credited = new HashSet<string>();

Almedia.OnInGameRewardGrantRequested += grant =>
{
    if (!_credited.Add(grant.Id)) return;   // redelivered; already credited
    foreach (var reward in grant.Rewards)
        Wallet.Credit(reward.Code, reward.Amount);
};

`static event Action<AlmediaProgress> OnProgressUpdated`

Fires when Progress changes. The argument is the new snapshot, or null when the native SDK cleared the snapshot with its message stream token. The accessor already holds the new value. A handler can read the argument or the accessor. Hide the progress UI on null. The SDK applies only a strictly newer snapshot. The new snapshot replaces the previous one completely. This includes Username: a newer snapshot without a username clears the previous username.

`static event Action<AlmediaTaskCompletion> OnTaskCompleted`

Fires when the server reports a completed task. The argument carries the message id and the completion, with the reward the completion paid. See AlmediaTaskCompletion. The event is historical and best-effort. The task is not always in the current snapshot. The event does not update the snapshot. The same completion can arrive more than once, also after the SDK resets its stream token. The server never reuses an Id. Deduplicate on it:

private readonly HashSet<string> _seen = new HashSet<string>();

Almedia.OnTaskCompleted += completion =>
{
    if (!_seen.Add(completion.Id)) return;   // replayed; already celebrated
    Celebrate(completion.Task.Task.Title, completion.Task.ActualReward);
};

`static event Action<AlmediaBalanceChange> OnBalanceChanged`

Fires when the server reports a balance change. The argument carries the balance after the change and the signed change. See AlmediaBalanceChange. The change is negative for a reversal. The event is historical and best-effort, like OnTaskCompleted. The balance can differ from the current snapshot. The event does not update the snapshot. A replay carries the same Id.

`static event Action<AlmediaError> OnErrorOccurred`

Fires for both synchronous (local validation) and asynchronous (native, network) errors. See AlmediaErrorCode for the full set. Connectivity loss in work the SDK runs on its own - notification polling, event delivery, status refreshes, a FetchNotifications that finds no network - does not fire it. Those are logged at Warning through OnLog and retried by the SDK. A 4xx response, an undecodable response, or a failure of work the game asked for still does.

`static event Action<AlmediaScreen> OnScreenPresented`

Fires when an SDK screen (AlmediaScreen: the linking webview, the reward hub, or an offer) is now on top of the game - pause gameplay here. It fires at the moment the native container commits to presenting, before the page loads, so a slow network cannot delay the pause. The event fires for every trigger that actually presents a screen: the API methods (StartLinking, ShowRewardHub, ShowOffer), and the LinkPopup’s CTA after the LinkButton prefab or ShowLink() opened it. The popup itself is not an SDK screen and fires neither event. Matched-pair guarantee. Every screen that appears produces exactly one OnScreenPresented and, later, exactly one matching OnScreenDismissed:

Scenario	`OnScreenPresented`	`OnScreenDismissed`
A screen actually appears	exactly one	exactly one (later, matching)
Call opens nothing (wrong state, missing URL, a screen already open)	never	never
System-browser linking (web-browser strategy)	never	never - only the link callbacks fire

`static event Action<AlmediaScreen, AlmediaInAppScreenResult> OnScreenDismissed`

Fires when the screen reported by OnScreenPresented is gone - resume gameplay here. Exactly one per OnScreenPresented (see the matched-pair table above). The AlmediaInAppScreenResult argument reports how the screen was dismissed - Completed (closed by the web client), Cancelled (user closed it), or Failed (it could not load, with the detail in Error). Native completes its sync-on-close before this fires, so state read in the handler (e.g. Status) already reflects anything that happened inside the screen. For webview linking the pair fires in addition to the link callbacks, and OnScreenDismissed fires before the outcome callbacks (OnLinkCompleted / OnErrorOccurred).

`static event Action<AlmediaLogLevel, string> OnLog`

Fires for every log line emitted by the SDK, including forwarded logs from the native plugins. No subscribers means no console output - the SDK does not call UnityEngine.Debug directly. Wire this into your own logging pipeline as needed. See AlmediaLogLevel for the levels.