drag on handset won't work with grid.fixedRecordHeights: false

[claudiobosticco]

SmartClient Version: SNAPSHOT_v13.1d_2024-10-18/AllModules Development Only (built 2024-10-18)

Safari on iOS (both in XCode simulator and on physical device)
happens also on iOS and Android emulator in Chrome

Hello, please try this test case:

isc.HLayout.create({
    width: "100%", height: "100%",
    canDrag: true,
    dragStart: function () {
        isc.logEcho(isc.EventHandler.getTarget().getID(), "drag start")
        return this.Super('dragStart', arguments);
    },
    members: [
        isc.ListGrid.create({
            ID: "dsListGrid",
            width: "100%",
            height: "100%",

            fixedRecordHeights: false,
            autoFetchData: true,
            dataSource: "supplyItem"
        })
    ]
})

you may see that drag on the grid works on desktop, but handset drag won't start *unless* you remove fixedRecordHeights: false.

Is it expected?

[Isomorphic]

Hi Claudio
Just a note to say we are reproducing this issue and have a developer looking into it. The fixedRecordHeights property should not impact drag interactions.

We are curious about your usage however.
ListGrid has built in support for record dragging. It also supports showing 'drag handles' for touch interfaces where dragging of records might otherwise interfere with scrolling.
These features do not appear to be impacted by fixedRecordHeights:false.

For background, we'd be interested to know what your use case is where you need dragging support for a grid outside of the the built in record drag behaviors, and this support is required on touch interfaces, and whether this is going to lead to problematic interactions with touch-scrolling of the listGrid body

Regards
Isomorphic Software

[claudiobosticco]

Hello, actually, I built a Carousel-type interface that currently works with buttons to navigate forward/backward.
Then I ran into this issue while experimenting with drag (which I don’t have much experience with) on various components to see if implementing swipe on the Carousel is feasible, and whether there might be problems when there are complex components in the Carousel.

Since it's important for me that the Carousel can contain arbitrary widgets at this point, but swipe interaction is not crucial, I’d be happy to hear your thoughts if you see more problems than benefits with this approach.

[Blama]

Hi claudiobosticco,

I think this is what I was thinking about here. Also, the thread starts with screenshots of an app you surly know ;)
Out of interest, could you share a video of your carousel in action?

Thank you & Best regards
Blama

[Isomorphic]

Hi Claudio and Blama,
Two things:

Firstly - we've done some investigation into why fixedRecordHeights impacts the drag events received by the ancestor layout.

What's happening is a consequence of virtual scrolling
Essentially, when listGrid record heights are unpredictable and the grid is not rendering a full set of data (see ListGrid.showAllRecords and related APIs), the grid has to compensate for the fact that as the user scrolls and the grid renders out blocks of records, the heights of un-rendered rows outside the viewport is unknown, so if we relied on standard browser scrolling we'd see odd jumps in scroll height and scroll position as the user attempted to move through the list of records.

The grid therefore enables custom scrolling, and for touch-interfaces where touch-scrolling is enabled, this intercepts and makes use of the drag event.

In your example this means the ancestor layout never receives the event in this case.

We will look at updating our documentation to make it clear that this is a known and expected consequence of virtual scrolling.

Secondly - you have a higher level question about carousel interfaces in SmartClient

"...I’d be happy to hear your thoughts if you see more problems than benefits with this approach."

The problem you hit with drag interaction interfering with swipe gestures would extend beyond listGrids to any components that would react to touch-drag type gestures.

To actually prevent your carousel panes reacting to the swipe gesture intended to rotate the carousel, we'd suggest masking the components in the carousel with a transparent (or translucent) Canvas that has the event handling for the swipe gesture.

Also, to avoid an ambiguous user-experience - is a user intending to scroll a widget or spin the carousel? - you'd probably want to use an approach like "edge based" swiping where the target area for a navigation swipe is limited to a specific area within the pane.

Blama brings up a version of this design in the thread he links above - having swipes start only on the left/right edges of the component.


Lastly, as in addition to the existing SmartClient capabilities, there are some Feature Sponsorship-eligible features we could consider in this area:

- We could add multi-touch support to the framework to make it possible to recognize gestures like multi-finger drag, distinct from single-finger drag. This would allow you to have an unambiguous multi-finger swipe gesture to navigate within this component

- We could create a built-in Carousel component as part of the framework so you get the user interface and features you need in a supported, built-in manner

If you'd be interested in one or both of these, please reach out to us via support@isomorphic.com

[claudiobosticco]

Hello Isomorphic and thank you for the detailed explanation. I think this helps explain why drag on the ListGrid* was working in my application while there were so few records that no vertical scrolling was needed.
However, I’ve noticed that even with fixedRecordHeights set to true but with a cellHeight different from the default, drag stops working on iOS handsets. Is this also an expected outcome?

(*) grid without horizontal scrollbar, where columns cannot be resized or reordered.

Now, about the suggestion,

we'd suggest masking the components in the carousel with a transparent (or translucent) Canvas that has the event handling for the swipe gesture

I’m not entirely sure I understand – it seems like this change might also block any interactivity with the components.

Anyway I do understand the significant limitations of my approach, though currently, I don’t have a need urgent enough to justify further adjustments. Good to know, however, that there might be the possibility of adding features to support a Carousel.

Thanks again!

[claudiobosticco]

Hello Blama , yes, I could share a video, though perhaps privately to avoid needing to blur too many details.

What I can already say is that, although my implementation is quite simplistic and certainly could be improved, the functionality - setting aside the limitations highlighted above by Isomorphic (such as drag not working if something is disabled) - is surprisingly good and very smooth, despite it being based only on position, not also on swipe speed.

Let's say that from this perspective, a video might only partially do it justice, but it’s really satisfying in terms of interaction.