Our pure JavaScript Scheduler component
Again I am not sure how the zoom project you are doing is coming along and if that will then handle ios zoom in a different way and get around the webkit issues that way.
Two different concepts of zooming here. When I say we'll redo zoom, I mean our internal time axis zooming, and if I understand you correctly - you want this disabled to have native iOS page zoom instead. Meaning, our new zooming would not solve this I'm afraid.
The ideal zoom solution would be the one I sent you the example videos of. ie Where it is just the calendar itself that is zooming rather than the whole web page as per the native ios whole page zoom.
Next best would be the native zoom, but without the crashing!
Yep, glad to see they are engaging to at least some degree. Who knows how seriously they will take it and how helpful they will be. Would be great if they sort it out. Something is not right, that's for sure!
As I said above, it could well be a good idea to add more rows to the example. That way it will definitely crash more "reliably" and Apple then cannot attempt deny the issue nor minimise it...
Thanks,
Nick
Hi Nick,
Tested with 1500 events and 500 rows. It didn't help me to increase crash periodicity, same thing as for simple demo - once per 1-2 minutes of continuous random zooming.
Maybe you have better steps to reproduce?
Btw, I tried to apply CSS tricks that a guy from StackOverflow recommended. It didn't help actually, the problem is still reproducible.
We will continue investigation on our side in parallel with Apple.
I'll defer to Anuj to see if he can think of any ways to make your example crash "better"!
To my amateur mind maybe more rows and events.
For our implementation anything more than 350 or 400 rows causes problems.
Perhaps there are other factor involved.
When we have 900 rows our will crash every single time and not just by zooming, during other operations too.
We removed all the events once to see if it was those, but it was the number of rows that was the determining factor alone really which is both curious and also strangely a bit of a relief in that there is hope. Maybe increase your rows to 1000, 2000 etc and see if it happens more frequently, then you can come back to the number where it stop altogether for what it is worth. With very few rows it won't crash at all.
At first we wondered if it was something we were doing our end but then when Anuj was able to give an example with your demo crashing that ruled that out, so for sure the issues lies somewhere between you guys and Apple. I accept it is tough to debug and find out what is going wrong where and why without their assistance. It is definitely worth chasing down though (we are reliant upon getting it working reliably to have a viable commercial product) and glad to hear you are also investigating too in parallel with Apple and trying things like the CSS suggestions etc to try to nail it. It will be good if the silver bullet can be found. Something somewhere that is not quite right is no doubt causing it.
Sorry!
No, I think we'll need to get Apple's comment before proceeding.
Okay.
I notice also that when it starts crashing a lot, then flicking all other apps up the screen (including safari) helps to reduce the crashing going forward, for a while at least. Everything points to the calendar using resources (either memory or CPU, I'm not sure exactly how iphones work) and then them running out and it crashes. I don't know if there is a memory leak of some sort, or what else it could possibly be. I am not technical myself so I am only guessing but at an amateur level it seems that it could be something along those lines. It would be good if Apple can point straight to where the issue lies. Or is it possible for you to somehow work it out by some sort of process of elimination if it is coming from your side rather than theirs? On the face of it zooming and rendering the calendar should not be a problem as such?
Nick