splitTestWithName triggers NSUserDefaultsDidChangeNotification every time it's called
JohnLemberger opened this issue · comments
It looks like:
if ([choices isKindOfClass:[NSArray class]]) {
if (!choice || ![choices containsObject:choice]) {
choice = SLRandomValueFromArray(choices);
}
} else if ([choices isKindOfClass:[NSDictionary class]]) {
if (!choice || ![[choices allKeys] containsObject:choice]) {
choice = SLRandomKeyFromDictionaryWithWeightedValues(choices);
}
} else {
@throw [NSException exceptionWithName:NSInvalidArgumentException reason:NSLocalizedString(@"Parameter `choices` must be either array or dictionary", nil) userInfo:nil];
}
[[NSUserDefaults standardUserDefaults] setObject:choice forKey:SLUserDefaultsKeyForTestName(name)];
[[NSUserDefaults standardUserDefaults] synchronize];
should change to:
if ([choices isKindOfClass:[NSArray class]]) {
if (!choice || ![choices containsObject:choice]) {
choice = SLRandomValueFromArray(choices);
}
[[NSUserDefaults standardUserDefaults] setObject:choice forKey:SLUserDefaultsKeyForTestName(name)];
[[NSUserDefaults standardUserDefaults] synchronize];
} else if ([choices isKindOfClass:[NSDictionary class]]) {
if (!choice || ![[choices allKeys] containsObject:choice]) {
choice = SLRandomKeyFromDictionaryWithWeightedValues(choices);
}
[[NSUserDefaults standardUserDefaults] setObject:choice forKey:SLUserDefaultsKeyForTestName(name)];
[[NSUserDefaults standardUserDefaults] synchronize];
} else {
@throw [NSException exceptionWithName:NSInvalidArgumentException reason:NSLocalizedString(@"Parameter `choices` must be either array or dictionary", nil) userInfo:nil];
}
It looks like the same pattern is used in multivariateTestWithName:variables:block
as well.
We ran across this because we were calling splitTestWithName:choices:block:
from inside tableView:cellForRowAtIndexPath:
and noticed repeated NSUserDefaultsDidChangeNotifications in the logs. Granted, that's not a great way to use it and we've refactored.
Please let me know if you'd rather have a pull request.
Thanks for bringing this to my attention, @JohnLemberger. This has been fixed by 2752732, which is tagged as part of the 1.0.0 release.