Repository navigation
Added new RefreshIndicator widget to be used with SliverAppBar. - #105769
elbeicktalat wants to merge 10 commits into
Conversation
|
Self-pinging to put this in my inbox for review. Thank you for putting this together. It looks like the failing tests are either broken doc references, analyzer issues or an issue with the sample code you are adding. It sounds like this PR is really two features as described above. Can this be split into two separate PRs then? It makes it easier to review, but more importantly, if 1 of 2 features causes an issue, it will be reverted, meaning both would have to be reverted rather than just the one. |
|
I think it doesn't make sense splitting this in two PR. since they are related to each other. In the end, if you see that essential splitting this in two PR. then I'll do it. Thank you! |
Piinks
left a comment
There was a problem hiding this comment.
Can you see about resolving the failures below first? Then we can give this a proper review.
Also, the sample code you have written requires tests to ensure it works as expected. Those tests can be found under examples/api/test.
Thanks!
| childCount: 20, | ||
| (BuildContext context, int index) { |
There was a problem hiding this comment.
This is causing one of the analysis failures the named parameter should come after the builder.
| childCount: testListLength, | ||
| (BuildContext context, int index) { |
| /// When the user scrolls past [refreshTriggerPullDistance], | ||
| /// this sample shows material pull to refresh indicator for 1 second and | ||
| /// adds a new item to the top of the list view. | ||
| /// | ||
| /// ** See code in examples/api/lib/material/refresh_indicator/sliver_refresh_control.0.dart ** | ||
| /// {@end-tool} |
There was a problem hiding this comment.
This is causing some of the failures as well. Can you check that the sample code follows the same pattern as other samples? It is throwing an error.
| /// * [CustomScrollView], a typical sliver holding scroll view this control | ||
| /// should go into. | ||
| /// * [RefreshIndicator], a Material Design version of the pull-to-refresh | ||
| /// paradigm. This widget works differently than [SliverRefreshControl] |
There was a problem hiding this comment.
There does not appear to be a class with this name, this is one of the docs failures.
| /// | ||
| /// See also: | ||
| /// | ||
| /// * [SliverRefreshControl], A sliver refresh control, that reflects the standard Material pull-to-refresh behavior. |
There was a problem hiding this comment.
Same here, this does not exist.
| // Flutter code sample for SliverRefreshIndicator | ||
|
|
||
| import 'package:flutter/material.dart'; | ||
|
|
There was a problem hiding this comment.
The failing framework test shard is due to this sample code see logs below:
The following TestFailure was thrown running a test:
Expected: exactly one matching node in the widget tree
Actual: _WidgetTypeFinder:<zero widgets with type "WidgetsApp" (ignoring offstage widgets)>
Which: means none were found but one was expected
When the exception was thrown, this was the stack:
#4 main.<anonymous closure> (file:///tmp/flutter%20sdk/examples/api/integration_test/smoke_integration_test.dart:2457:9)
<asynchronous suspension>
<asynchronous suspension>
(elided one frame from package:stack_trace)
This was caught by the test expectation on the following line:
file:///tmp/flutter%20sdk/examples/api/integration_test/smoke_integration_test.dart line 2457
The test description was:
Smoke test material/refresh_indicator/sliver_refresh_indicator.0.dart
There was a problem hiding this comment.
I would refer to other sample code to see if there is something missing from your case here.
One way to tell is, how does adding |
| Widget build(BuildContext context) { | ||
| return Scaffold( | ||
| body: CustomScrollView( | ||
| physics: const BouncingScrollPhysics( |
There was a problem hiding this comment.
Is this required for this to work? This would not match native scroll physics for folks that want a native look and feel on Android.
There was a problem hiding this comment.
Yes, this is required to create a overscrolling space which is not available the the older versions of android, I don't think that flutter dose include the new behavior of native android.
Is this can be considered as an issue?
|
Also of note, the material version here does not currently match the native behavior. This is the current behavior of RefreshIndicator: Screen.Recording.2022-06-13.at.5.46.35.PM.movAnd this is the proposed sliver refresh here: Screen.Recording.2022-06-13.at.5.43.41.PM.movThe behavior does not look quite right. Can you take a look? This page should detail of the expected behaviors of this widget: |
| const SliverRefreshIndicator({ | ||
| super.key, | ||
| super.refreshTriggerPullDistance, | ||
| super.refreshIndicatorExtent, |
There was a problem hiding this comment.
The material refresh indicator does not occupy any layoutExtent or scrollExtent, see: https://material.io/design/platform-guidance/android-swipe-to-refresh.html#usage
| /// A builder that's called as this sliver's size changes, and as the state | ||
| /// changes. | ||
| /// | ||
| /// Can be set to null, in which case nothing will be drawn in the overscrolled |
There was a problem hiding this comment.
This doesn't seem to be true. It falls back to buildRefreshIndicator in _BaseSliverRefreshControlState.build. Is there a reason you're making this change?
| /// When provided, the value of [progress] must be between 0.0 | ||
| /// and 1.0 (full circle) inclusive. Defaults to 1.0. | ||
| /// {@macro flutter.material.ProgressIndicator.ProgressIndicator} | ||
| const RefreshProgressIndicator.partiallyRevealed({ |
There was a problem hiding this comment.
The cupertino refresh control reveals the "spinner" slice by slice as you drag thus the name (see the gif here: https://stackoverflow.com/questions/29791995/swift-pull-to-refresh). The material circular progress indicator doesn't do the same so partiallyRevealed doesn't seem to accurately reflect the actual behavior.
There was a problem hiding this comment.
Without partiallyRevealed the result will be like:
Screen_Recording_20220614-101128.mp4
As you scroll the RefreshIndicator is being animated.
With partiallyRevealed the result like:
Screen_Recording_20220614-101207.mp4
| } | ||
|
|
||
| class _CircularProgressIndicatorState extends State<CircularProgressIndicator> with SingleTickerProviderStateMixin { | ||
| class _CircularProgressIndicatorState<T extends CircularProgressIndicator> extends State<T> with SingleTickerProviderStateMixin { |
There was a problem hiding this comment.
Is there a reason this needs to be made a type parameter? RefreshProgressIndicator is already a subtype of CircularProgressIndicator.
There was a problem hiding this comment.
Well I have added a new property on the subclass without this I can't access to it. I could cast the super class as the subclass, but I think this is can be useful for the future.
| return SizedBox( | ||
| width: radius * 2, | ||
| height: radius * 2, | ||
| child: FittedBox( |
There was a problem hiding this comment.
The material refresh indicator does not resize when you overscroll I think? If you use a FittedBox here it will expand when the user overscrolls and shrink when the scroll view bounces back.
|
Hi @Piinks,
With the actual structure can arrive to something like: Screen_Recording_20220614-145925.mp4If this doesn't seems to be right, then probably I'll reset The Thank you! |
This breaks the design of the Material indicator, so I do not think we will want to make this change. If there is a way to change this proposal and match the design spec, we can definitely take another look! |
|
For sure I can get out of this issue, but I have to revert a few changes like: having a Base implementation for both iOS and Material. Should I allow Thanks! |
Do you mean CustomScrollView? I am not sure! I would return to the issue you are trying to solve, and see what you think would be the best approach. I do have a proposal tat is almost finished that may resolve this, I would love your feedback on it when it is ready. :) |
|
@elbeicktalat Will you be able to continue working on this? It's totally fine if not; we can take it over (though it might take longer). I'm just asking because I'm trying to clean out our review queue. |
|
Hey @elbeicktalat, I am going to close this PR. I do still have plans to support this without breaking the current spec (#107182 was an earlier proposal), I just haven't circled back around to it yet. |

This PR. introduce a new widget called
SliverRefreshIndicatorwhich is the material equivalent toCupertinoSliverRefreshControl, both widget are subclasses ofBaseSliverRefreshControlwhich holds the shared logic.It is also provide a new named constructor
partiallyRevealedto the existingRefreshProgressIndicator, which allows the gettingRefreshProgressIndicatorbased on passed progress value.Fix #54272
Pre-launch Checklist
///).