Scrolling UI with a editable BrowserComponent (passing touch events beneath)

[P5music]

I have some troubles with the scrollable feature of Containers when a BrowserComponent is involved, especially on simulator.

I can have some good functioning on Android if I assign a large height to its content.

In certain cases the BrowserComponent takes all the space in the UI.

My app has an editing screen that has some controls on the top part, and a BC on the bottom part.

The UI scrolls but when I start writing into the BC it takes all the space and it is not possible to scroll back or to see or regain control of the top part of the UI.

I would like to pass the touchmove events to the underlying Container.

It is a special event that I use along with touchstart and touchend to ensure the scroll events are filtered, but it is used in another BrowserComponent.

Now I want to use it to create a smooth user experience for this BC, passing it in a transformed form to the underlying Container. So I am not going to pass it directly.

I just want to know what method I have to call on the main underlying container to make it scroll.

Thanks in advance

[Javier Anton]

I think this has been discussed before. BrowserComponent is meant to be used in the center of a BorderLayout Form. Avoid mixing it with other components other than a toolbar. If you want to add stuff next to your BC, add it in the html and pass callbacks

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/dbbb198e-68ca-4b21-aa2b-0a98411769cbn%40googlegroups.com.

[P5music]

@Javier

of course it is in the CENTER of a BL, just there is something NORTH too. Do not worry.

It has also callbacks inside, like you say.

The question is now how to allow the scrolling back when the touch keyboard has scrolled the UI too much.

Regards

[Javier Anton]

Right, so what I meant is that there can only be 1 BC in CENTER, and nothing anywhere else in the BL. You can't safely scroll a BC, the scrolling is in the BC itself

This is accurate as far as I know

To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/9ea2af3a-6200-4284-9362-6c136f8518fdn%40googlegroups.com.

[P5music]

@Javier

It is enough that the UI scrolls, not the BC content, its height is set at large so it seems very large.

The user just can touch inside it to set the caret position when editing.

About what you meant about the BC being alone it is not necessary.

However what I meant is that

when the user edits inside the BC the touch-keyboard appears and the NORTH part is lifted up and it is lost at sight, so the user has not any area to drag to scroll back. But the scrolling works before it happens.

In Android two scrolling areas are certainly possible, and one can be used when the other has reached its limit.

I know this is not possible with CodenameOne.

I am assessing whether my app can be published. There are also some checks about the filesystem that would be possible only in the iOS simulator, I do not know when that new CN feature is available. I am finishing my Swift project, at least for iOS 14>.

Regards

[Shai Almog]

Make the container in the north scrollable on Y axis e.g. northContainer.setScrollableY(true).
Make sure it has a layout such as BoxLayout Y.

[P5music]

I tried what you suggest, even it is not what I meant.

As expected it does not work, because the container in the north position has not to scroll inside itself.

Also my idea was not good in the original form I proposed above, so this is the new version:

I think that the scrolling of the entire BL (mainContainer) has to happen, in fact it happens even with scrollableY=false.

Now I put true but it is the same.

The text inside the BC has some strange scrolling, for example if the caret is on the bottom (so there is a lot of text above that has scrolled inside the BC) I can scroll back touching on the beginning of the text, and it scrolls at chunks. Better than nothing.

But If I am in landscape mode, it is the container in the north that is lost at sight.

It is why I would like to pass the touch move events to the underlying mainContainer.

Of course they would be filtered and they would pass only when the BC is in the very top scroll position, otherwise they would be used to scroll the BC itself.

Is it possible?

[Shai Almog]

Scrolling can only be handled by one element. The browser component is native so only it can scroll. That's why it's in the center of the form. Center is a special case where scrolling is disabled and size is determined by available space. So native scrolling in the BC takes over.

If you add Codename One based scrolling they'll collide and you'll get a jumping mess that looks and feels awful. It's an either/or situation.

[P5music]

I solved the Layout problems by getting rid of the BorderLayout because in my particular case it is not needed.

Indeed I set the preferredHeight of the BrowserComponent and of its content to a large value.

Now it is added to a BoxLayout.y() and the user can scroll the entire interface,

but it seems that the scroll is lost if the other components goes up too much and just the BC is visible.

