refreshInbox

Requests an updated list of Inbox messages from Marketing Cloud. listener, if provided, is notified at most once per source for this call: once for each configured server (MCE, MAM) whose fetch completes, tagged with that server. Once the first server answers, a new refresh may be started; doing so stops this listener from receiving the remaining server's outcome. Outcomes are not matched to a specific call: a server's next outcome goes to the latest refresh's listener, even if it comes from a fetch started earlier. If the module itself refuses or cancels the request (a refresh is already in progress, Inbox is disabled or GDPR-blocked, or Inbox is disabled/torn down before any server has answered), listener is notified once with (false, Event.Producer.INBOX_FEATURE_MODULE). If Inbox is disabled/torn down after one server has answered, listener is released without a callback for the other server. Every listener callback, including a refusal, is made on the main thread after this call returns.

Refreshes are rate limited, by the SDK and by the server, so a refresh requested too soon after another can be refused. A refused refresh is not retried: InboxRefreshListener.onRefreshComplete reports successful = false. Use it for a user-initiated refresh (for example pull-to-refresh) and rely on the SDK's automatic refreshes otherwise.

Lifecycle: the SDK holds a strong reference to listener until both servers have answered, the next refresh is accepted, Inbox is disabled, or unregisterInboxRefreshListener is called. With only one server configured, the other server never answers, so without unregisterInboxRefreshListener that means until the next refresh or until Inbox is disabled. A fetch can take a long time (MAM waits for network connectivity), so a callback may arrive after the Activity, Fragment or ViewModel that started the refresh is gone. Call unregisterInboxRefreshListener when that owner is destroyed (e.g. Activity.onDestroy, ViewModel.onCleared).