Make remote config accessible to background agents #3124
Conversation
...okerProtection/Sources/DataBrokerProtection/Scheduler/DataBrokerProtectionAgentManager.swift
Outdated
Show resolved
Hide resolved
...erProtection/Sources/DataBrokerProtection/Configuration/DBPPrivacyConfigurationManager.swift
Outdated
Show resolved
Hide resolved
| @@ -34,30 +35,84 @@ final class ConfigurationStore: ConfigurationStoring { | |||
| .remoteMessagingConfig: "remote-messaging-config.json" | |||
| ] | |||
|
|
|||
| static let shared = ConfigurationStore() | |||
| private enum Constants { | |||
There was a problem hiding this comment.
Nitpicky so feel free to ignore.
In my opinion naming this ETag would result in improved readability:
ETag.configStorageTrackerRadar vs Constants.configStorageTrackerRadarEtag
DuckDuckGo/ContentBlocker/Mocks/ContentBlockerRulesManagerMock.swift
Outdated
Show resolved
Hide resolved
| var trackerDataManager = TrackerDataManager(etag: ConfigurationStore().loadEtag(for: .trackerDataSet), | ||
| data: ConfigurationStore().loadData(for: .trackerDataSet), |
There was a problem hiding this comment.
Not going to change much, but maybe take an easy win and instantiate ConfigurationStore() once since we're using it twice here?
There was a problem hiding this comment.
I'm going to opt to leave these as is. These are instantiating properties on the tests so even adding a dedicated property for the store throws an error in Xcode probably because of init order. Refactoring this to simplify it doesn't seem worth it.
| trackerDataManager: TrackerDataManager(etag: ConfigurationStore().loadEtag(for: .trackerDataSet), | ||
| data: ConfigurationStore().loadData(for: .trackerDataSet), |
There was a problem hiding this comment.
Another possibility to use the same instance.
| @@ -155,7 +155,7 @@ final class DataBrokerRunCustomJSONViewModel: ObservableObject { | |||
| private let authenticationManager: DataBrokerProtectionAuthenticationManaging | |||
|
|
|||
| init(authenticationManager: DataBrokerProtectionAuthenticationManaging) { | |||
| let privacyConfigurationManager = PrivacyConfigurationManagingMock() | |||
| let privacyConfigurationManager = DBPPrivacyConfigurationManager() | |||
There was a problem hiding this comment.
Has anyone from DBP looked at these changes?
<!-- Note: This checklist is a reminder of our shared engineering expectations. --> Please review the release process for BrowserServicesKit [here](https://app.asana.com/0/1200194497630846/1200837094583426). **Required**: Task/Issue URL: https://app.asana.com/0/1203581873609357/1207165680693234/f iOS PR: duckduckgo/iOS#3255 macOS PR: duckduckgo/macos-browser#3124 What kind of version bump will this require?: Major **Optional**: Tech Design URL: CC: **Description**: This PR modularizes the config to allow it to be used in background processes <!-- Tagging instructions If this PR isn't ready to be merged for whatever reason it should be marked with the `DO NOT MERGE` label (particularly if it's a draft) If it's pending Product Review/PFR, please add the `Pending Product Review` label. If at any point it isn't actively being worked on/ready for review/otherwise moving forward (besides the above PR/PFR exception) strongly consider closing it (or not opening it in the first place). If you decide not to close it, make sure it's labelled to make it clear the PRs state and comment with more information. --> **Steps to test this PR**: 1. Run the VPN and DBP background agents 2. Look for `Configuration` logs that indicate the config being downloaded or refreshed 3. If the config is setup correctly you can watch for the pixel test as well. 1. <!-- Before submitting a PR, please ensure you have tested the combinations you expect the reviewer to test, then delete configurations you *know* do not need explicit testing. Using a simulator where a physical device is unavailable is acceptable. --> **OS Testing**: * [ ] iOS 14 * [ ] iOS 15 * [ ] iOS 16 * [ ] macOS 10.15 * [ ] macOS 11 * [ ] macOS 12 --- ###### Internal references: [Software Engineering Expectations](https://app.asana.com/0/59792373528535/199064865822552) [Technical Design Template](https://app.asana.com/0/59792373528535/184709971311943)
There was a problem hiding this comment.
In terms of edits to existing files things look good.
In terms of new files (e.g. ConfigurationManager), I think the horse might have bolted on this since it's the same across the targets, but generally I think it's lacking clarity on the purpose of each thing without having a lot of wider context.
| We ideally should refactor the privacy config out of the main app | ||
| Into a local package, so that it can be be used here | ||
| */ | ||
| public final class PrivacyConfigurationManagingMock: PrivacyConfigurationManaging { |
There was a problem hiding this comment.
My greatest crime removed
| static var config: Logger = { Logger(subsystem: Bundle.main.bundleIdentifier ?? "DuckDuckGo", category: "Configuration") }() | ||
| } | ||
|
|
||
| final class ConfigurationManager: DefaultConfigurationManager { |
There was a problem hiding this comment.
It's probably a bit late for this since I see the same pattern is used across the different targets, but I think it would be better if this had a more specific name since there's multiple different configurations flying around (e.g. executionConfig)
| PixelKit.fire(DebugEvent(domainEvent, error: error)) | ||
| } | ||
|
|
||
| func log() { |
There was a problem hiding this comment.
Similar to above, I think this could do with a more descriptive name
Task/Issue URL: https://app.asana.com/0/1203581873609357/1207165680693234/f
Tech Design URL:
CC:
Description:
Steps to test this PR:
Definition of Done:
Internal references:
Pull Request Review Checklist
Software Engineering Expectations
Technical Design Template
Pull Request Documentation