-
Notifications
You must be signed in to change notification settings - Fork 13
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
feat: SSE / real time flags support #32 #67
feat: SSE / real time flags support #32 #67
Conversation
…he decoding and logic
…nnection logic to use a backoff timer
Bump version 3.7.0 (Flagsmith#66)
…smith-ios-client-sdk into feature/sse-support
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, but I've added a few minor comments.
Co-authored-by: Matthew Elwell <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, but let's remove the version bump.
# Conflicts: # Example/FlagsmithClient/Base.lproj/LaunchScreen.xib # FlagsmithClient/Classes/Traits.swift
As above, there isn't actually a bump |
Description
This PR implements the Real Time Flags feature #32 and part of Flagsmith/flagsmith#1498 for iOS.
The functionality is implemented using the Kotlin SDK's implementation as a working example, as this is the platform most closely aligned with the iOS implementation.
One difference of note is that the iOS SDK does not make use of any HTTP client library, using URLSession directly. As such its SSE implementation contains some lower-level functionality not found in the other implementations such as more granular error handling and increasing delay timer on most error conditions.
It also felt prudent to update the Example app to support SwiftUI and in-turn provide a reactive view of the current flags based on the new
var flagStream: AsyncStream<[Flag]>
provided by the SDK. This allowed for 'real life' manual testing through various network conditions to verify the integrity of the SSE connection.Pre-iOS 13 compatibility has been maintained as was done in the current SDK, though the need for this is probably up for discussion. Validating the SDK on iOS 12.x wasn't possible on my Mac. The implementation might have been a little tidier it this wasn't the case, and obvious improvements are commented in the code.
Unit tests have been added for all core business logic where possible without butchering the implementation. Significant changes would be required to get any more coverage really.
Regression Test Recommendations
I've tested this on Swift 5.10 and the new Xcode with Swift 6 and everything was fine. Xcode is really good at telling you about deprecations and compatibility issues and there are no warnings.
Has all been linted and formatted.
Would be nice to try this on iOS 12.x if possible.
Type of Change