OK, if you guys think we should really keep it in iOS, that's fine. That being said, we should REALLY either:
- remove the orientation tests from mobile spec (or don't include them in the auto test runs) and let this be a magical iOS only API OR: - add support for this API to all other platforms, and document that it exists and how to use it. On 3/14/12 11:08 AM, "Shazron" <[email protected]> wrote: >According to this, resize event might not be reliable on iOS to detect >orientation change: >http://stackoverflow.com/questions/1649086/detect-rotation-of-android-phon >e-in-the-browser-with-javascript > >In my opinion if we chase a standard but it's not reliable - it's just >going to frustrate users, especially if we take away a feature that is >already working well. > >On Wed, Mar 14, 2012 at 10:55 AM, Filip Maj <[email protected]> wrote: >> My opinion is it should be a W3C spec for it be considered "default >> browser behavior". >> >> The only "specification" for this that I can find is Apple's >>documentation. >> >> On 3/14/12 10:45 AM, "Jesse" <[email protected]> wrote: >> >>>WP7 supports the orientationchange event, and window.orientation stores >>>the >>>current value. >>>I believe this concept was started in early Mobile Safari on iOS and has >>>been cloned in the other WebKit devices. >>> >>>In my mind this is default expected browser behaviour and should be >>>carried >>>through to our implementation, although I cannot find a spec or list of >>>which mobile browsers support it. >>> >>>On Tue, Mar 13, 2012 at 1:07 PM, Filip Maj <[email protected]> wrote: >>> >>>> Pretty sure iOS is the only platform with this implementation. >>>> >>>> On 3/13/12 12:40 PM, "Shazron" <[email protected]> wrote: >>>> >>>> >I just realize the resize event will only work for iOS if we throw >>>>out >>>> >the concept of there being two types of Landscape and Portrait >>>> >(LandscapeLeft, LandscapeRight, Portrait and PortraitUpsideDown) >>>>which >>>> >exist with the current window.orientation. Are the two types of >>>> >Landscape and Portrait only used in iOS, what about BB and Android, >>>>or >>>> >WP7? >>>> > >>>> >On Tue, Mar 13, 2012 at 10:28 AM, Filip Maj <[email protected]> wrote: >>>> >> Certainly works on Android and at least on the Torch (BBs with an >>>> >> accelerometer) >>>> >> >>>> >> On 3/13/12 10:21 AM, "Shazron" <[email protected]> wrote: >>>> >> >>>> >>>Is that what Android / BB does and is reliable and tested? >>>> >>> >>>> >>>On Tue, Mar 13, 2012 at 9:15 AM, Filip Maj <[email protected]> wrote: >>>> >>>> I don't think we need to jump on supporting the new >>>> >>>> (DeviceOrientation/Motion) events in the cordova API right away. >>>> >>>> >>>> >>>> As a first step I would simply remove the tests for >>>> >>>>window.orientation. >>>> >>>> >>>> >>>> As for replacing it: you can attach to the "resize" event on >>>>window, >>>> >>>>and >>>> >>>> compare the screen width vs. screen height to figure out what >>>> >>>>orientation >>>> >>>> the device is in. >>>> >>>> >>>> >>>> On 3/13/12 9:02 AM, "Shazron" <[email protected]> wrote: >>>> >>>> >>>> >>>>>If we go ahead with removing iOS < 4.2 support, the backfilling >>>>of >>>> >>>>>support of the two events in JS can be removed: >>>> >>>>>https://issues.apache.org/jira/browse/CB-93 >>>> >>>>> >>>> >>>>>I'll let others chime in about removing window.orientation in iOS >>>> >>>>>before adding an issue in jira. >>>> >>>>> >>>> >>>>>If we remove it, here are my recommendations: >>>> >>>>> 1) Remove iOS < 4.2 support in Cordova >>>> >>>>> 2) Write docs regarding what replaces window.orientation, and >>>>how >>>> >>>>>to use the new event(s) to detect simple orientation changes >>>> >>>>> >>>> >>>>> >>>> >>>>>On Tue, Mar 13, 2012 at 8:40 AM, Shazron <[email protected]> >>>>wrote: >>>> >>>>>> The iOS window.orientation and orientationchange event items >>>>(which >>>> >>>>>> are not W3C, and has been in iOS since 1.1) was to support >>>>these >>>> >>>>>> features in a UIWebView which came for free in Mobile Safari. >>>> >>>>>>Apple's >>>> >>>>>> description is here: >>>> >>>>>> >>>> >>>>>> >>>> https://developer.apple.com/library/ios/#DOCUMENTATION/AppleApplicati >>>> >>>>>>on >>>> >>>>>>s/ >>>> >>>>>>>>>>Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#//a >>>>>>>>>>pp >>>>>>>>>>le >>>> >>>>>>_r >>>> >>>>>>ef >>>> >>>>>>/doc/uid/TP40006511-SW16 >>>> >>>>>> >>>> >>>>>> Apple already supports the DeviceMotionEvent and >>>> >>>>>> DeviceOrientationEvents in iOS 4.2 (which we backfill support >>>>for >>>> >>>>>> older iOS versions) and those are W3C drafts are I believe. >>>> >>>>>> >>>> >>>>>> >>>> http://www.mobilexweb.com/blog/safari-ios-accelerometer-websockets-ht >>>> >>>>>>ml >>>> >>>>>>5 >>>> >>>>>> >>>> >>>>>> Also those two events are not exact replacements for >>>> >>>>>> window.orientation - we would need to have to have equivalents >>>>/ >>>> >>>>>> educate users on how to map the event values to the appropriate >>>> >>>>>> window.orientation ones. >>>> >>>>>> >>>> >>>>>> Shaz >>>> >>>>>> >>>> >>>>>> On Tue, Mar 13, 2012 at 8:19 AM, Filip Maj <[email protected]> >>>>wrote: >>>> >>>>>>> Hey all, >>>> >>>>>>> >>>> >>>>>>> In mobile-spec we have a series of tests checking an API >>>>available >>>> >>>>>>>at >>>> >>>>>>>navigator.orientation [1]. From what I can tell / remember, >>>>this >>>>is >>>> >>>>>>>something that we support as a legacy, as neither Android or >>>> >>>>>>>BlackBerry >>>> >>>>>>>have it but I believe there are leftovers in iOS (before >>>>cordova-js >>>> >>>>>>>integration) that still have this API. >>>> >>>>>>> >>>> >>>>>>> I do not think it is based on any W3C spec. The closest thing >>>>I >>>> >>>>>>>could >>>> >>>>>>>find is something the Geolocation Working Group are drafting >>>>up, >>>>an >>>> >>>>>>>event called device orientation [2]. >>>> >>>>>>> >>>> >>>>>>> My thinking is, remove this API completely. It is not part of >>>>our >>>> >>>>>>>documentation and as far as I can tell only iOS supports it >>>>right >>>> >>>>>>>now. >>>> >>>>>>>Instead, set new tasks to implement the W3C deviceorientation >>>>event >>>> >>>>>>>(or >>>> >>>>>>>perhaps come up with a simpler, synchronous API of our own!). >>>> >>>>>>> >>>> >>>>>>> Thoughts? >>>> >>>> >>>> >> >>>> >>>> >>
