incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce Curtis <curtis.br...@gmail.com>
Subject Re: navigator.orientation API + tests
Date Wed, 14 Mar 2012 19:45:02 GMT
We definitely need to test WebSQL + storage since not all platforms
(Android) can use built-in, but need our implementation.

On Wed, Mar 14, 2012 at 1:59 PM, Filip Maj <fil@adobe.com> wrote:

> We already have tests for localStorage + sessionStorage. Our docs also
> have websql in them. For consistency, should add websql storage tests.
>
> On 3/14/12 11:48 AM, "Jesse" <purplecabbage@gmail.com> wrote:
>
> >I'm cool with removing the tests.
> >Should we test for other polyfils? WebSQL? localStorage? console.log?
> >
> >Here is a good write up on some of the inconsistencies with orientation
> >[1]
> >And a test page [2]
> >
> >[1]
> >
> http://www.matthewgifford.com/2011/12/22/a-misconception-about-window-orie
> >ntation/
> >
> >[2]  http://www.matthewgifford.com/tests/orientation/
> >
> >On Wed, Mar 14, 2012 at 11:14 AM, Filip Maj <fil@adobe.com> wrote:
> >
> >> 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" <shazron@gmail.com> 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-pho
> >>n
> >> >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 <fil@adobe.com> 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" <purplecabbage@gmail.com> 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 <fil@adobe.com>
wrote:
> >> >>>
> >> >>>> Pretty sure iOS is the only platform with this implementation.
> >> >>>>
> >> >>>> On 3/13/12 12:40 PM, "Shazron" <shazron@gmail.com> 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 <fil@adobe.com>
> wrote:
> >> >>>> >> Certainly works on Android and at least on the Torch
(BBs with
> >>an
> >> >>>> >> accelerometer)
> >> >>>> >>
> >> >>>> >> On 3/13/12 10:21 AM, "Shazron" <shazron@gmail.com>
wrote:
> >> >>>> >>
> >> >>>> >>>Is that what Android / BB does and is reliable
and tested?
> >> >>>> >>>
> >> >>>> >>>On Tue, Mar 13, 2012 at 9:15 AM, Filip Maj <fil@adobe.com>
> >>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" <shazron@gmail.com>
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
<shazron@gmail.com>
> >> >>>>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 <fil@adobe.com>
> >> >>>>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?
> >> >>>> >>>>
> >> >>>> >>
> >> >>>>
> >> >>>>
> >> >>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message