feat: Revised Usage of Remote Parameter Fetcher #18
Conversation
activate() instead of fetchAndActivate()
RemoteParameter class
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #18 +/- ##
==========================================
+ Coverage 47.71% 54.40% +6.68%
==========================================
Files 10 10
Lines 285 261 -24
==========================================
+ Hits 136 142 +6
+ Misses 149 119 -30
☔ View full report in Codecov by Sentry. |
| /// This is useful for when you want to force a refetch of the value. | ||
| final Future<T> Function() activateAndRefetch; | ||
| /// The subscription to the stream of updated parameter information. | ||
| final StreamSubscription<void> _subscription; |
There was a problem hiding this comment.
By passing subscription as an argument, it has become unnecessary for the caller of the class to be conscious of adding or removing listeners!
| @visibleForTesting | ||
| Stream<RemoteConfigUpdate> get onConfigUpdated { | ||
| return _rc.onConfigUpdated; | ||
| late final Stream<RemoteConfigUpdate> onConfigUpdated = _rc.onConfigUpdated; |
There was a problem hiding this comment.
As noted in the comment, the original method format created different Streams each time it was called, resulting in only the latest Stream functioning effectively.
Therefore, we changed it to hold just one Stream per instance.
This ensures that once a Stream is created, it is continuously used for that instance, guaranteeing efficient and consistent operation.
There was a problem hiding this comment.
I see, I hadn't even thought about the behavior of getter and late final!
| RemoteParameter<String> getStringParameter( | ||
| String key, { | ||
| required ValueChanged<String> onConfigUpdated, | ||
| }) { |
There was a problem hiding this comment.
Instead of using addListener, we changed the approach to pass the callback for when onConfigUpdated is triggered as an argument. This allows for a more streamlined implementation, as shown in the following example using Riverpod.
@riverpod
String stringParameter(StringParameterRef ref) {
final fetcher = ref.watch(remoteParameterFetcherProvider);
final parameter = fetcher.getStringParameter(
stringParameterKey,
onConfigUpdated: (value) => ref.state = value,
);
ref.onDispose(parameter.dispose);
return Uri.parse(parameter.value);
}
| return getString(key); | ||
| }, | ||
| subscription: filteredOnConfigUpdated(key).listen((event) async { | ||
| await activate(); |
There was a problem hiding this comment.
https://firebase.google.com/docs/remote-config/get-started?platform=flutter#add-real-time-listener
The official documentation stated "Automatically fetch new parameter values" and only activate() was mentioned, so we modified it to match the documentation.
| Future<void> dispose() async { | ||
| await _intRemoteParameter.dispose(); |
packages/flutterfire_remote_parameter_fetcher/lib/src/remote_parameter_fetcher.dart
Outdated
Show resolved
Hide resolved
| const SizedBox(height: 16), | ||
| FilledButton( | ||
| onPressed: () async { | ||
| await _intRemoteParameter.activateAndRefetch(); |
There was a problem hiding this comment.
Does this mean that it is no longer necessary to expose methods for forced refresh such as activateAndRefetch to the outside world?
There was a problem hiding this comment.
Yes, as of now, onConfigUpdate suffices, so there's no need to expose RemoteParameter externally anymore!
It seems that onConfigUpdate is also triggered when returning from the background, which was the intended use case.
In RemoteParameterFetcher, fetchAndActivate can still be used, so if re-fetching and activation are needed, we will continue to use that method.
naipaka
changed the title
naipaka
changed the title
Co-authored-by: Ryunosuke Muramatsu <[email protected]>
🙌 What I did
activate()instead offetchActivate()during real-time retrieval✍️ What I didn't do
✅ Verification
Screenshots
2023-11-12.14.07.09.mov
Additional Information