Vertical ScrollView in web app build

#1

Vertical list scrolling doesn’t appear to work in a webapp build viewed on my Samsung.

I was hoping that webapp views would behave like the mobile view does in the simulator app on my phone but vertical scrolling affects the entire page (even though I have scrolling disabled at the page level).

Is this a known issue?

BTW, horizontal scrolling in rows nested inside a vertical scrolling list DOES work in a web app build … with the exception that vertical scrolling attempts scroll the entire page in which the rows horizontally scroll.

#2

Answered here: Adding a non-REST data resource

But I started to think that if after you try to limit Scroll view size in some ways scrolling still doesn’t work, send a few screenshots of the configuration here and maybe share your app ID so I could see if I can figure out a way to make this work (I such exists to begin with which I think it does)

1 Like
#3

Thanks! I’ll give that a try. Maybe I can do that via percentage-based dimensions since I want this to be multi-device.

I don’t actually know where the appID is but I’ll look for it and share.

#4

:+1: Let’s hope you’ll find a solution

App ID is part of the Composer URL when you have the app open: Where can I find my APP ID

#5

Thanks! Great to have such fast and on-target responses!

I’ll find the appid and add it to the thread today.

#6

Tried an 80% height on the scrolllist container with no obvious effect on the webapp build … but I’m wondering if the webapp builder is using my latest saved version in Composer? … and how to tell?

The build seems to show a list of historical builds but only shows the Composer version used … not the app version and no date time stamp on the builds.

Might be very helpful to have those. :slight_smile:
My appID is 159674

#7

Having built a few now I see the list is “latest build first” and adds a “queued” label for pending builds. Good … but the detail would be better, I think.

Regarding the container limit, that seems to have fixed the whole page scroll problem in the desktop preview … but at the cost of dropping out the last x of 13 items in my list; x being dependent on vertical height of the display area of the device … and had no effect on the desktop latest build view which still scrolls the whole page.

So, it seems there’s some interplay of container height, scroll list height, and device display. This makes sense since they are percentages of percentages of a variable … but it makes it tricky to understand and control the scroll list’s ability to actually show all items on the list.

Probably needs some attention.

Next step is to set the list ietms’ height to percentage as well … and then remove the empty container at the end of the scroll list (suggested elsewhere as a fix) and try to sort out the interplay of these settings.

Thanks for you responses!
Cheers :slight_smile:

#8

Ahhh…some accidentally found info!

If I scroll the whole page in the webapp preview, the scrollist shows all items in the list.
If I DON’T scroll the whole page view, the scroll list truncates as noted above.

So the items are “there” … but the scroll list doesn’t scroll completely unless the whole page is scrolled.

This is the case on the Composer desktop preview of the webapp.

Checking on mobile webapp…

#9

I should add that these are minor difficulties within a Composer system that is, in my view, INCREDIBLY well-conceived and executed … and it seems some easy tweaks can be made to make it even more seamless in deployment across devices/OS’s!

Really…thanks!

#10

The mobile version of the latest webapp build with container %height. on my Samsung Galaxy scrolled the first 12 items … so one item short.

Waiting on the build that has both container AND scroll list %height.

#12

So, the bottomline seems to be that setting the percentage height in the scroll list container and/or the scroll list itself SORT OF fixes both the missing items in the list AND the list scrolling problem … but with a consistent caveat:

The list will scroll to its the last row of a truncated list in the display (whether desktop preview from Composer, Appgyver preview app preview, or mobile build) but when the end of the truncated list is reached continued scrolling affects the whole page and missing rows come into view.

On the desktop build, the whole page still scrolls if there’s no empty container at the bottom of the scroll list.

I’ll work with this more tomorrow to see if the percentage height setting for the scroll list affects how many row items are seen before the whole page scrolls to reveal the rest.

#13

I’ll attach the results on my Samsung with the current app design. It varies between the Preview app view, the built view of the same webapp in Chrome, and the built view of the same webapp in DuckDuckGo.

#14

Here’s the recording of the webapp on my desktop in Chrome:

#15

The latest update:

