We have received a bug report from a user with our app, and we believe we have an idea where the cause might be.

Our App does a local-datasource set when the user edits a record, it then calls an API on our server and if the results from this API is OK, we perform a datasource sync. 

Sometimes (it is not consistent) - the list-view scrolling gets stuck on an iPhone (we were unable to reproduce in Chrome, did not test it on Android) following one or more of these edit operations.

We managed to recreate the issue with a small sample (remember, you need to test it from a device, it does not happen in Chrome).

http://dojo.telerik.com/aReBU/10

We tried to simulate our app by doing the following:

When we edit, we do a set on the record, wait a random amount of time (to simulate the round trip to our server) and perform a sync on the datasource.

Please notice that to make the debugging easy, you actually do not need to change any values in the edit screen, just press the done button in it - and it will add a suffix to a field which will be set to the datasource and later synced.

It is important to remember to try and scroll the listview once the edit-dialog is closed - and repeat the edit/done/scroll until it gets stuck - it does not happen consistently and sometimes takes us 5 or 6 tries to get it stuck.

We suspect that the issue is related to the sync operation, but are not sure.

Hello Ron,

the sync operation replaces the DOM elements in the listview. This terminates the current touch sequence (as, by spec, the touch events are bound to the originating DOM element), and the JavaScript based scroller is left in an invalid state - the touchend event never gets fired. 

The easiest way to resolve this is to use native scrolling for the listview view - data-use-native-scrolling="true" - please give this approach a try.

Regards,
Petyo
Telerik

Petyo, thanks, 

We tried this suggestion and unfortunately, it did not help. The updated sample with the additional data-use-native-scrolling="true" is available at http://dojo.telerik.com/aReBU/11

At first it did seem faster and smoother but after about 7 times when clicking the Done button the scroller was stuck.

Is there no way to copy that bound events from the old DOM elements to the new ones on Sync?

If there is no way to do it automatically as part of the sync operation - Is there a way for us to manually unbind them before calling sync and manually bind them again after the sync is done?

Another question - if there is no way to unbind/rebind the events manually, is there a way for us to reset the Javascript based scroller somehow? Trying to use the scroller reset method did not help us. Is there a way to place it back in a valid state?

 

Hello Ron,

I checked the dojo provided. The native scrolling is set on the detail view - if I understand you correctly, the scroll was stuck on the list of items view - this is where the native scrolling should be enabled.

Regards,
Petyo
Telerik

Petyo, thanks for the response. 

 

If we understand you correctly, the change is as currently implemented in http://dojo.telerik.com/aReBU/12

 

If so, it does not seem to provide a solution - as we still get the stuck issues, they are actually easier to replicate with this code. Please update us if we missed something in the implementation - otherwise, a suggestion related to our question about unbinding/rebinding the events would be helpful.

Hello Ron,

Please check this version of your dojo. I moved the native scrolling attribute at the view level (the listview does not recognize that). 

Regards,
Petyo
Telerik

Petyo, Thanks. There is some progress, but unfortunately, one step forward, one step back. 

 When testing this version of the dojo on iPhone 5s the scroller was not stuck, but it seems that we lost the click evens handler.

In the first trial we edited 3 items (simply by clicking "Done"; Once clicked you can see the sufix "-X" was added was added to the item). After those 3 edit actions the items lost their click events and I could no longer edit any item. Unfortunately, this is as bad as a stuck scroller as both means the user must restart the app.

In another trial it only happen after the tenth edit operation. So it is not a consistent problem - but still unstable and problematic to release to actual users.

Is there a way to handle this case of click events that are not working while using the view native scrolling? Is there some other solution that will not force the users to restart the app?

Hello Ron,

I am not sure what may cause this - the approach you have taken should work in general and the native scrolling should not interact with the taps. I tested the provided dojo in the native iOS emulator, and successfully edited a lot of items; see screenshot. 

If you don't use the kendo touch events for something else, you may try using the listview click event instead. perhaps this will improve your case.

Regards,
Petyo
Telerik

Hello Petyo,

Thanks for you continued help. As suggested we edited the dojo, removed the touch events and added the listview click event. We performed several tests with this dojo (as before, simply by clicking the "Done" which adds "-X" suffix). The updated dojo is available at http://dojo.telerik.com/aReBU/15 and is based on the dojo you prepared for us earlier.

All our tests were done on a real iPhone 5s device with iOS 8.4 and all the tests ended in the same way: the click event eventually stopped working (which means that even when we clicked an item we stayed in the same view).

In some tests it happened after less than 5 edits while in others we managed to do more edits before the click was lost. The "longest rally" we had involved about 20 edits.

We appreciate your assistance on this matter and look forward to find a solution. 

Thanks,

Ron.

Hello Ron,

I managed to reproduce the problem on my side. It is somehow related to quickly scrolling and stopping the scroller while editing the item. This seems like a bug on our side. I will attach the debug scripts and examine what goes on. The ticket is marked as requiring an additional answer on our side, I will follow you up shortly. 

Regards,
Petyo
Telerik

Petyo, Thanks. We appreciate it.

 

Do you by any chance have an estimate for us - we are getting close to a new release of our App - and want to have some info about timing - to decide if we wait for this fix before our release or not.

 

Thanks,

 Ron.

Hello Ron,

 

I am sorry for the delay; we are quite occupied with the upcoming Q3 release. I hope that I will be able to find a resolution for the problem next week and include the fix in the usual Friday internal build. 

 

Regards,
Petyo
Telerik

Hello Ron,

 

I am glad to inform you that I managed to address the problem (see issue). We are going to publish a Service Pack release this week, which will include the fix.

 

Regards,
Petyo
Telerik

Thanks a lot Petyo!

 

We look forward for the Service Pack release and plan to use it for our coming app release.

Can you please clarify if we still need to use data-use-native-scrolling="true"  for the view or not? (not sure if this fix made any change about that).

Regards,

Ron.

Hello Ron,

I would definitely recommend keeping the native scrolling turned on. It generally performs better in most cases. 

Regards,
Petyo
Telerik

Patyo,

 

Thanks for your help with this issue. We implemented the new build with our app and the issue seems to be resolved in all our tests.

 

All the best,

 Ron.