New IterableEmbeddedUpdateHandler methods for sync failure and success.

[franco-zalamena-iterable]

🔹 Jira Ticket(s) if any

• SDK-302

✏️ Description

Creating new methods regarding sync success and failures for users to be able to act upon result.
Matching listener style from ios side
ios merged pr: Iterable/iterable-swift-sdk#988

[sumeruchat]

Also is the refactoring really necesssary. Any refactor runs the risk of introducing regressions. Lets try to get the minimum changeset that accomplishes the task and has no side effects.

[franco-zalamena-iterable]

Also is the refactoring really necesssary. Any refactor runs the risk of introducing regressions. Lets try to get the minimum changeset that accomplishes the task and has no side effects.

Yes i think we should have android and ios matching, this change introduces no behavior change, it is only new callbacks

[sumchattering]

1. Bug: notifySyncFailed called alongside broadcastSubscriptionInactive for
   inactive subscriptions

This is the most important issue. In the new code:

{ reason, data ->
handleSyncFailure(reason, data) // calls
broadcastSubscriptionInactive() for inactive subs
notifySyncFailed(reason) // ALSO called — always
}

In the original code, the failure handler had an early return after
broadcastSubscriptionInactive(), meaning listeners would only receive
onEmbeddedMessagingDisabled(). Now they receive both
onEmbeddedMessagingDisabled() and onEmbeddedMessagingSyncFailed() for the
SUBSCRIPTION_INACTIVE / Invalid API Key cases.

Recommendation: If this is intentional, document it. If not, either:

• Return a boolean from handleSyncFailure and conditionally call
  notifySyncFailed, or
• Move notifySyncFailed into the else branch of handleSyncFailure.

2. processEmbeddedMessagesResponse only catches JSONException

The catch block in syncMessages catches JSONException, but
processEmbeddedMessagesResponse calls
IterableEmbeddedPlacement.fromJSONObject() which uses getLong() /
getJSONArray() — these throw JSONException, so the malformed-JSON test should
pass. However, if fromJSONObject ever evolves to throw other exceptions
(e.g., NullPointerException from a null optJSONObject), those would propagate
uncaught. Consider whether a broader catch (e: Exception) would be more
defensive here.

[joaodordio]

LGTM