Skip to content
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

RefreshContainer is not intuitive to use as a user (not developer) #15529

Open
gentledepp opened this issue Apr 26, 2024 · 5 comments · May be fixed by #17496
Open

RefreshContainer is not intuitive to use as a user (not developer) #15529

gentledepp opened this issue Apr 26, 2024 · 5 comments · May be fixed by #17496
Labels
bug enhancement help-wanted A contribution from the community would be most welcome.

Comments

@gentledepp
Copy link
Contributor

Describe the bug

If the RefreshContainer is configured to refresh with PullDirection.TopToBottom and contains a list,

  • you have to drag the first list item down to initiate the "refresh"
    truncation

This is counterintuitive to most users.

Also: You have to klick into the list first (i.e. select an item of the list in the ControlGallery/RefreshContainer sample).
Then, with the second click, you can finally start the "pull2refresh" action:
truncation

To Reproduce

Run the ControlGallery app on iOS/Android and go to the RefreshContainer sample.
Try to refresh.

It took me very long (including looking up the code on github) to finally figure out that the first list item has to be dragged.

Expected behavior

On Android/iOS the behavior is typically as such:

Instead of having to drag down the first item of a list,
you can drag down on any part of the RefreshContainer.
If the list is not scrolled to the top, the this gesture is interpreted as a scroll gesture => the list scrolls up
If we are scrolled to the top of the list alreaedy (when using PullDirection.TopToBottom), the "refresh" logic kicks in.

truncation

This can be easily implemented by allowing to override the "canpull" in PullGestureRecognizer
image

And then overriding this in the ScrollViewerIRefreshInfoProviderAdapter:
image

Also, a list item should only be selected on "pointerUP", not on "pointerPRESSED". Because then, you do not have to

  • first select a list element
  • then drag it to start the "refresh" logic.

Avalonia version

11.1

OS

No response

Additional context

No response

@maxkatz6
Copy link
Member

This behavior might be different on mobile with touch. But valid points, nonetheless.

@gentledepp
Copy link
Contributor Author

I just checked on Android (since the iOS deployment is broken #14933) and the behavior is absolutely the same.

We cannot use this container because our users will not understand why refreshing is not working (as it only does if you pull down the very first item of a list)

Please consider providing the requested override mechanism so we can at least fix it ourselves in our projects.
I am willing to create a PR with those virtual methods if you approve :-)

@timunie
Copy link
Contributor

timunie commented May 23, 2024

@gentledepp I think I like your previous idea shown in Expected Behavior, where each item can be refreshed when list is at top. A PR for final review would be appreciated.

@timunie timunie added the help-wanted A contribution from the community would be most welcome. label May 23, 2024
@gentledepp
Copy link
Contributor Author

Sure thing. But please understand that before I can work on these fun thing, I need to somehow fix #14933 first.
Withot iOS, AvaloniaUI does not make sense to us :-|

@nickodei
Copy link
Contributor

nickodei commented Nov 3, 2024

Hey, I would be down to implement this improvement. Since @gentledepp didn't create a PR since now, I would guess that there is no work done on it

@nickodei nickodei linked a pull request Nov 13, 2024 that will close this issue
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug enhancement help-wanted A contribution from the community would be most welcome.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants