Skip to content

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

Merged
merged 8 commits into from
Oct 9, 2020
Merged

Conversation

danasilver
Copy link
Contributor

@danasilver danasilver commented Oct 6, 2020

Removes the following methods:

FirebaseRemoteConfig#activateFetched()
FirebaseRemoteConfig#getByteArray(String)
FirebaseRemoteConfig#setConfigSettings(FirebaseRemoteConfigSettings)
FirebaseRemoteConfig#setDefaults(Map<String,Object>)
FirebaseRemoteConfig#setDefaults(int)

FirebaseRemoteConfigSettings#isDeveloperModeEnabled()
FirebaseRemoteConfigSettings.Builder.setDeveloperModeEnabled(boolean)

and the FirebaseRemoteConfigFetchException class.

@googlebot googlebot added the cla: yes Override cla label Oct 6, 2020
@google-oss-bot
Copy link
Contributor

google-oss-bot commented Oct 6, 2020

Coverage Report

Affected SDKs

  • firebase-config

    SDK overall coverage changed from 88.72% (e65f487) to 89.02% (056025ca) by +0.30%.

    Filename Base (e65f487) Head (056025ca) Diff
    ConfigCacheClient.java 93.55% 93.33% -0.22%
    ConfigFetchHandler.java 97.20% 97.18% -0.02%
    ConfigMetadataClient.java 89.47% 90.11% +0.64%
    FirebaseRemoteConfig.java 88.28% 89.19% +0.91%
    FirebaseRemoteConfigSettings.java 65.63% 61.54% -4.09%

Test Logs

Notes

HTML coverage reports can be produced locally with ./gradlew <product>:checkCoverage.
Report files are located at <product-build-dir>/reports/jacoco/.

Head commit (056025ca) is created by Prow via merging commits: e65f487 102a838.

@google-oss-bot
Copy link
Contributor

google-oss-bot commented Oct 6, 2020

Binary Size Report

Affected SDKs

  • firebase-config

    Type Base (e65f487) Head (056025ca) Diff
    aar 193 kB 191 kB -2.23 kB (-1.2%)
    apk (release) 1.02 MB 1.02 MB -480 B (-0.0%)
  • firebase-installations

    Type Base (e65f487) Head (056025ca) Diff
    aar 62.2 kB 62.2 kB +5 B (+0.0%)

Test Logs

Notes

Head commit (056025ca) is created by Prow via merging commits: e65f487 102a838.

Copy link

@erikeldridge erikeldridge left a 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.
*/

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 👍

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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.

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 :)

Copy link
Contributor Author

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) {

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

Copy link
Contributor Author

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 {

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.

Copy link
Contributor Author

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.

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) {

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());

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?

Copy link
Contributor Author

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

@danasilver danasilver merged commit 83e9406 into master Oct 9, 2020
@danasilver danasilver deleted the rc-remove-deprecated-apis branch October 9, 2020 14:50
@firebase firebase locked and limited conversation to collaborators Nov 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants