-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Wrapper sdk proxy #2014
base: main
Are you sure you want to change the base?
[WIP] Wrapper sdk proxy #2014
Conversation
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
5287a37
to
b60479b
Compare
b60479b
to
03c6218
Compare
03c6218
to
93a2144
Compare
927ac69
to
7158c90
Compare
That change, which moved the `presence` property from the ARTRealtimeChannel class to ARTRealtimeChannelProtocol, changed the type of the property from ARTRealtimePresence to id<ARTRealtimePresenceProtocol>. This is a breaking change for anybody who was relying on the property returning the concrete type, one such example being our Asset Tracking SDK. So, we undo it. The change made in 26d9bf7 was triggered by us noticing, whilst working on the Chat SDK — which does its best to avoid referring to ably-cocoa's concrete types — that when you have an ably-cocoa concrete type ConcreteA which implements a protocol ProtocolA, and where ConcreteA has a public method or property `someMethod` which returns an instance of another concrete type ConcreteB which happens to implement a protocol ConcreteB, then `someMethod` is always defined directly on ConcreteA, not on ProtocolA. We wondered "why can't these methods be on ProtocolA instead?", hence 26d9bf7. But the first reason is that we can't because in order to do this it makes sense for you to also change the the return type of `someMethod` from ConcreteB to ProtocolB, which is a breaking change as we've seen here. But also I'm not sure whether it'd work even if we accepted the breaking change; for example, I don't know if you can mark a protocol as Sendable in Objective-C (haven't looked into it since we currently have no intention of making the breaking change, but one to investigate if we consider it in the future). Resolves #2003.
Preparation for introducing a new class that conforms to these protocols but which won't have these initializers. Let's use these protocols just to list the functionality provided by an already-initialized client. (TODO is this a breaking change)
this is so that we can do things like move `channels` into them (the types currently clash; e.g. one is `ChannelsInternal` and one is `Channels`), and it's just unnecessarily restrictive. perhaps there's some undocumented characteristic of the `Internal` classes that i'm violating, but oh well (i still remain confused about the purpose of the Internal classes) (TODO not sure if, post-removal of attempting to use interfaces for properties, this is still needed)
It's already declared in ARTChannelProtocol.
TODO same for REST?
it's unused (i.e. nobody takes one as a dependency)
Nobody makes use of this conformance.
note that this justifies our earlier making of the internal not conform to the public protocol note this provides groundwork for allowing other REST-triggering things to also supply wrapper SDK agents, but that we're currently passing nil for wrapperSDKAgents param; will address that piecemeal later TODO test
7158c90
to
209035f
Compare
this will allow us to insert the agent parameter (no functional changes in this commit) TODO this doesn't cover the channel's other properties TODO reuse existing instance
Will use in an upcoming commit, but it's also handy for users of the SDK (e.g. I had already found myself wanting it in Chat, when wishing to create a modified version of an options object recevied as an argument). TODO test
209035f
to
7410363
Compare
No description provided.