Native vs. emulated scrolling

[Roman]

After releasing our first Kendo web app to the public we received a lot of feedback about the listview scrolling having a very bad performance. Some users on older smartphones weren't able to scroll down in an appropriate way at all.

So we decided to switch to native scrolling following this documentation: http://docs.telerik.com/kendo-ui/getting-started/mobile/native-scrolling

Instead of

new kendo.mobile.Application(document.body, { useNativeScrolling: true });

which completely screwed our whole app, we used data-use-native-scrolling="true" for the views.

After the change, scrolling was very performant, but we encountered a strange behaviour of the listviews regarding setting back the scroll position. We tried several ways of resetting the listviews scroll position:

1. via e.view.scroller inside the show() event

The documentation mentioned above states that there is no scroller object when using native scrolling, but in fact there is. So we used e.view.scroller.scrollTo(0, 0) at the end of the show() event.

Problems: several users reported that clicks on listview items were not correctly processed, instead a different listview items click event was executed, leading to the wrong details page.

2. via window.scrollTo(0,0) (as recommended in the documentation)

Problems: when going back using the phones back button, the listview jumps to the top before switching the view. Looks really awkward. Also, the listviews scrolling position is often not set back, it stays scrolled.

3. no scrollTo() at all

Problems: same as 2.


So I have 2 questions:

1. What would be the correct way to handle a view with a listview using native scrolling?

2. Is the abysmal scrolling performance with listviews normal? Even on the newest quad core devices we noticed a huge performance difference to native scrolling. Is there a way to optimize that?

Thanks in advance for any hint on this,
Roman

[Petyo]

Hello Roman,

the documentation you refer to describes the specifics of the application level native scrolling feature. The view native scrolling mode is a different feature. In a nutshell, it uses an element with overflow: auto CSS property set. 

Up to your questions:

1) - the native scrolling view still exposes a scroller object, mostly for compatibility reasons. You may use its scrollTo method. The problem you refer to sounds like an issue we have encountered on Android 4.0.* (or 4.1.*) devices. Please let me know if this is so.

2) The window.scrollTo approach is valid for the application level scroller, so I will not go into further details. The jumping issue sounds strange, though. Can you try to reproduce it in our Dojo?

Of course, the browser native scrolling will always outperform any JavaScript based implementation. However, we offer a JavaScript based scrolling for older devices (Android 2.*, iOS 4, etc.). In addition to that, certain features like pull to refresh, endless scrolling and fixed headers are hard (or impossible) to implement in native mode.

If you don't use those features, I would strongly recommend that you enable native scrolling for your views.

Regards,
Petyo
Telerik