Marat Al
Marat Al
https://docs.ably.io/client-lib-development-guide/features/#TO3l9 ┆Issue is synchronized with this [Jira Story](https://ably.atlassian.net/browse/ECO-4390) by [Unito](https://www.unito.io)
https://docs.ably.io/client-lib-development-guide/features/#TO3l8 ┆Issue is synchronized with this [Jira Story](https://ably.atlassian.net/browse/ECO-4388) by [Unito](https://www.unito.io)
_Originally posted by maratal in https://github.com/ably/ably-cocoa/issues/1260#issuecomment-1046296276_ ┆Issue is synchronized with this [Jira Story](https://ably.atlassian.net/browse/ECO-4387) by [Unito](https://www.unito.io)
From comment [here](https://github.com/ably/ably-cocoa/pull/1307#discussion_r831486280) * the behavior of `ARTDataEncoder/decode:identifier:encoding:` method is misaligned with the [specs](https://docs.ably.com/client-lib-development-guide/features/#RSL6b) ┆Issue is synchronized with this [Jira Bug](https://ably.atlassian.net/browse/ECO-4317) by [Unito](https://www.unito.io)
`ARTJsonLikeEncoder` tries to parse incoming error in the server's response like this: `NSDictionary *errorReason = [input valueForKey:@"errorReason"];` While in the updated implementation of the server's endpoint it's just an `error`...
Apple article on how to implement location pushes: https://developer.apple.com/documentation/corelocation/creating_a_location_push_service_extension `ably-cocoa`: https://github.com/ably/ably-cocoa/issues/1762 Server: 1. Handle additional dictionary parameter in POST "/push/deviceRegistrations". a) In addition to "push.recipient.deviceToken", "push.recipient.locationDeviceToken" should be read from...
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](https://github.com/ably/ably-cocoa/issues/593) and [this](https://github.com/ably/ably-cocoa/issues/1380)) and potential performance...
>The naming doesn't really tell me what's the difference between `openConnection` and `_openConnection` here. (It seems the the leading underscore is just a convention used to denote any private method...
What about if we made this a callback-based API instead, which, as well as not blocking, encapsulates the logic of waiting for the shared `ARTSRRunLoopThread` to start? Along the lines...