Closed dorukeker closed 9 years ago
That seems like a great addition here. I'll see what I can come up with in the coming days. Thank you for the suggestion and feel free to ping me if nothing shows up in the next week or so.
I looked a bit deeper into it. The SensorCheck is checking if the objects deviceOrientationData
and deviceMotionData
exists. These objects are already defined in intro.js
. So it will always resolve.
Another thing the SensorCheck runs before the events are fired. So it is not reliable to check if the sensor is supported or the values are available.
I hope this helps.
I looked a bit deeper into it. The SensorCheck is checking if the objects deviceOrientationData and deviceMotionData exists. These objects are already defined in intro.js. So it will always resolve.
Thanks! This has been fixed with 11117c52423e2ae08cecdc314d9c0c18fa1dac54.
Another thing the SensorCheck runs before the events are fired. So it is not reliable to check if the sensor is supported or the values are available.
I should clean this up further. Thanks for pointing this out.
Another thing the SensorCheck runs before the events are fired. So it is not reliable to check if the sensor is supported or the values are available.
I should clean this up further. Thanks for pointing this out.
Actually, I believe the device orientation / motion event listeners are registered before each respective SensorCheck starts.
From src/Core.js:
var control = new FULLTILT.DeviceOrientation(options);
control.start();
var orientationSensorCheck = new SensorCheck(sensors.orientation);
The deviceorientation
event listener is created in .start()
before the SensorCheck
starts. Same for devicemotion
.
Actually, I believe the device orientation / motion event listeners are registered before each respective SensorCheck starts.
Correct. The event listeners are registered before the SensorCheck starts, but not necessarily fired by the browser. In some cases the events fire after the SensorCheck. Since SensorCheck was checking already existing object it was resolving also earlier than it should.
But now you changed the checking logic in the SensorCheck so this is not a problem anymore. It still starts checking before the event is fired but does not resolve. It only resolves after the event is fired.
And regarding the availability check: a pull request is on the way. Lets see if it fits what you had in mind :)
Fixed with https://github.com/richtr/Full-Tilt/pull/6.
Currently there is running a SensorCheck to determine the support for an event on the device. The SensorCheck is checking if the return object from the event exists or not.
I have seen before that in some device+browser combinations there is partial support. In this case the event will return the object but some of the values will be missing. So although SensorCheck will resolve, some of the values will not be available.
For example on some Android devices, the DeviceMotion event will return an object with the AccelerationIncludingGarvity values but not the RotationRate values.
Do you have a plan to add a check for availability. Something like: