-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Migrate to UserDefaults based heartbeat on tvOS #7893
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
Conversation
Package.swift
Outdated
"7.2.1" ..< "8.0.0" | ||
// TODO: Move from `revision` to version below before publishing. | ||
.revision("a59fd0181d8f7c2b4c815cd6cddf4c38a4ba35ee") | ||
// "7.4.0" ..< "8.0.0" |
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.
This tag won't be available until we publish GoogleUtilities.
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.
cc @paulb777 - how did we handle this in the past?
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.
We either need to publish GoogleUtilities sooner or update this later in the release cycle.
There are some options to explore from https://forums.swift.org/t/best-practices-for-integration-testing-and-releasing-multiple-packages/47006/11, but nothing too clear or easy.
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.
Happy to hold off temporarily and cherry-pick this when it's published. We should also probably set up a presubmit that prevents .revision
from being checked in to prevent failures in the future
NSString *const kHeartbeatStorageName = @"HEARTBEAT_INFO_STORAGE"; | ||
id<GULHeartbeatDateStorable> dataStorage; | ||
#if TARGET_OS_TV | ||
NSString *const kFIRCoreSuiteName = @"com.firebase.core"; |
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.
I can stick with standardUserDefaults
but felt like I should move away from it. Thoughts on this domain?
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.
A custom domain looks reasonable as there is less probability that it will be modified by developers for their purposes. "com.firebase.core" is pretty generic name, so I would either declare a more specific one for the heartbeat use only or at least define a constant available for the rest of Core if we would like to reuse the same defaults for other purposes. I would prefer the more specific name.
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.
I did intentionally name it so Core could use it in the future for other things, since I don't think we need a new suite name for every piece of data we need to store (that's what the keys are for). Breaking it out into a constant would make sense in that case then, and other SDKs could follow suit eventually (com.firebase.auth
, .firestore
, etc).
Does that sound reasonable?
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.
SGTM. The only potential issue with reuse may be that the same defaults may potentially be modified from different parts of the code that may be easy to overlook. It seems to me that having extra user defaults is a relatively cheap mitigation of this issue. I'm fine with either for this 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.
Yeah, we currently use a single user defaults (standardUserDefaults
) anyways so this wouldn't be anything new, and we should provide a unique key for each usage point as we currently do.
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.
yeah, makes sense. Looks safe for now.
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
NSString *const kHeartbeatStorageName = @"HEARTBEAT_INFO_STORAGE"; | ||
id<GULHeartbeatDateStorable> dataStorage; | ||
#if TARGET_OS_TV | ||
NSString *const kFIRCoreSuiteName = @"com.firebase.core"; |
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.
A custom domain looks reasonable as there is less probability that it will be modified by developers for their purposes. "com.firebase.core" is pretty generic name, so I would either declare a more specific one for the heartbeat use only or at least define a constant available for the rest of Core if we would like to reuse the same defaults for other purposes. I would prefer the more specific name.
Will wait until GoogleUtilities 7.4.0 publishes so we can have the proper |
Coverage ReportAffected SDKs
Test Logs |
I moved the milestone to 8.0.0 since the update did not make it into 7.11.0. |
Kicked off a rerun of CI to test with GoogleUtils 7.4 (that is staged in SpecsStaging atm) |
This should mitigate heartbeat files being wiped due to tvOS cache being invalidated.
5907aa6
to
b879789
Compare
name: "GoogleUtilities", | ||
url: "https://github.com/google/GoogleUtilities.git", | ||
"7.3.0" ..< "8.0.0" | ||
"7.4.0" ..< "8.0.0" |
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.
@paulb777 @ryanwilson tagged GoogleUtils 7.4.0 for SwiftPM (on GoogleUtils repo) and am now pointing to GoogleUtils 7.4 in the Package manifest here.
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 - thanks for the update!
This should mitigate heartbeat files being wiped due to tvOS cache being
invalidated. Fixes #6662
#no-changelog