Nc/custom signal #13976
Nc/custom signal #13976
Conversation
Generated by 🚫 Danger |
Apple API Diff ReportCommit: 907789c FirebaseRemoteConfigEnumerations[ADDED] FIRRemoteConfigCustomSignalsError[ADDED] FIRRemoteConfigCustomSignalsErrorSwift:
+ typealias RemoteConfigCustomSignalsError . Code . _ErrorType = RemoteConfigCustomSignalsError
+ case unknown = 8001
+ case invalidValueType = 8002
Objective-C:
+ enum FIRRemoteConfigCustomSignalsError : NSInteger {}
+ FIRRemoteConfigCustomSignalsErrorUnknown = 8001
+ FIRRemoteConfigCustomSignalsErrorInvalidValueType = 8002ClassesFIRRemoteConfig[ADDED] -setCustomSignals:WithCompletion:Objective-C:
+ - ( void ) setCustomSignals :( nullable NSDictionary < NSString * , NSObject *> * ) customSignals WithCompletion :( void ( ^ _Nullable )( NSError * _Nullable error )) completionHandler NS_REFINED_FOR_SWIFT ;Constants[ADDED] FIRRemoteConfigCustomSignalsErrorDomain[ADDED] FIRRemoteConfigCustomSignalsErrorDomainSwift:
+ let RemoteConfigCustomSignalsErrorDomain : String
Objective-C:
+ extern NS_SWIFT_NAME ( RemoteConfigCustomSignalsErrorDomain ) NSString * const FIRRemoteConfigCustomSignalsErrorDomain |
| void (^setCustomSignalsBlock)(void) = ^{ | ||
| if (!customSignals) { | ||
| if (completionHandler) { | ||
| dispatch_async(dispatch_get_main_queue(), ^{ |
There was a problem hiding this comment.
Any reason we have to dispatch the completion block back to main thread? Ideally if SDK work does not involve UI we should try stay away from main as much as possible.
| if (value && ![value isKindOfClass:[NSString class]] && | ||
| ![value isKindOfClass:[NSNumber class]]) { | ||
| if (completionHandler) { | ||
| dispatch_async(dispatch_get_main_queue(), ^{ |
There was a problem hiding this comment.
Same here, any reason we have to dispatch the completion block back to main? Also, the logic here seems like, if there is one invalid value type we send error back the completion block. Wonder do we want to check all and send all invalid entries as error instead?
| } | ||
| } | ||
|
|
||
| self->_settings.customSignals = newCustomSignals; |
There was a problem hiding this comment.
Hmmmm I don't see any synchronization strategy on _settings.customSignals, assuming this is the in memory record for customSignals, how do we maintain the update order if setCustomSignals getting called multiple time?
| @@ -1834,6 +1834,32 @@ - (void)testFetchAndActivateRolloutsNotifyInterop { | |||
| [self waitForExpectations:@[ notificationExpectation ] timeout:_expectationTimeout]; | |||
| } | |||
|
|
|||
| - (void)testSetCustomSingals { | |||
There was a problem hiding this comment.
Can we have another test case where within one rc instance call setCustomSignals multiple times?
| @@ -237,6 +240,61 @@ - (void)callListeners:(NSString *)key config:(NSDictionary *)config { | |||
| } | |||
| } | |||
|
|
|||
| - (void)setCustomSignals:(nullable NSDictionary<NSString *, NSObject *> *)customSignals | |||
There was a problem hiding this comment.
why not just take in NSDictionary<NSString *, NSString *>? then it becomes impossible to set something invalid
feat(rc): Add custom signals support