There's a bug in one of your ListView demos with Hierarchical data binding ( http://demos.telerik.com/kendo-ui/mobile-listview/hierarchical-databinding )
I edited in Dojo ( http://dojo.telerik.com/OPido ) and addded for debug purposes:
requestStart:function(rsp){
console.log(this,rsp);
},
requestEnd:function(rsp){
console.log(this,rsp);
}
I don't know why, but requestStart and requestEnd are fired twice, each. Also the back button doesn't work every time in this case (only on iPhone Safari), and I suspect it has something to do with those doubled fired requests.
Can someone please confirm? I'm using it in production, and it's a big headache for the iPhone users. Thanks!
14 Answers, 1 is accepted
you should not worry about the requestStart/requestEnd firing multiple times - this is due to the parent/child item being fetched upon each view load, in order to support deep linking. However, since the records are already there, no actual network requests are performed.
The back button does not work reliably in the dojo sandbox, however, it should work as expected in full screen mode. You may experience touch sensitivity issues, for which you can try setting the clickOn option to "down".
Regards,
Petyo
Telerik
Rank 1
I found out these days about clickOn option. I had to upgrade from v2014.3.1411 to latest, because it was not present in that version.
It seems to improve button reaction, especially on iOS where it was really bad (using either Safari or Chrome)
Rank 1
It seems clickOn doesn't come only with benefits. It has a downside too. I edited the Hierachical ListView and added data-click-on="true" to the BackButton and strange things happen. On Android but mostly on iOS it fires twice...Basically it goes back twice. So problem not solved. Any ideas?
dojo edited demo: http://runner.telerik.io/fullscreen/uxOwe
iphone: https://www.youtube.com/watch?v=-qLq9o0viwc
ios simulator: https://www.youtube.com/watch?v=sivN9-bdMsU
this seems like a bug of the data-click-on implementation indeed - we need to address it in the source code itself. I am logging it here.
Regards,
Petyo
Telerik
Rank 1
using data-click and navigate seems to be good as a workaround
http://dojo.telerik.com/UVixo
data-role="button" data-click-on="true" data-click="goBack" class="km-back"
function goBack(){
app.navigate("#:back");
}
Rank 1
Another bug related to clickOn
Using alert function triggered by a click event from a button renders all touch unresponsive...
http://dojo.telerik.com/OdURi/3
https://www.youtube.com/watch?v=NzLOaMTZ4y4
Rank 1
*only in iOS
Thank you for the workaround suggested. We still need to investigate the other case, though. Apart from that, the bug you have found is a known one (not specific to Kendo UI). Same happens with the confirm method, too.
Regards,
Petyo
Telerik
Rank 1
the issue should be addressed in the 515 internal build.
Regards,
Petyo
Telerik
Rank 1
Is it included in an internal build?
Also, i noticed the workaround I've been using doesn't work if transition animation is disabled (set to none).
yes, the fix is included in the internal build (515) which I pointed to.
Regards,
Petyo
Telerik
Rank 1
Sorry, I don't know how I overlooked that.
I tried version 521 on desktop browser (Chrome 43) and I stumbled upon some problems.
1. The buttons I use to navigate to home view don't work anymore. ( <a href="#/" data-role="button" data-icon="home"></a> )
- I guess it has something to do with the previous bug where back button didn't work.
- Weird thing is that if I use the home button inside a view, it will work. It won't work if use it in the view header.
2. Buttons with data-click-on used inside Mobile ScrollView will also scroll the view after click is releasedhere is a dojo: http://dojo.telerik.com/EpoWo
the first issue you experience is specific to the desktop browser - the example you have posted works as expected in a mobile device. However, you can use the chrome device testing mode - as long as touch events are emulated, the buttons work as expected.
We haven't explored the second scrollview + data-click-on scenario in details. Notice that the data-click-on behavior triggered is suitable for non-scrollable containers (like the navbar), since it interferes with the scrolling mechanism, like this case. We will log this for future consideration, though.
Regards,
Petyo
Telerik