-
Notifications
You must be signed in to change notification settings - Fork 627
Remove deprecated methods from RC. #2042
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
Coverage ReportAffected SDKs
Test Logs
NotesHTML coverage reports can be produced locally with Head commit (056025ca) is created by Prow via merging commits: e65f487 102a838. |
Binary Size ReportAffected SDKs
Test Logs
NotesHead commit (056025ca) is created by Prow via merging commits: e65f487 102a838. |
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, but since we can't approve w changes requested, I'm selecting "request changes" just to highlight a question.
* | ||
* @param settings The new settings to be applied. | ||
* @deprecated Use {@link #setConfigSettingsAsync(FirebaseRemoteConfigSettings)} instead. | ||
*/ |
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.
Thinking (no action req'd): after we remove the sync methods, we'll be able to drop the "async" suffix and use the setConfigSettings
signature for async 👍
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 could, but that'd be a breaking API change, too.
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 wonder if, instead of deleting this one, we could change it's return type to Task and deprecate the setConfigSettingsAsync() method. And then at some point delete the "Async" method. wdyt?
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.
Would that be more confusing or error prone for developers on this update path? I'd figure many people use the deprecated sync methods and don't check the return type. Might create unexpected behavior to make them async with the existing 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.
This PR currently removes the setConfigSettings
method, so anyone using it is going to have to change code. The same would be true if we retained the method and made it async. Ultimately, I think it's relatively minor, since naming is hard :)
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, my thought is that requiring the new method with Async
in the name will prevent users from blindly switching to a method that's now async (when they previously might have fired and forgot, expecting a sync call).
* Asynchronously sets the defaults cache to the given default values, and persists the values to | ||
* disk. | ||
*/ | ||
private void setDefaultsWithStringsMap(Map<String, String> defaultsStringMap) { |
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.
Thinking (no action req'd): I wonder why a simple overload of setDefaults
was insufficient and we needed to add the WithStringsMap
qualifier
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.
😄
@@ -15,8 +15,7 @@ | |||
package com.google.firebase.remoteconfig; | |||
|
|||
/** An exception thrown when a {@link FirebaseRemoteConfig#fetch()} call is throttled. */ | |||
public class FirebaseRemoteConfigFetchThrottledException | |||
extends FirebaseRemoteConfigFetchException { | |||
public class FirebaseRemoteConfigFetchThrottledException extends FirebaseRemoteConfigException { |
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.
Given the deprecation guidance on FirebaseRemoteConfigFetchException
is to use FirebaseRemoteConfigServerException
or FirebaseRemoteConfigClientException
, I wonder if we should be deprecating FirebaseRemoteConfigFetchThrottledException
. If so, we could make that a tiny follow-up change just to keep this PR focused.
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.
The throttled exception makes more sense to me to keep since it has info (throttleEndTimeMillis
) the super class doesn't.
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.
Good point
* | ||
* @return A {@link Task} representing the write to disk. | ||
*/ | ||
public Task<ConfigContainer> putWithoutWaitingForDiskWrite(ConfigContainer configContainer) { |
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.
Thinking (no action req'd): I'm happy to see us reducing sources of ambiguity like this fire-and-forget async update
frc.setConfigSettings( | ||
new FirebaseRemoteConfigSettings.Builder().setDeveloperModeEnabled(true).build()); | ||
frc.setConfigSettingsAsync( | ||
new FirebaseRemoteConfigSettings.Builder().setFetchTimeoutInSeconds(0L).build()); |
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.
Dumb question: IIUC, this test app calls a live RC endpoint, in which case setting a timeout of 0s seems aggressive; any chance the intent is to bypass the cache (setMinimumFetchIntervalInSeconds
), which is closer to the functionality of developer mode, rather than setting a timeout?
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.
Not a dumb question! That is actually what I intended to do, but I set the wrong setting! Thanks for questioning it. :P
Removes the following methods:
and the
FirebaseRemoteConfigFetchException
class.