Lifecycle of `ARTRealtime` object

[maratal]

Until close is called ARTRealtime object remains in memory, even if replaced with another one. This is a source of many bugs (such as this and this) and potential performance issues.

For this to be fixed memory management of the following ARTRealtimeInternal objects should be refactored:

__weak ARTEventListener *_connectionRetryFromSuspendedListener;
__weak ARTEventListener *_connectionRetryFromDisconnectedListener;
__weak ARTEventListener *_connectingTimeoutListener;

┆Issue is synchronized with this Jira Task by Unito

[maratal]

WDYT @QuintinWillison @lawrence-forooghian

[sync-by-unito[bot]]

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-3189

[QuintinWillison]

The spec doesn't make it really clear, however it doesn't prohibit reuse of Realtime or Connection instances. We also infer this in our documentation for close.

So I'm not convinced that the problem area is the close method, as you're more discussing the lifecycle of the overarching Realtime instance and underlying instances of other classes upon which it relies to do its work.

I don't feel that reuse of instances of objects that have lifecycles that include terminal states should ever have been in the design, but this is what we've got.

If there's a tweak you can make that would not affect SDK side effects or other behaviours upon which existing apps might rely then go for it, but I suspect it'll not be that simple. Therefore, this might be something to consider for our version 2 scope for this SDK. FYI, @mikelee638