#2208 Add interactive dragging to .anytypeSheet

[stansidel]

---

• I understand that contributing to this repository will require me to agree with the CLA

---

Description

This PR adds interactive dragging capability to .anytypeSheet used for popup like presentation (object settings for example). It should fix #2208.

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI

Related Tickets & Documents

#2208

Mobile & Desktop Screenshots/Recordings

Screen.Recording.2024-10-15.at.7.36.48.AM.mov

Added tests?

• 👍 yes
• 🙅 no, because they aren't needed
• 🙋 no, because I need help

Added to documentation?

• 📜 README.md
• 📓 tech-docs
• 🙅 no documentation needed

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[stansidel]

I have read the CLA Document and I hereby sign the CLA

[mgolovko]

@stansidel thank you for your help!

There are some issues that need to be improved:

• AnytypeSheet doesn't have to add DragIndicator. The screen adds it if necessary.
• The screen size should not change.
• The keyboard is not handled.
• We expect that dragging will work anywhere on the screen and will not conflict with horizontal scrolls inside the screen.

Case.1.mov

Case.2.mov

[ignatovv]

I have updated the issue with richer details from @mgolovko comment

[stansidel]

@mgolovko Thank you for reviewing my PR and making suggestions. I'll make sure to work on the improvements soon.

[stansidel]

I've made the following changes to the PR:

• Removed DragIndicator from anytypeSheet.
• Added DragIndicator to ObjectSettingsView.
• Fixed an issue where the bottom sheet height could change while dragging in certain cases.

I would appreciate more clarification regarding the two remaining improvements:

• Keyboard Handling: Could you provide more details on the expected behavior when the keyboard is visible?
• Drag Behavior: We expect that dragging should work anywhere on the screen without conflicting with horizontal scrolls inside the sheet. Could you explain how you envision this interaction?

To assist with comparison, I’ve recorded and attached the following:

anytypeSheet vs. Default SwiftUI sheet Dragging Behavior:

Recording with scrollable content inside the bottom sheet using anytypeSheet:

scrolling-fullscreen.mov

Recording with scrollable content inside the bottom sheet using the default SwiftUI sheet:

scrolling-sheet.mov

Dragging with Keyboard Visible:

Recording using anytypeSheet:

keyboard-fullscreen.mov

Recording using the default SwiftUI sheet:

keyboard-sheet.mov

@mgolovko, could you kindly describe your expectations for the bottom sheet’s behavior in these two scenarios?

[joe-pusya]

Hey @stansidel thank you for your work! I just had a look on your implementation/comments and would like to answer on it:

About drag gesture - we would like to avoid clashing between any other gesture (taps, scrolls (ideally scrollview too) and other).
What I mean by examples:

Our anytypeSheet implementation problems:

1. When you finger goes down and then up - sheet closes, you should understand the direction of dragging
2. When you clash with another gesture (tap for example) anytypeSheet becomes non-interactive and just closes at the end
3. Scrollview inside anytypeSheet -> interaction doesn't work I think so
   https://github.com/user-attachments/assets/9af4e7c6-2ca5-4bc6-8c69-35e0b0182f3e

SwiftUI sheet behaviour to compare (I didn't understand your examples with it, can you please explain what do you mean?)
https://github.com/user-attachments/assets/8f627a3c-3354-4b11-8182-2ecac4ab3c3f

[stansidel]

Hi @joe-pusya,

Thank you for your comments. I guess I used the native sheet incorrectly in my examples because, in my implementation, there was a visual effect of the views in the background getting narrower.

As I see in your example of the native behavior here https://github.com/user-attachments/assets/8f627a3c-3354-4b11-8182-2ecac4ab3c3f, it works just like you'd expect the custom implementation to work. Could you please explain then what are the goals of using a custom implementation of the sheets over the native one as demonstrated in the video you provided?

[joe-pusya]

Hi @joe-pusya,

Thank you for your comments. I guess I used the native sheet incorrectly in my examples because, in my implementation, there was a visual effect of the views in the background getting narrower.

As I see in your example of the native behavior here https://github.com/user-attachments/assets/8f627a3c-3354-4b11-8182-2ecac4ab3c3f, it works just like you'd expect the custom implementation to work. Could you please explain then what are the goals of using a custom implementation of the sheets over the native one as demonstrated in the video you provided?

It's just because of design request) The main goal is to implement floating sheet (clear space under the content, proper design like round corner and not stacking behind screens) with native swiftui sheet capabilities