Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

[Bug] [SwipeView] Changing SwipeMode changes the width of the SwipeItem #8941

Closed
czuck opened this issue Dec 17, 2019 · 2 comments · Fixed by #9574
Closed

[Bug] [SwipeView] Changing SwipeMode changes the width of the SwipeItem #8941

czuck opened this issue Dec 17, 2019 · 2 comments · Fixed by #9574
Labels
a/swipeview e/3 🕒 3 help wanted We welcome community contributions to any issue, but these might be a good place to start! in-progress This issue has an associated pull request that may resolve it! t/bug 🐛 up-for-grabs We welcome community contributions to any issue, but these might be a good place to start!
Milestone

Comments

@czuck
Copy link

czuck commented Dec 17, 2019

Description

Changing the SwipeMode from Reveal to Execute changes the width of the associated SwipeItem. This is an issue on both Android and iOS.

Steps to Reproduce

  1. Run the SwipeView Demo. Choose the Mode and Behavior page. When set to reveal the image looks like this:
    image

  2. Shange the SwipeMode to Execute, now it looks like this:
    image
    note - I also had to change the SwipeBehaviorOnInvoked to be able to capture the image, but this does not affect the width of the SwipeItem

  3. This issue is even more evident looking at two items:
    image
    image

Expected Behavior

Changing the mode should not change the item itself.

@czuck czuck added s/unverified New report that has yet to be verified t/bug 🐛 labels Dec 17, 2019
@jsuarezruiz
Copy link
Contributor

jsuarezruiz commented Dec 20, 2019

Currently the SwipeView applies different sizes to SwipeItems depending on certain conditions.
Using SwipeItem:

  • If Mode is Reveal, it will apply a fixed width by default. The SwipeThreshold needed to open the SwipeView is 80% of the width of the SwipeItems.
  • If the Mode is Execute, the width of the SwipeView is used. If there are N SwipeItems, the width is divided between each element. That's why in your example, each SwipeItem occupies half the width of the SwipeView in Execute mode.

Then we have SwipeItemView. In this case a View is used and can set a custom width. So, the SwipeThreshold is 80% of the width.

We can avoid this problem in several ways:

For now, you can use the Execute Mode with SwipeItemView and define the width you need. In this way I am sure you can achieve the desired result.

@jsuarezruiz jsuarezruiz added a/swipeview e/3 🕒 3 and removed s/unverified New report that has yet to be verified labels Dec 20, 2019
@czuck
Copy link
Author

czuck commented Dec 20, 2019

@jsuarezruiz my concern with this design is with a single item, the user has to swipe about 2/5 the way across the screen before there is any indication of what the swipe does. The first few times I tested this I didn't see the item because I didn't swipe far enough. Then there is a much smaller distance past the item that the user can move before the action is executed. When a second item is added, the second item is never visible because the maximum swipe pull, which looks to be about 2/3 the width of the SwipeView, is not enough to reveal the second icon. To fix this issue I would use the maximum width of the swipe reveal rather than the width of the full SwipeView to determine the width of the SwipeItems.
My personal preference would be to position the SwipeItem at the edge of the SwipeView rather than the center so when the user starts their swipe they see that something is there. They can fully reveal the item without triggering the action, but swiping a particular distance past the item causes the execution. If there were two items the items would be stacked together similar to the reveal layout with the extra swipe area following the last item. Perhaps this could be an optional layout parameter?

Icon is revealed, action is not executed:
image
Swipe continues, now the action is executed (Bold is removed from the title):

image

@samhouts samhouts added the in-progress This issue has an associated pull request that may resolve it! label Feb 13, 2020
@samhouts samhouts added inactive Issue is older than 6 months and needs to be retested help wanted We welcome community contributions to any issue, but these might be a good place to start! up-for-grabs We welcome community contributions to any issue, but these might be a good place to start! and removed inactive Issue is older than 6 months and needs to be retested help wanted We welcome community contributions to any issue, but these might be a good place to start! labels Jul 17, 2020
@samhouts samhouts added inactive Issue is older than 6 months and needs to be retested help wanted We welcome community contributions to any issue, but these might be a good place to start! and removed inactive Issue is older than 6 months and needs to be retested labels Jul 31, 2020
@samhouts samhouts added this to the 5.0.0 milestone Aug 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a/swipeview e/3 🕒 3 help wanted We welcome community contributions to any issue, but these might be a good place to start! in-progress This issue has an associated pull request that may resolve it! t/bug 🐛 up-for-grabs We welcome community contributions to any issue, but these might be a good place to start!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants