Swipe to replace container

[Maaike]

I have a container with a sort of calendar (TableLayout Container) and currently a next/previous button which animate a new container (replace). I would like to do this by horizontally swiping. The containers should be created dynamically on every swipe (to the next / previous day / week / month, depending on the mode). What is the best way to do this? I was thinking of a horizontal scrollable list, but I don't know if it's that easy to create list components dynamically. 

Detecting swipe and replace the container after swipe is another option. Like in this topic:

http://www.codenameone.com/discussion-forum.html#!searchin/codenameone-discussions/detect$20swipe/codenameone-discussions/bsTSuVLrYho/WNXe6C0cJaoJ

What is the best way to do this and do you have any further tips how to achieve this? Is there maybe another good option?

[Chen Fishbein]

Try Tabs, horizontal swiping is already implemented and you can add Tabs dynamically. 

[Maaike]

Ok thank you! 

Should I add a tab when swiping to the left with insertTab with index 0?

And is it a good idea to always delete the previous tab (performancewise, or better: leave at least three tabs: the current, previous and next)?

[Shai Almog]

Its hard to tell since we haven't done that to such an extent. If you add a lot of tabs you might run into memory/performance issues.

[Maaike]

I tried Tabs and made a build. I have a TableLayout in the Tab. Swiping and scrolling up/down are very slow. Scrolling up/down in the other parts of the app is OK. Is this because of the TableLayout? Especially the scrolling up/down is actually nearly not acceptable.

[Shai Almog]

Its hard to tell.
It might be related to the new Android pipeline, did you try disabling it to see if its related?

[Maaike]

Ok I tried to test several things with / without the new Android pipeline:

- With the new Android pipeline, swiping left/right is a bit quicker. However, scrolling up/down is quicker with the old Android pipeline. 

- With the old and new Android pipeline, swiping left/right is unacceptable slow (on a (I know, old) Samsung Galaxy Tab 2 10.1", it takes a second or two seconds to go to the next/previous tab and on my Asus MemoPad Smart it takes slightly less, but it's still unreasonable slow).

- I used Tabs within Tabs, with one swiping off, and the other swiping on. Only using one Tabs container makes no difference (so Tabs in Tabs doesn't slow it down).

- I removed the Tabs and the swiping, and replaced the container content only with the next/previous button (removeComponent / addComponent). With the old pipeline, replacing the container works ok. However, scrolling up/down is still slow (feels just sluggish, that's why I left html5 app development). With the new pipeline, scrolling up/down is impossible, the app is not reacting anymore and after a while the device comes with the question if I want to close the app because it does not respond anymore. Also (with the new pipeline) replacing the container (from 'Home' to the TableLayout container) is very very sluggish.

This is all happening with a TableLayout container. I use the TableLayout as a kind of calendar. I have a row for every half an hour, from 6:00 to 23:00 (34 rows?). I use two columns, one for the time and one for the content. Every time cell has a label with the time in it. Every content cell has a Container with a BoxLayout. Within it a Container with a BorderLayout with two buttons in it (west and east). I added a screenshot.

Any idea how to make at least the scrolling faster? And if it's possible I also would like to swipe with a reasonable speed.

The other tabs and scrolling in the app work ok. Only this TableLayout container is throwing a spanner in the works.

[Maaike]

Addition: On the Asus MemoPad Smart (Android 4.4), the new pipeline is not working with the above described TableLayout container (the app isn't responding anymore and crashes or asks if it should be closed because it's not responding). With the old pipeline, it's better but still far too slow, especially swiping left/right, but horizontal scrolling is also not acceptable. If you want to have the source for testing purposes for the new pipeline: please tell me. 

Will a table perform better than a TableLayout or is it behaving (almost) the same?

Oh well, I'm using smaller TableLayouts in other parts of the app and they are working OK.

[Joshua Aroke]

I'm experiencing this same issue with tabs

[Shai Almog]

Can you both try invoking this in the init(Object) method and see if it helps:

Display.getInstance().setProperty("paintLockEnabled", "false");

Assuming it does then we should probably change this to be the default from now on.

[Maaike]

On my LG: better, especially the swipe (left/right)! Up/down is good.

On my Asus MemoPad: especially the swipe is MUCH better. However, both (swipe and scroll) are still feeling sluggish (html-like ;)). 

On the Galaxy Tab2: possible to use, but very slow.

Im still talking about the Tab with the TableLayout, the others are OK.

This is all on the old pipeline. The new pipeline is still a big problem (not usable on the tablets). 

[Maaike]

On iOS, it's ok with the standard options (however, ipad is little slower than iphone, especially the left/right swiping + animation).

[Shai Almog]

What do you have in these tabs?
You might need to go over your usage of components and try to optimize your UI so it will work faster on all pipelines.

[Maaike]

In my post on Sep 17 in this topic, there is a description of the slow container: a TableLayout with at least 68 containers, 34 labels and 34 buttons (and more if there are 'activity's' that day). I use the TableLayout in other tabs, these are not slow. But the TableLayout which shows kind of Calendar shows these problems. How can I optimize this? Does a Table have a better performance?

[Maaike]

Hmm ok, I can confirm it's not the TableLayout Container itself, nor the 68 containers etc. When isolating that part, everything looks ok. Investigating now... that's difficult (thought I tried everything now, but it's still fast in my test case, so I'm forgetting things :().

Thanks anyway.

[Shai Almog]

The thing that usually costs here is the multiple layers that need to get repainted. E.g. if you have round corners on a component that means we need to paint the parent every time we paint the round component.
If you trigger a repaint for all individual components (e.g. call repaint(), revalidate etc.) when you don't need to you can trigger a chain reaction where components paint themselves then traverse thru parental hierarchy to paint all the parents which can get pretty expensive.

[Maaike]

That's indeed the problem, but it has something to do with borders. I started a new topic, because it's a different problem.