Swiping effects specific container/multibutton height

37 views
Skip to first unread message

CS

unread,
Aug 10, 2016, 2:51:15 PM8/10/16
to CodenameOne Discussions
If you are experiencing an issue please mention the full platform your issue applies to:
Simulator
Device: iOS and Android

Dear CNO,

instead of trying to explain, I have created a short video which demonstrates the problem: http://cs.ijs.si/CodeNameOne.mov
As one can see, with regard to the element (MultiButton inside a container) that is being pressed to make a swipe is almost always enlarged (in height) when one swipes back to the tab. So please pay attention on which element a swipe is done, since on a swipe back, it is the one which is enlarged.
The structure used is the following:
there is a main tabs component, inside the the first tab (Schedule) there is another tabs component, which has many tabs. Inside each tab there is a scrollable container (layout Y) with one label component at the top followed by many container (boarder layout) components. Each container component consists of one (CENTER layout) MultiButton (there can be also a second MultiButton which has EAST layout ... just to state the reason for container with Boarder layout).

If any other information is need let me know.

The question is ... how do I prevent this "enlargements" to happen on "back" swipe.

Thank you.

Best regards,
CS

Shai Almog

unread,
Aug 11, 2016, 1:05:00 AM8/11/16
to CodenameOne Discussions, computer.s...@gmail.com
Hi,
Make sure the size relevant elements for the selected & pressed UIID's match perfectly to the unselected style. E.g. padding, margin, font etc. must all be identical in all versions of multi-button customization.

CS

unread,
Aug 11, 2016, 7:26:52 AM8/11/16
to CodenameOne Discussions, computer.s...@gmail.com
Dear Shai,

I tried everything ... double checking for identical customizations, removing customization (all of them on MultiButton) etc. nothing helped. After removing piece by piece of changes that I made to the form (in code) I think I found the culprit. The problem is caused by the call of the hideTabs() function. As soon as I removed this call everything worked as expected (no more double sized elements). I would really like to have Tabs element without tab "buttons". Is this something you can easily fix on your part? Or do you know for a good workaround?

While testing swiping on iOS I noticed an "ugly" feature. If I pull down the content of the tab (like pull for refresh) and at the same time swipe to the next tab, when I go back to the tab, the content stays at the same position as it was during previous swipe from the pull (but it should go up). The same can be observed on simulator also. On Android is ok, since I cannot pull down the content. Can I prevent this behaviour on iOS also (pull down, since I do not need it)?

Shai Almog

unread,
Aug 12, 2016, 1:37:00 AM8/12/16
to CodenameOne Discussions, computer.s...@gmail.com
Hi,
I suggest using the Component Inspector tool and reviewing the UIID's in the hierarchy. Try setting one of the UIID's to some other value with the component inspector (e.g. Container) and see if the behavior changes and that way you can pin the specific UIID that might be at fault.

CS

unread,
Aug 12, 2016, 4:24:51 AM8/12/16
to CodenameOne Discussions, computer.s...@gmail.com
Dear Shai,

I am afraid I do not know (not sure) what exactly you want from me. Bellow are the screenshots of component inspector. In first one you see with hideTabs() function called and the second one with no hideTabs() function call (that is the only difference). The difference in screenshots is that the second one contains container with radio buttons (which are actual tabs, which I do not want). And in second case swiping works as expected, while in first one works as shown in video from the first post. It seems like if there are no tabs (first case) the "selected" element tries to "compensate" for the missing tabs (since the extension of the element is about the height of the missing tab), but this might be more of a coincidence. I even tried to change almost all the UIIDs in component inspector to Container (in first case) but did not help (the only difference was in the look of the elements). If I tried to change the UUID of the Tab (in second case) to Container, but it changed immediately back to Tab after the swipe.



 


Best regard,
CS

CS

unread,
Aug 12, 2016, 8:29:51 AM8/12/16
to CodenameOne Discussions, computer.s...@gmail.com
Dear Shai,

regarding "ugly" feature from my second post I did a little more research. I have prepared a short video of demonstration (the same is happening on iOS). When a pointer is being pressed a circle is drawn around it.


You can see, how the content is left in the middle of the screen. And if the swipe is done while the content is being pulled down, the next tab content needs to be pulled down twice for the the pulling to work (see in the first seconds of the video, that I needed to pull twice on "Monday" for actual pull to happen). And if I do that (pull at least once), the content of the previous tab is corrected itself (moved to the top), but if I do not, the content is wrongly positioned. So it seems that the next pull that is done on the tab (that was swiped while pulling) still affects the previous tab and not the current one (this can be clearly seen in video). I hope you can identify the problem and fix it or please provide the information on how can I prevent pulling in iOS.

Best regards,
CS


Shai Almog

unread,
Aug 13, 2016, 2:03:00 AM8/13/16
to CodenameOne Discussions, computer.s...@gmail.com
Hi,
you mixed two separate issues in the same thread. One of them seems to be about focus behavior of an element and the other seems to be about scrolling while sideswiping a tab.

I think we can workaround the latter but I'm not so sure. We normally block sidescrolling when scrolling vertically but since tab swiping is a special case it isn't affected by that block. File an issue on that and we might be able to resolve it.

With the issue with the focus component I'm guessing I'm looking at something other than what you intended in the video. I suggest distilling it to a simple test case where the issue is more obvious.
Reply all
Reply to author
Forward
0 new messages