Investigate various API issues + come up with plan

[atsakiridis]

Various API issues came up from BETA 8 testing. Let's document them altogether as we need to come up with a solution covering all angles and keep the API from changing constantly:

• When open the app and RCDevice is registered, go to settings screen and hit home button. When returning back to the app (setting screen), change some of the settings and tap on back (to go to main screen), exception is thrown. @ognjenns can you add here the error text that you got? Issue here is that only MainActivity calls RCDevice.initialize(), so when user hits home, RCDevice is released() and then when they go back to Settings and update the settings there is no RCDevice initialized to do the reconfigure(). We generally assume that user will always come in the App from MainActivity which isn't the case.
• When going to BugReport Activity RCDevice is released(). This happens because in BugReport activity we don't bind to RCDevice. The general issue is that right now in order to be able to receive calls across the whole App (i.e. all activities), you need to bind to service on each of them. Also, when changing from one activity to another there's a chance that release() is called by old activity and initialize() called by new activity, and state could get messy depending on the ordering of those.
• We are not able to monitor RCConnection status outside of CallActivity. This doesn't seem much, but since we are supporting having a live call and navigating outside of CallActivity we need to think how we can be notified of events of the call. That way, for example when the call ends we can remove a banner from other screens that the call is ongoing. We could add broadcastreceiver and intents for that but we need to think more broader the API design and what other changes it might bring. Need to check
• Come up with more intuitive API in terms of what happens if initialization fails asynchronously (for example due to SIP authorizations going wrong). Right now if that happens, the RCDevice is deemed initialized, but RCDevice.state is OFFLINE which makes things work easily for the App, since we can call reconfigure() to fix things. On the other hand if initialization fails synchronously (typically due to validation issue) then RCDevice is not initialized() and the user needs to re-initialize properly which is intuitive behavior. Need to brainstorm to see how we can be consistent between synchronous and asynchronous error reporting across all APIs.
• Its unclear whether when SDK conveys Connectivity status it takes into account just network connectivity or actual connectivity with RC. The latter is documented, but still in some case if there's some sort of signaling error, then SDK returns connectivity Wifi, even though it conveys the error with the statusCode & text. Need to clarify

[atsakiridis]

This is still pending work. Did some research and trying various ways to improve, but haven't managed to conclude yet. Hopefully by next sprint we 'll be able to have some actionable items