Repository navigation
fix(ios): apply the setup() options to CallKit right away - #907
Merged
Merged
Conversation
When the module loads, it builds the CallKit provider from the settings stored by setup() during the previous launch. setup() then stored the new options but left the provider alone (initCallKitProvider only creates it), so CallKit kept the previous launch's options, and a second setup() never changed them. setup() now sets the provider's configuration when the provider exists. The Mac Catalyst harness, which compiles RNCallKeep.m and reads callKeepProvider.configuration, shows it with options A stored and setup(B) (relaunch), and with setup(A) then setup(B): master keeps A, this change applies B. As documented, setup() from JavaScript is still ignored after a setup from native code; calling [RNCallKeep setup:] again now updates the options too (it went through the JavaScript method, which returned early). Based on #732 by Christian Schmidt, which applied the configuration the same way but also let JavaScript override a native setup. Co-authored-by: Christian Schmidt <cs@relatel.dk>
# Conflicts: # CHANGELOG.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Takes over #732 by @c960657.
The problem
When the module loads,
initbuilds the CallKit provider from the settings thatsetup()stored during the previous launch (so a VoIP push can be reported before JavaScript runs).setup()then stores the new options, butinitCallKitProvideronly creates a provider, so the existing one keeps the old configuration:setup()options (or any option computed at runtime), CallKit uses the previous launch's options until the next launch;setup()again, as [IOS] Allow calling setup() multiple times #732 wanted for options that depend on user preferences, never changes CallKit.The change
setup()setssharedProvider.configurationwhen the provider exists (the approach of #732). Unlike #732, it keeps the documented rule thatsetup()from JavaScript is ignored after a setup from native code ([RNCallKeep setup:]in the app delegate): #732 let JavaScript override it. A native app can now call[RNCallKeep setup:]again to change the options; that went through the JavaScript method, which returned early.docs/setup.mdand thesetSettingssection ofdocs/api.mdsay how to change the options.Tests
The Mac Catalyst harness compiles
RNCallKeep.mwith React stubs and readscallKeepProvider.configuration(options A: 1 call group, in Recents, no video; options B: 3 groups, not in Recents, video):setup(B)setup(A), thensetup(B)setup(A), then JavaScriptsetup(B)setup(A), then nativesetup(B)On an iPhone 15 Pro Max with iOS 27, the example app had stored
includesCallsInRecents: trueduring earlier launches; a build of this branch whosesetup()passesfalseshowed an incoming call, answered and hung up normally, and the call did not appear in the Phone app's Recents (with master it would: the provider keepstrue).