-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add async/await functionality to abtesting [SwiftUI] #1214
Conversation
Use updateFromRemoteConfigAsync for iOS 15
The test is failing because of missing #if swift 5.5 checks. See firebase/firebase-ios-sdk#8289 for examples. Before fixing that, it would be good to investigate why the CI is succeeding despite the error. |
We might want to make a subset of https://github.com/firebase/firebase-ios-sdk/blob/master/scripts/build.sh#L111 with the |
You should be able to repro the CI build failures with Xcode 12. |
@morganchen12 @paulb777 I am not very sure, but my current understanding is that while xcodebuild is failing, xcpretty is exiting successfully, but that seems to contradict other scripts which do something like Also, is there a better way of debugging CI issues instead of committing changes and waiting for GHA checks? |
@paulb777 Should I go ahead and look into this and incorporating it with abtesting? |
Should updating the NotificationCenter observer to either Combine or async/await be a separate PR? |
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.
LGTM to merge here and follow up in separate PRs for the other tasks.
let value = remoteConfig["color_scheme"].stringValue ?? "nil" | ||
if changed { | ||
print("Remote Config changed to: \(value)") | ||
DispatchQueue.main.async { |
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.
Wouldn't it be better to use @MainActor
to ensure colorScheme
is updated on the main actor?
Using DispatchQueue.main.async in combination with the new async/await features feels a bit like an anti-pattern to me.
See https://peterfriese.dev/swiftui-concurrency-essentials-part1/#updating-published-properties
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.
Great catch, thanks! I will include this change in a separate PR 👍
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.
Actually, is there an alternative other than using @MainActor
? Since we need the app to be backward-compatible with previous versions of iOS, I am not sure how to conditionally add @MainActor
...
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.
There are a couple of options:
- You could apply it to a function that needs to run on the main actor (and the #ifdef that function)
- Add it to the class (and #ifdef it there)
- Call
MainAction.run
directly: https://www.avanderlee.com/swift/mainactor-dispatch-main-thread/#using-the-main-actor-directly
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.
Awesome, in that case I can apply it to the already conditionally-compiled async function. Thanks for the pointers!
Use updateFromRemoteConfigAsync when using iOS 15 pull-down-to-refresh functionality.
Where else should async/await functionality be used? Should the app log something special to showcase async/await?