Android Mobile SDK to easily integrate communication features (WebRTC, messaging, presence, voice, video, screensharing) based on RestComm into native Mobile Applications
Init with success signaling, success in push configuration: return success after signaling is good, and then nothing when push configuration is successful
Init with error signaling, doesn't matter what happens in push: right after signaling is failed, return error and don't even try doing push configuration
Init with success signaling, error push: return status when signaling succeeds, and then, when push configuration fails return a warning
The problem with this is that:
In (1), success only tells us about the signaling part which is a bit misleading as its not clear to the user whether they are really able to take full advantage of SDK.
In (3), we get 2 consecutive statuses, which again is not very helpful from UI/UX perspective on how to convey the issue in a nice manner
Proposed approach:
Init with success signaling, success in push: wait until both signaling and push setting are successful and then return success
Init with error signaling, doesn't matter what happens in push: right after signaling is failed, return error and not even try doing push configuration (when those happen in parallel, we can leave it finish though, no point in killing it)
Init with success signaling, error push: don't return any status until you both are done, at which point we return a warning BUT using RCDeviceListener.onInitialized() and introducing a warning code
Update parameters when user changed a push notifications related parameter, convey status potentially by using onConnectivityUpdate(), also consider renaming it to something like onStatusUpdate(), so that it reports on changes both on signaling connectivity and push notifications status.
FCM token updated so push notifications configuration was updated internally. In this case we don't need to update the user (since the user didn't initiate the change), unless the update was failed, in which case we can return onStatusUpdate() accordingly.
Notice that it might make sense to introduce a simple FSM class inside RCDevice to take care of the transitions, without having to scatter checks in the whole codebase.
Right now we are using the following approach:
The problem with this is that:
Proposed approach:
onConnectivityUpdate()
, also consider renaming it to something likeonStatusUpdate()
, so that it reports on changes both on signaling connectivity and push notifications status.Notice that it might make sense to introduce a simple FSM class inside RCDevice to take care of the transitions, without having to scatter checks in the whole codebase.