Decide approach to memory management #9
Description
Currently, our LiveObjects plugin objects are just holding a weak reference to e.g. their ARTRealtimeChannel. But this doesn't seem to be the approach used in the core SDK; it seems like e.g. a channel holds a strong reference to its realtime instance. It would be good to be consistent with this approach, but I need to understand it better, in particular what's the mechanism that allows objects to be eventually deallocated (i.e. not have a permanent strong reference cycle).
Take a look at ably-cocoa and its ObjectLifetimesTests which hopefully will clarify the intended behaviour.
Update, 2025-06-09: Also double-check the new channel property that I've added to ARTRealtimeChannelInternal, and whether weak is the right thing.
Update, 2025-06-12: Also understand the "dispose and close" pattern that we have in all of the ably-cocoa tests. Is this necessary or just superstition? For now I'm just going to do defer { client.close() } in our test suite (because we don't have the dispose method of ably-cocoa's test suite and I'm not yet sure it's necessary). (Answer, 2025-07-10: Yes, it appears that ably-cocoa has a behaviour whereby the ARTRealtimeInternal will keep itself alive whilst the connection is connected; see this conversation where Cursor explains it; key point is that the WebSocket self-retains and then the transport has a strong delegate property; honestly this behaviour is surprising to me and I wonder if it'd be to our users too, especially since a WebSocket connection is not some sort of short-lived thing; you might leak it for a long time)
Update, 2025-07-01: When porting across the JS integration tests, noticed that they don't even maintain an external reference to the channel (only to the RealtimeObjects instance) so when we port them the channel gets deallocated and LiveObjects no longer works property. I've had to work around this by explicitly extending the lifetime of the channel in the tests for now.