After some hours had passed, the above-recorded variations of things like viewable scroll list size went away (maybe a propagation timing issue? I had cleared my cache before loading and recording the webapp above. I’m in Bulgaria so maybe there’s some sort of lag in the built version propagaing across servers??) and things became pretty consistent.

The Appgyver app selector preview on mobile behaves as intended with the scroll list scrolling within a stationary page.

The built webapp in the browser and the Composer preview scroll a partial list first then scroll the whole page to display the rest of the list.

Recordings attached.

Desktop: https://drive.google.com/file/d/1SYwEBSM-eVbFvRz3spXLd9rSM9wYL6sL/view

Mobile:

#16

I see what you mean, mate. Basically, long story short, Disable Scroll doesn’t seem to work for web apps. Scroll view components don’t seem to work in either Web Previews (including beta). But I have found that a regular container with overflow set to Scroll will work in the beta Preview only. So that’s some encouragement when all you’re trying to do is make a floating header.

I think the primary problem is that Appgyver does not respect Disable Scroll being checked and lock the page to the dimensions of, say, my web browser page. If it did, I believe it would work properly. Here’s to hoping they can get it figured out soon.

#17

Hi! Disable scroll works in 2.4.10 and newer! I tested disable scroll and a scroll view in 2.4.16 web just now and I had no trouble, so please check again on https://preview-beta.appgyver.com if the scrollview would work for you now :slight_smile:

#18

Terminology:
Master scrollbar: The overall page scrollbar, similar to what you see to the right of this forum page.
Child scrollbar: The scrollbar rendered in the scrollbar.
Tested in Preview Beta.

Correct me if I’m wrong, Mevi, but doesn’t Disable Scroll remove the ability for the page in question to ever generate a master vertical scrollbar? Presumably, any overflowing content below is simply cut off, yes?

So I should be able to set my custom header container and a scroll view underneath it (both relative), set an exact height for the header, set both dimensions of the scroll view to 100%, and the page would be forced to render to fit both components in the available browser screen space for Chrome, in this case.

The issue that remains is the double scrollbar syndrome in which both the master and child scrollbars are simultaneously rendered such as (just tested now):

Screenshot 2020-12-08 102704
Screenshot 2020-12-08 1027041920×940 110 KB

As other users have discussed, full-page scrolling issues come with this. To be fair, you could set exact dimensions to the scroll view and somewhat fake it within the dimensions of your browser. But as soon as you adjusted the browser window size or add another toolbar, for example, to Chrome, the same problem persists.

BUT… that may be old news as I’ve improvised a stable solution just this morning.

  1. Set the header to Absolute.

  2. Set a higher z-index, if necessary, for the header container.

  3. Set both dimensions of the scroll view to 100%.
    • The scroll view will now render underneath the header, including its content.

  4. Set upper padding for the scroll view to force its UI components visually below the header. In our case, 60 padding worked. Experiment.

Result: The page renders correctly for the most part. Curiously, the child scrollbar for the scroll view renders properly “below” the header, as it should, rather than “below” as in the top portion of scrollbar showing up hidden under the header.

You get something like the following image with a single scrollbar and a floating header:

Screenshot 2020-12-08 105137
Screenshot 2020-12-08 1051371917×940 114 KB

It even respects browser window size changes, although it can flicker between double scrollbars rendering and a single scrollbar with extreme vertical compression. But little things like a slightly smaller PC screen or having another toolbar visible in your browser won’t throw it out of whack.

Scrollview does not end correctly
Containers and Overflow scroll?
#19

Oh, hmm. I haven’t tried the scroll view without using the navigation menu, which is what might cause the difference. Good that you got it working for you and thank you for sharing your findings for me to investigate and for any others to have a look at!

1 Like
#20

I was under the impression almost everyone did away with the default navigation menu from the get-go as they could design something infinitely more visually appealing for a header. But I suppose you might use it for getting around quickly between pages in the Preview since the Beta version does not yet respect an initial loading page being set in the Navigation settings, unlike the older Preview.

In fact, that might explain why scrollviews have never worked for me in the old Preview, now that I think about it. Hmm.

Well, happy to give some food for thought and, for the time being, I believe that solution could solve a lot of folks’ problems with custom headers and page-scrolling issues.

2 Likes