I do not need the scrolling in the BC at all, but I would like that the user can scroll the entire interface even if the only visible component is the BC and the other ones are up too much.

Is it possible to disable the BC scrolling effectively? (setting the scrollableY has no effect)

It is not in a BorderLayout, so it has not to take over at all like you say, it is not needed.

Thanks in advance

[Shai Almog]

There's setNativeScrollingEnabled(false) on the browser component but it's designed for small snippets of browser component not for large ones. Not sure how well it will behave in a larger case.

[P5music]

I checked the code and that line is already present 

setNativeScrollingEnabled(false)

It seems that the problem is in fact the touch keyboard:

it appears not only when tapping inside the editable area

but

also when scrolling

so that the keyboard appears and the BC does not scroll as expected in the layout. 

Coud it be an issue?

[Or maybe it would not scroll anyway.

This leads to my originas question]

1- Any possible solution or workaround for the issue of keyboard appearing when scrolling?

My only idea is to stop the scrolling at a certain point so it is not complete 

and a piece of the other UI is always available for the user as an "handle" to scroll back.

2 - Is it possible to achieve it in an elegant way with containers and things like that? Or with some workaround?

Regards

[Shai Almog]

I don't follow. What causes the keyboard to appear?
If there a text component within the browser component? Outside of it?

[P5music]

Yes, as said in my previous message, the BC is editable. The keyboard appears when the user taps into it to write

but

it appears also when trying to scroll the BC to scroll the entire UI.

The BC is not inside a BorderLayout, instead it is inside a BoxLayout.y

The trick is that the BC has a large preferred H so it scrolls together with the other UI parts, when scrolling outside of the BC.

If the user tries to scroll from the inside of it, the touch keyboard appears.

It is wrong in all scenarios I think.

In particular it is wrong in my scenario where I want that the user can scroll the UI.

1- Any possible solution or workaround for the issue of keyboard appearing when scrolling?

This was the first question, it is about the issue of the keyboard appearing.

This is another question, it is about the scrolling:

2 - My idea is to stop the scrolling at a certain point

and a piece of the other UI is always available for the user as an "handle" to scroll back. The BC is at bottom, the other components are at top.

Is it possible to achieve it in an elegant way with containers and things like that? Or with some workaround?

I mean, I want that the scroll stops before all the other components are "gone". Let's say that a small area, like 1 cm, remains visible, no further scrolling possible.

Please have a look to the attached images: the first image to see is named "landscape_mode", the second image is named "scrolled_UI_lanscape_mode".

Regards

[Shai Almog]

I don't think there's a solution for that. I suggest rethinking your UI design so the BC is in a single form. Notice that a lot of native apps also take that approach because it's REALLY hard to distinguish swipes from edit actions. That makes the process inconvenient to users. Just have them click to edit and move to a form where the BC is in the center of the form.

[P5music]

Don't be concerned for native apps, they work, for example the Android counterpart of my CodenameOne app itself is not affected by this issue without any workaround.

Back to the CodenameOne world, what about the question n° 2?

I will break down the request:

first of all, forget the BC, imagine it is not even in the layout, now my request is:

-how can I stop the scrolling of the BoxLayout.y with buttons

so that

a line of buttons remains visible when the user has scrolled down the entire UI?

I think it is not impossible, I asked here also for other developer's help. Please check  attachments in my previous message.

But I think in the end I will have an idea.

If it not feasible I can ponder on disabling the landscape mode of my app on phones, but this would a serious limitation.

If you know an elegant way with containers please tell me. Or even a workaround.

Thank you

[Shai Almog]

Just place the buttons outside of the scrollable container I don't understand the problem.

E.g. a south container in a border layout where the box layout Y is scrollable and in the center.

[P5music]

If you read the messages and look at the image attachments you understand that the user interface has its layout as carefully designed.

You agree that I am asking that those buttons are in the scrollable area just because they will be used as an handle to scroll.

If I prevent all buttons, or some of them, from scrolling there is no room for the BC in landscape mode.

So what you say is totally off track.

I cannot explain things better than this.

I have the constant impression you are kidding, but rather you are deceiving yourself.

But I have to finish this app as a fallback for iOS<14 (provided that it works correctly in the iOS simulator for certain things still to be checked), so whatever. I will find something by myself.

Regards