You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Filip Maj <fi...@adobe.com> on 2012/11/07 01:40:56 UTC
iOS' device API
Currently if you ask for device.platform you will get several different
responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This seems
backwards. IMO all of these should return 'iOS'.
Related, device.name returns the custom device name as the user defines it
in iTunes. IMO it should return the model name, I.e. What device.platform
returns now.
This would line it up with our docs + other platforms.
Re: Accessibility + PhoneGap
Posted by Becky Gibson <gi...@gmail.com>.
On iOS you should be able to make a PhoneGap based application accessible
via VoiceOver using basic accessibility practices and ARIA in your HTML
files. Any of the device UI within the Cordova core plugins should be
accessible. The camera and contacts views are provided by Apple and are
accessible. Cordova provides the CaptureAudio UI and it was made
accessible.
Note that most of the plugins that access UI device features may NOT
accessible without some additional accessibility parameters - toolbar,
navigation bar, etc.
Also, not all of the mobile JS frameworks have implemented accessibility
features so you'll have to do some testing.
-becky
On Thu, Nov 8, 2012 at 9:41 AM, Simon MacDonald
<si...@gmail.com>wrote:
> On Android the screen reader software, TalkBack, is unable to read the
> contents of a WebView component until Android 4.x. So if you have users
> with low vision you have to be cognizant of that fact.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Thu, Nov 8, 2012 at 4:27 AM, Saurabh Kumar Singh <skumarsi@adobe.com
> >wrote:
>
> > Hi,
> >
> > I wanted to confirm one thing. What is the effort involved in making
> > PhoneGap based application accessible ?
> >
> > Thanks & Regards,
> > Saurabh
> >
> >
>
Re: Accessibility + PhoneGap
Posted by Simon MacDonald <si...@gmail.com>.
On Android the screen reader software, TalkBack, is unable to read the
contents of a WebView component until Android 4.x. So if you have users
with low vision you have to be cognizant of that fact.
Simon Mac Donald
http://hi.im/simonmacdonald
On Thu, Nov 8, 2012 at 4:27 AM, Saurabh Kumar Singh <sk...@adobe.com>wrote:
> Hi,
>
> I wanted to confirm one thing. What is the effort involved in making
> PhoneGap based application accessible ?
>
> Thanks & Regards,
> Saurabh
>
>
Re: Accessibility + PhoneGap
Posted by Laurent Hasson <lh...@rim.com>.
For Web content stuff though, I think most modern browsers support things like ARIA no? And frameworks such as jQueryMobile, Dojo or Sencha have some support for it.
___________________________________________
LDH (Laurent Hasson)
Technical Director, BlackBerry Web Platform
Research In Motion
Email: lhasson@rim.com
Mobile: 646-460-7066
-----------------------------------------------------------------
"... He would have given him wings Mr. Kidd." - Mr Wint
-----------------------------------------------------------------
Sent from my BlackBerry Torch!
----- Original Message -----
From: Brian LeRoux [mailto:b@brian.io]
Sent: Thursday, November 08, 2012 11:38 AM
To: dev@cordova.apache.org <de...@cordova.apache.org>
Subject: Re: Accessibility + PhoneGap
each operating system has some level accessibility features tho we do
nothing to abstract those / it would be custom native code
On Thu, Nov 8, 2012 at 1:27 AM, Saurabh Kumar Singh <sk...@adobe.com>wrote:
> Hi,
>
> I wanted to confirm one thing. What is the effort involved in making
> PhoneGap based application accessible ?
>
> Thanks & Regards,
> Saurabh
>
>
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Accessibility + PhoneGap
Posted by Brian LeRoux <b...@brian.io>.
each operating system has some level accessibility features tho we do
nothing to abstract those / it would be custom native code
On Thu, Nov 8, 2012 at 1:27 AM, Saurabh Kumar Singh <sk...@adobe.com>wrote:
> Hi,
>
> I wanted to confirm one thing. What is the effort involved in making
> PhoneGap based application accessible ?
>
> Thanks & Regards,
> Saurabh
>
>
Re: Accessibility + PhoneGap
Posted by Saurabh Kumar Singh <sk...@adobe.com>.
Thanks a lot for your inputs :)
It should be useful for me.
Thanks & Regards,
Saurabh
On 11/8/12 9:20 PM, "Ross Gardler" <rg...@opendirective.com> wrote:
> -----Original Message-----
>> From: Saurabh Kumar Singh [mailto:skumarsi@adobe.com]
>> Sent: 08 November 2012 10:27
>> To: dev@cordova.apache.org
>> Subject: Accessibility + PhoneGap
>>
>> Hi,
>>
>> I wanted to confirm one thing. What is the effort involved in making
>> PhoneGap based application accessible ?
>
>You can use any UI framework you want in a Cordova application so, to a
>large extent, the accessibility of your application depends on the
>framework
>you use and the effort you put into UI design.
>
>We use, for example, JQuery Mobile as our framework because it has much
>excellent support of the various accessibility related standards.
>
>Ross
>
RE: Accessibility + PhoneGap
Posted by Ross Gardler <rg...@opendirective.com>.
-----Original Message-----
> From: Saurabh Kumar Singh [mailto:skumarsi@adobe.com]
> Sent: 08 November 2012 10:27
> To: dev@cordova.apache.org
> Subject: Accessibility + PhoneGap
>
> Hi,
>
> I wanted to confirm one thing. What is the effort involved in making
> PhoneGap based application accessible ?
You can use any UI framework you want in a Cordova application so, to a
large extent, the accessibility of your application depends on the framework
you use and the effort you put into UI design.
We use, for example, JQuery Mobile as our framework because it has much
excellent support of the various accessibility related standards.
Ross
Re: iOS' device API
Posted by Shazron <sh...@gmail.com>.
I'll just go ahead and create the tasks for device.model (and
device.namedeprecation) - if there's a reason not to, please chime in.
http://issues.cordova.io/1850
On Wed, Nov 14, 2012 at 12:00 PM, Shazron <sh...@gmail.com> wrote:
> I like device.model. Should we adopt it for all the platforms? +1 for me
>
>
> On Wed, Nov 14, 2012 at 11:44 AM, Filip Maj <fi...@adobe.com> wrote:
>
>> Yeah. Device.name is an ambiguous-sounding API. Thus my original
>> recommendation to deprecate device.name and add device.model or
>> device.hardware.
>>
>> Basically, this API should return a string that makes it clear what
>> hardware or model of device it is.
>>
>> On 11/14/12 11:28 AM, "Shazron" <sh...@gmail.com> wrote:
>>
>> >I have somewhat similar concern for iOS:
>> >https://issues.apache.org/jira/browse/CB-1837
>> >
>> >Wonder whether we should output the model number instead eg iPad2,5
>> >This might solve the comical procedure to detect an iPad Mini (at least
>> >for
>> >Cordova):
>> >http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5
>> >
>> >
>> >On Wed, Nov 14, 2012 at 11:14 AM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> >> Resurrecting this one.
>> >>
>> >> BlackBerry has the same issue sorta.
>> >>
>> >> I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
>> >>When I
>> >> ask for "device.version", I get "BlackBerry Playbook OS" for both.
>> >>
>> >> Device.name also returns weird stuff for the play books, seem like
>> >> arbitrary numbers: 100669958.
>> >>
>> >> Also, device.platform returns "playbook". Shouldn't this be
>> >>"BlackBerry" ?
>> >>
>> >> /cc anyone from RIM
>> >>
>> >> On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote:
>> >>
>> >> >thanks shaz
>> >> >
>> >> >
>> >> >On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
>> >> >
>> >> >> Added:
>> >> >>
>> >> >> http://issues.cordova.io/1836
>> >> >> http://issues.cordova.io/1837
>> >> >> http://issues.cordova.io/1838
>> >> >> http://issues.cordova.io/1839
>> >> >> http://issues.cordova.io/1840
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com>
>> wrote:
>> >> >>
>> >> >> > Adding jira tasks as per Brian's last comment.
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com>
>> wrote:
>> >> >> >
>> >> >> >> +1 sounds like a plan
>> >> >> >>
>> >> >> >>
>> >> >> >> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
>> >> >> >>
>> >> >> >>> +1
>> >> >> >>>
>> >> >> >>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >> >> >>>
>> >> >> >>> >I think would it make sense to:
>> >> >> >>> >
>> >> >> >>> >1. align apis as orig msg from fil suggests
>> >> >> >>> >2. drop in deprecation notice for sync usage and add to deprec
>> >>page
>> >> >> >>> >3. add async equiv and get it out of startup path as andrew
>> >> >>suggests
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com>
>> wrote:
>> >> >> >>> >
>> >> >> >>> >> Although I think we're close to being able to author
>> >> >>cross-platform
>> >> >> >>> apps
>> >> >> >>> >> sans UA detection , I think people still have valid use cases
>> >>to
>> >> >>use
>> >> >> >>> it.
>> >> >> >>> >>
>> >> >> >>> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org>
>> >> wrote:
>> >> >> >>> >>
>> >> >> >>> >> >I like the idea of at least removing this from the start-up
>> >> >>path.
>> >> >> If
>> >> >> >>> >>users
>> >> >> >>> >> >want to know about the device, they could always call exec()
>> >> >> >>> >>themselves.
>> >> >> >>> >> >
>> >> >> >>> >> >
>> >> >> >>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com>
>> >> >>wrote:
>> >> >> >>> >> >
>> >> >> >>> >> >> Also, if we remove the device API like Brian suggested, it
>> >> >>would
>> >> >> be
>> >> >> >>> >> >>good in
>> >> >> >>> >> >> the sense that we won't have to call the CDVDevice plugin
>> >>to
>> >> >> >>> populate
>> >> >> >>> >> >>some
>> >> >> >>> >> >> js variables before deviceready can fire -- eliminating a
>> >> >> >>> dependency.
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron
>> >><sh...@gmail.com>
>> >> >> >>> wrote:
>> >> >> >>> >> >>
>> >> >> >>> >> >> > Agree with Fil to make it consistent - in essence this
>> >>is an
>> >> >> iOS
>> >> >> >>> >>bug
>> >> >> >>> >> >>:)
>> >> >> >>> >> >> >
>> >> >> >>> >> >> > Brian, there is one case I can think of -- detecting the
>> >> >>iPad
>> >> >> >>> >>mini's
>> >> >> >>> >> >> > features using js - Max Firt investigated trying to do
>> it
>> >> >> >>> >> >> >
>> >> >> >>> >> >>
>> >> >> >>> >> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>>
>> >> >>
>> >> >>
>> >>
>> >>
>> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>> >> >> >>> >> >>tthe only kludgy way right now using PG would be
>> >> >>device.platform
>> >> >> to
>> >> >> >>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to
>> >> >>detect
>> >> >> >>> >>this to
>> >> >> >>> >> >> > enlarge certain UI elements for the mini (since the
>> >>physical
>> >> >> area
>> >> >> >>> >> >>will be
>> >> >> >>> >> >> > smaller than a reg sized iPad)
>> >> >> >>> >> >> >
>> >> >> >>> >> >> >
>> >> >> >>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj
>> >><fi...@adobe.com>
>> >> >> >>> wrote:
>> >> >> >>> >> >> >
>> >> >> >>> >> >> >> CI implementation is what I am gunning for here (and
>> can
>> >> >> >>> actually
>> >> >> >>> >>use
>> >> >> >>> >> >> it).
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >> I don't like it either but reality is for people
>> >>building
>> >> >> >>> >> >>cross-platform
>> >> >> >>> >> >> >> apps at some point you have to do:
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >> if (device.platform == 'android') // do some stuff
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >> For example, knowing when to attach to a back button vs
>> >> >> >>> rendering
>> >> >> >>> >> >>some
>> >> >> >>> >> >> ui
>> >> >> >>> >> >> >> to handle that.
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >> IMO we should set up deprecation for "name" and move to
>> >> >> "model"
>> >> >> >>> as
>> >> >> >>> >> >>it's
>> >> >> >>> >> >> >> clearer (and probably was the reason why iOS went for
>> >> >>device's
>> >> >> >>> >>custom
>> >> >> >>> >> >> name
>> >> >> >>> >> >> >> in the first place - semantic confusion :P )
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >> >This may get some rotton tomatoes thrown at me but I
>> >> >>would be
>> >> >> >>> in
>> >> >> >>> >> >>favor
>> >> >> >>> >> >> of
>> >> >> >>> >> >> >> >axing these apis altogether. I think they are more
>> >> >>dangerous
>> >> >> >>> than
>> >> >> >>> >> >> useful
>> >> >> >>> >> >> >> /
>> >> >> >>> >> >> >> >developers should favor browser feature detection for
>> >> >>their
>> >> >> UI
>> >> >> >>> >>work.
>> >> >> >>> >> >> >> >
>> >> >> >>> >> >> >> >There is no programmatic reason to want these
>> >>properties
>> >> >> >>> >>otherwise
>> >> >> >>> >> >> that I
>> >> >> >>> >> >> >> >can think of?
>> >> >> >>> >> >> >> >
>> >> >> >>> >> >> >> >(But agree at least should be consistent as Fil
>> >>suggests.)
>> >> >> >>> >> >> >> >
>> >> >> >>> >> >> >> >
>> >> >> >>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj
>> >><fi...@adobe.com>
>> >> >> >>> wrote:
>> >> >> >>> >> >> >> >
>> >> >> >>> >> >> >> >> Currently if you ask for device.platform you will
>> get
>> >> >> several
>> >> >> >>> >> >> different
>> >> >> >>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod
>> >>Touch,
>> >> >>etc.
>> >> >> >>> >>This
>> >> >> >>> >> >> seems
>> >> >> >>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
>> >> >> >>> >> >> >> >>
>> >> >> >>> >> >> >> >> Related, device.name returns the custom device name
>> >>as
>> >> >>the
>> >> >> >>> user
>> >> >> >>> >> >> >> defines
>> >> >> >>> >> >> >> >>it
>> >> >> >>> >> >> >> >> in iTunes. IMO it should return the model name, I.e.
>> >> >>What
>> >> >> >>> >> >> >> >>device.platform
>> >> >> >>> >> >> >> >> returns now.
>> >> >> >>> >> >> >> >>
>> >> >> >>> >> >> >> >> This would line it up with our docs + other
>> >>platforms.
>> >> >> >>> >> >> >> >>
>> >> >> >>> >> >> >> >>
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >>
>> >> >> >>> >> >> >
>> >> >> >>> >> >>
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >
>> >> >>
>> >>
>> >>
>>
>>
>
Re: iOS' device API
Posted by Shazron <sh...@gmail.com>.
I like device.model. Should we adopt it for all the platforms? +1 for me
On Wed, Nov 14, 2012 at 11:44 AM, Filip Maj <fi...@adobe.com> wrote:
> Yeah. Device.name is an ambiguous-sounding API. Thus my original
> recommendation to deprecate device.name and add device.model or
> device.hardware.
>
> Basically, this API should return a string that makes it clear what
> hardware or model of device it is.
>
> On 11/14/12 11:28 AM, "Shazron" <sh...@gmail.com> wrote:
>
> >I have somewhat similar concern for iOS:
> >https://issues.apache.org/jira/browse/CB-1837
> >
> >Wonder whether we should output the model number instead eg iPad2,5
> >This might solve the comical procedure to detect an iPad Mini (at least
> >for
> >Cordova):
> >http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5
> >
> >
> >On Wed, Nov 14, 2012 at 11:14 AM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> Resurrecting this one.
> >>
> >> BlackBerry has the same issue sorta.
> >>
> >> I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
> >>When I
> >> ask for "device.version", I get "BlackBerry Playbook OS" for both.
> >>
> >> Device.name also returns weird stuff for the play books, seem like
> >> arbitrary numbers: 100669958.
> >>
> >> Also, device.platform returns "playbook". Shouldn't this be
> >>"BlackBerry" ?
> >>
> >> /cc anyone from RIM
> >>
> >> On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote:
> >>
> >> >thanks shaz
> >> >
> >> >
> >> >On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
> >> >
> >> >> Added:
> >> >>
> >> >> http://issues.cordova.io/1836
> >> >> http://issues.cordova.io/1837
> >> >> http://issues.cordova.io/1838
> >> >> http://issues.cordova.io/1839
> >> >> http://issues.cordova.io/1840
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
> >> >>
> >> >> > Adding jira tasks as per Brian's last comment.
> >> >> >
> >> >> >
> >> >> > On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
> >> >> >
> >> >> >> +1 sounds like a plan
> >> >> >>
> >> >> >>
> >> >> >> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
> >> >> >>
> >> >> >>> +1
> >> >> >>>
> >> >> >>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >> >> >>>
> >> >> >>> >I think would it make sense to:
> >> >> >>> >
> >> >> >>> >1. align apis as orig msg from fil suggests
> >> >> >>> >2. drop in deprecation notice for sync usage and add to deprec
> >>page
> >> >> >>> >3. add async equiv and get it out of startup path as andrew
> >> >>suggests
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com>
> wrote:
> >> >> >>> >
> >> >> >>> >> Although I think we're close to being able to author
> >> >>cross-platform
> >> >> >>> apps
> >> >> >>> >> sans UA detection , I think people still have valid use cases
> >>to
> >> >>use
> >> >> >>> it.
> >> >> >>> >>
> >> >> >>> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org>
> >> wrote:
> >> >> >>> >>
> >> >> >>> >> >I like the idea of at least removing this from the start-up
> >> >>path.
> >> >> If
> >> >> >>> >>users
> >> >> >>> >> >want to know about the device, they could always call exec()
> >> >> >>> >>themselves.
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com>
> >> >>wrote:
> >> >> >>> >> >
> >> >> >>> >> >> Also, if we remove the device API like Brian suggested, it
> >> >>would
> >> >> be
> >> >> >>> >> >>good in
> >> >> >>> >> >> the sense that we won't have to call the CDVDevice plugin
> >>to
> >> >> >>> populate
> >> >> >>> >> >>some
> >> >> >>> >> >> js variables before deviceready can fire -- eliminating a
> >> >> >>> dependency.
> >> >> >>> >> >>
> >> >> >>> >> >>
> >> >> >>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron
> >><sh...@gmail.com>
> >> >> >>> wrote:
> >> >> >>> >> >>
> >> >> >>> >> >> > Agree with Fil to make it consistent - in essence this
> >>is an
> >> >> iOS
> >> >> >>> >>bug
> >> >> >>> >> >>:)
> >> >> >>> >> >> >
> >> >> >>> >> >> > Brian, there is one case I can think of -- detecting the
> >> >>iPad
> >> >> >>> >>mini's
> >> >> >>> >> >> > features using js - Max Firt investigated trying to do it
> >> >> >>> >> >> >
> >> >> >>> >> >>
> >> >> >>> >> >>
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>>
> >> >>
> >> >>
> >>
> >>
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
> >> >> >>> >> >>tthe only kludgy way right now using PG would be
> >> >>device.platform
> >> >> to
> >> >> >>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to
> >> >>detect
> >> >> >>> >>this to
> >> >> >>> >> >> > enlarge certain UI elements for the mini (since the
> >>physical
> >> >> area
> >> >> >>> >> >>will be
> >> >> >>> >> >> > smaller than a reg sized iPad)
> >> >> >>> >> >> >
> >> >> >>> >> >> >
> >> >> >>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj
> >><fi...@adobe.com>
> >> >> >>> wrote:
> >> >> >>> >> >> >
> >> >> >>> >> >> >> CI implementation is what I am gunning for here (and can
> >> >> >>> actually
> >> >> >>> >>use
> >> >> >>> >> >> it).
> >> >> >>> >> >> >>
> >> >> >>> >> >> >> I don't like it either but reality is for people
> >>building
> >> >> >>> >> >>cross-platform
> >> >> >>> >> >> >> apps at some point you have to do:
> >> >> >>> >> >> >>
> >> >> >>> >> >> >> if (device.platform == 'android') // do some stuff
> >> >> >>> >> >> >>
> >> >> >>> >> >> >> For example, knowing when to attach to a back button vs
> >> >> >>> rendering
> >> >> >>> >> >>some
> >> >> >>> >> >> ui
> >> >> >>> >> >> >> to handle that.
> >> >> >>> >> >> >>
> >> >> >>> >> >> >> IMO we should set up deprecation for "name" and move to
> >> >> "model"
> >> >> >>> as
> >> >> >>> >> >>it's
> >> >> >>> >> >> >> clearer (and probably was the reason why iOS went for
> >> >>device's
> >> >> >>> >>custom
> >> >> >>> >> >> name
> >> >> >>> >> >> >> in the first place - semantic confusion :P )
> >> >> >>> >> >> >>
> >> >> >>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >> >> >>> >> >> >>
> >> >> >>> >> >> >> >This may get some rotton tomatoes thrown at me but I
> >> >>would be
> >> >> >>> in
> >> >> >>> >> >>favor
> >> >> >>> >> >> of
> >> >> >>> >> >> >> >axing these apis altogether. I think they are more
> >> >>dangerous
> >> >> >>> than
> >> >> >>> >> >> useful
> >> >> >>> >> >> >> /
> >> >> >>> >> >> >> >developers should favor browser feature detection for
> >> >>their
> >> >> UI
> >> >> >>> >>work.
> >> >> >>> >> >> >> >
> >> >> >>> >> >> >> >There is no programmatic reason to want these
> >>properties
> >> >> >>> >>otherwise
> >> >> >>> >> >> that I
> >> >> >>> >> >> >> >can think of?
> >> >> >>> >> >> >> >
> >> >> >>> >> >> >> >(But agree at least should be consistent as Fil
> >>suggests.)
> >> >> >>> >> >> >> >
> >> >> >>> >> >> >> >
> >> >> >>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj
> >><fi...@adobe.com>
> >> >> >>> wrote:
> >> >> >>> >> >> >> >
> >> >> >>> >> >> >> >> Currently if you ask for device.platform you will get
> >> >> several
> >> >> >>> >> >> different
> >> >> >>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod
> >>Touch,
> >> >>etc.
> >> >> >>> >>This
> >> >> >>> >> >> seems
> >> >> >>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
> >> >> >>> >> >> >> >>
> >> >> >>> >> >> >> >> Related, device.name returns the custom device name
> >>as
> >> >>the
> >> >> >>> user
> >> >> >>> >> >> >> defines
> >> >> >>> >> >> >> >>it
> >> >> >>> >> >> >> >> in iTunes. IMO it should return the model name, I.e.
> >> >>What
> >> >> >>> >> >> >> >>device.platform
> >> >> >>> >> >> >> >> returns now.
> >> >> >>> >> >> >> >>
> >> >> >>> >> >> >> >> This would line it up with our docs + other
> >>platforms.
> >> >> >>> >> >> >> >>
> >> >> >>> >> >> >> >>
> >> >> >>> >> >> >>
> >> >> >>> >> >> >>
> >> >> >>> >> >> >
> >> >> >>> >> >>
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >
> >> >>
> >>
> >>
>
>
Re: iOS' device API
Posted by Filip Maj <fi...@adobe.com>.
Yeah. Device.name is an ambiguous-sounding API. Thus my original
recommendation to deprecate device.name and add device.model or
device.hardware.
Basically, this API should return a string that makes it clear what
hardware or model of device it is.
On 11/14/12 11:28 AM, "Shazron" <sh...@gmail.com> wrote:
>I have somewhat similar concern for iOS:
>https://issues.apache.org/jira/browse/CB-1837
>
>Wonder whether we should output the model number instead eg iPad2,5
>This might solve the comical procedure to detect an iPad Mini (at least
>for
>Cordova):
>http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5
>
>
>On Wed, Nov 14, 2012 at 11:14 AM, Filip Maj <fi...@adobe.com> wrote:
>
>> Resurrecting this one.
>>
>> BlackBerry has the same issue sorta.
>>
>> I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
>>When I
>> ask for "device.version", I get "BlackBerry Playbook OS" for both.
>>
>> Device.name also returns weird stuff for the play books, seem like
>> arbitrary numbers: 100669958.
>>
>> Also, device.platform returns "playbook". Shouldn't this be
>>"BlackBerry" ?
>>
>> /cc anyone from RIM
>>
>> On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote:
>>
>> >thanks shaz
>> >
>> >
>> >On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
>> >
>> >> Added:
>> >>
>> >> http://issues.cordova.io/1836
>> >> http://issues.cordova.io/1837
>> >> http://issues.cordova.io/1838
>> >> http://issues.cordova.io/1839
>> >> http://issues.cordova.io/1840
>> >>
>> >>
>> >>
>> >> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
>> >>
>> >> > Adding jira tasks as per Brian's last comment.
>> >> >
>> >> >
>> >> > On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
>> >> >
>> >> >> +1 sounds like a plan
>> >> >>
>> >> >>
>> >> >> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
>> >> >>
>> >> >>> +1
>> >> >>>
>> >> >>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >> >>>
>> >> >>> >I think would it make sense to:
>> >> >>> >
>> >> >>> >1. align apis as orig msg from fil suggests
>> >> >>> >2. drop in deprecation notice for sync usage and add to deprec
>>page
>> >> >>> >3. add async equiv and get it out of startup path as andrew
>> >>suggests
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> >>> >
>> >> >>> >> Although I think we're close to being able to author
>> >>cross-platform
>> >> >>> apps
>> >> >>> >> sans UA detection , I think people still have valid use cases
>>to
>> >>use
>> >> >>> it.
>> >> >>> >>
>> >> >>> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org>
>> wrote:
>> >> >>> >>
>> >> >>> >> >I like the idea of at least removing this from the start-up
>> >>path.
>> >> If
>> >> >>> >>users
>> >> >>> >> >want to know about the device, they could always call exec()
>> >> >>> >>themselves.
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com>
>> >>wrote:
>> >> >>> >> >
>> >> >>> >> >> Also, if we remove the device API like Brian suggested, it
>> >>would
>> >> be
>> >> >>> >> >>good in
>> >> >>> >> >> the sense that we won't have to call the CDVDevice plugin
>>to
>> >> >>> populate
>> >> >>> >> >>some
>> >> >>> >> >> js variables before deviceready can fire -- eliminating a
>> >> >>> dependency.
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron
>><sh...@gmail.com>
>> >> >>> wrote:
>> >> >>> >> >>
>> >> >>> >> >> > Agree with Fil to make it consistent - in essence this
>>is an
>> >> iOS
>> >> >>> >>bug
>> >> >>> >> >>:)
>> >> >>> >> >> >
>> >> >>> >> >> > Brian, there is one case I can think of -- detecting the
>> >>iPad
>> >> >>> >>mini's
>> >> >>> >> >> > features using js - Max Firt investigated trying to do it
>> >> >>> >> >> >
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>>
>> >>
>> >>
>>
>>http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>> >> >>> >> >>tthe only kludgy way right now using PG would be
>> >>device.platform
>> >> to
>> >> >>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to
>> >>detect
>> >> >>> >>this to
>> >> >>> >> >> > enlarge certain UI elements for the mini (since the
>>physical
>> >> area
>> >> >>> >> >>will be
>> >> >>> >> >> > smaller than a reg sized iPad)
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj
>><fi...@adobe.com>
>> >> >>> wrote:
>> >> >>> >> >> >
>> >> >>> >> >> >> CI implementation is what I am gunning for here (and can
>> >> >>> actually
>> >> >>> >>use
>> >> >>> >> >> it).
>> >> >>> >> >> >>
>> >> >>> >> >> >> I don't like it either but reality is for people
>>building
>> >> >>> >> >>cross-platform
>> >> >>> >> >> >> apps at some point you have to do:
>> >> >>> >> >> >>
>> >> >>> >> >> >> if (device.platform == 'android') // do some stuff
>> >> >>> >> >> >>
>> >> >>> >> >> >> For example, knowing when to attach to a back button vs
>> >> >>> rendering
>> >> >>> >> >>some
>> >> >>> >> >> ui
>> >> >>> >> >> >> to handle that.
>> >> >>> >> >> >>
>> >> >>> >> >> >> IMO we should set up deprecation for "name" and move to
>> >> "model"
>> >> >>> as
>> >> >>> >> >>it's
>> >> >>> >> >> >> clearer (and probably was the reason why iOS went for
>> >>device's
>> >> >>> >>custom
>> >> >>> >> >> name
>> >> >>> >> >> >> in the first place - semantic confusion :P )
>> >> >>> >> >> >>
>> >> >>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >> >>> >> >> >>
>> >> >>> >> >> >> >This may get some rotton tomatoes thrown at me but I
>> >>would be
>> >> >>> in
>> >> >>> >> >>favor
>> >> >>> >> >> of
>> >> >>> >> >> >> >axing these apis altogether. I think they are more
>> >>dangerous
>> >> >>> than
>> >> >>> >> >> useful
>> >> >>> >> >> >> /
>> >> >>> >> >> >> >developers should favor browser feature detection for
>> >>their
>> >> UI
>> >> >>> >>work.
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >There is no programmatic reason to want these
>>properties
>> >> >>> >>otherwise
>> >> >>> >> >> that I
>> >> >>> >> >> >> >can think of?
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >(But agree at least should be consistent as Fil
>>suggests.)
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj
>><fi...@adobe.com>
>> >> >>> wrote:
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >> Currently if you ask for device.platform you will get
>> >> several
>> >> >>> >> >> different
>> >> >>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod
>>Touch,
>> >>etc.
>> >> >>> >>This
>> >> >>> >> >> seems
>> >> >>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> Related, device.name returns the custom device name
>>as
>> >>the
>> >> >>> user
>> >> >>> >> >> >> defines
>> >> >>> >> >> >> >>it
>> >> >>> >> >> >> >> in iTunes. IMO it should return the model name, I.e.
>> >>What
>> >> >>> >> >> >> >>device.platform
>> >> >>> >> >> >> >> returns now.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> This would line it up with our docs + other
>>platforms.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >
>> >> >>> >> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >>
>>
>>
Re: iOS' device API
Posted by Filip Maj <fi...@adobe.com>.
Yeah. Device.name is an ambiguous-sounding API. Thus my original
recommendation to deprecate device.name and add device.model or
device.hardware.
Basically, this API should return a string that makes it clear what
hardware or model of device it is.
On 11/14/12 11:28 AM, "Shazron" <sh...@gmail.com> wrote:
>I have somewhat similar concern for iOS:
>https://issues.apache.org/jira/browse/CB-1837
>
>Wonder whether we should output the model number instead eg iPad2,5
>This might solve the comical procedure to detect an iPad Mini (at least
>for
>Cordova):
>http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5
>
>
>On Wed, Nov 14, 2012 at 11:14 AM, Filip Maj <fi...@adobe.com> wrote:
>
>> Resurrecting this one.
>>
>> BlackBerry has the same issue sorta.
>>
>> I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
>>When I
>> ask for "device.version", I get "BlackBerry Playbook OS" for both.
>>
>> Device.name also returns weird stuff for the play books, seem like
>> arbitrary numbers: 100669958.
>>
>> Also, device.platform returns "playbook". Shouldn't this be
>>"BlackBerry" ?
>>
>> /cc anyone from RIM
>>
>> On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote:
>>
>> >thanks shaz
>> >
>> >
>> >On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
>> >
>> >> Added:
>> >>
>> >> http://issues.cordova.io/1836
>> >> http://issues.cordova.io/1837
>> >> http://issues.cordova.io/1838
>> >> http://issues.cordova.io/1839
>> >> http://issues.cordova.io/1840
>> >>
>> >>
>> >>
>> >> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
>> >>
>> >> > Adding jira tasks as per Brian's last comment.
>> >> >
>> >> >
>> >> > On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
>> >> >
>> >> >> +1 sounds like a plan
>> >> >>
>> >> >>
>> >> >> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
>> >> >>
>> >> >>> +1
>> >> >>>
>> >> >>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >> >>>
>> >> >>> >I think would it make sense to:
>> >> >>> >
>> >> >>> >1. align apis as orig msg from fil suggests
>> >> >>> >2. drop in deprecation notice for sync usage and add to deprec
>>page
>> >> >>> >3. add async equiv and get it out of startup path as andrew
>> >>suggests
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> >>> >
>> >> >>> >> Although I think we're close to being able to author
>> >>cross-platform
>> >> >>> apps
>> >> >>> >> sans UA detection , I think people still have valid use cases
>>to
>> >>use
>> >> >>> it.
>> >> >>> >>
>> >> >>> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org>
>> wrote:
>> >> >>> >>
>> >> >>> >> >I like the idea of at least removing this from the start-up
>> >>path.
>> >> If
>> >> >>> >>users
>> >> >>> >> >want to know about the device, they could always call exec()
>> >> >>> >>themselves.
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com>
>> >>wrote:
>> >> >>> >> >
>> >> >>> >> >> Also, if we remove the device API like Brian suggested, it
>> >>would
>> >> be
>> >> >>> >> >>good in
>> >> >>> >> >> the sense that we won't have to call the CDVDevice plugin
>>to
>> >> >>> populate
>> >> >>> >> >>some
>> >> >>> >> >> js variables before deviceready can fire -- eliminating a
>> >> >>> dependency.
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron
>><sh...@gmail.com>
>> >> >>> wrote:
>> >> >>> >> >>
>> >> >>> >> >> > Agree with Fil to make it consistent - in essence this
>>is an
>> >> iOS
>> >> >>> >>bug
>> >> >>> >> >>:)
>> >> >>> >> >> >
>> >> >>> >> >> > Brian, there is one case I can think of -- detecting the
>> >>iPad
>> >> >>> >>mini's
>> >> >>> >> >> > features using js - Max Firt investigated trying to do it
>> >> >>> >> >> >
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>>
>> >>
>> >>
>>
>>http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>> >> >>> >> >>tthe only kludgy way right now using PG would be
>> >>device.platform
>> >> to
>> >> >>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to
>> >>detect
>> >> >>> >>this to
>> >> >>> >> >> > enlarge certain UI elements for the mini (since the
>>physical
>> >> area
>> >> >>> >> >>will be
>> >> >>> >> >> > smaller than a reg sized iPad)
>> >> >>> >> >> >
>> >> >>> >> >> >
>> >> >>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj
>><fi...@adobe.com>
>> >> >>> wrote:
>> >> >>> >> >> >
>> >> >>> >> >> >> CI implementation is what I am gunning for here (and can
>> >> >>> actually
>> >> >>> >>use
>> >> >>> >> >> it).
>> >> >>> >> >> >>
>> >> >>> >> >> >> I don't like it either but reality is for people
>>building
>> >> >>> >> >>cross-platform
>> >> >>> >> >> >> apps at some point you have to do:
>> >> >>> >> >> >>
>> >> >>> >> >> >> if (device.platform == 'android') // do some stuff
>> >> >>> >> >> >>
>> >> >>> >> >> >> For example, knowing when to attach to a back button vs
>> >> >>> rendering
>> >> >>> >> >>some
>> >> >>> >> >> ui
>> >> >>> >> >> >> to handle that.
>> >> >>> >> >> >>
>> >> >>> >> >> >> IMO we should set up deprecation for "name" and move to
>> >> "model"
>> >> >>> as
>> >> >>> >> >>it's
>> >> >>> >> >> >> clearer (and probably was the reason why iOS went for
>> >>device's
>> >> >>> >>custom
>> >> >>> >> >> name
>> >> >>> >> >> >> in the first place - semantic confusion :P )
>> >> >>> >> >> >>
>> >> >>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >> >>> >> >> >>
>> >> >>> >> >> >> >This may get some rotton tomatoes thrown at me but I
>> >>would be
>> >> >>> in
>> >> >>> >> >>favor
>> >> >>> >> >> of
>> >> >>> >> >> >> >axing these apis altogether. I think they are more
>> >>dangerous
>> >> >>> than
>> >> >>> >> >> useful
>> >> >>> >> >> >> /
>> >> >>> >> >> >> >developers should favor browser feature detection for
>> >>their
>> >> UI
>> >> >>> >>work.
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >There is no programmatic reason to want these
>>properties
>> >> >>> >>otherwise
>> >> >>> >> >> that I
>> >> >>> >> >> >> >can think of?
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >(But agree at least should be consistent as Fil
>>suggests.)
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj
>><fi...@adobe.com>
>> >> >>> wrote:
>> >> >>> >> >> >> >
>> >> >>> >> >> >> >> Currently if you ask for device.platform you will get
>> >> several
>> >> >>> >> >> different
>> >> >>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod
>>Touch,
>> >>etc.
>> >> >>> >>This
>> >> >>> >> >> seems
>> >> >>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> Related, device.name returns the custom device name
>>as
>> >>the
>> >> >>> user
>> >> >>> >> >> >> defines
>> >> >>> >> >> >> >>it
>> >> >>> >> >> >> >> in iTunes. IMO it should return the model name, I.e.
>> >>What
>> >> >>> >> >> >> >>device.platform
>> >> >>> >> >> >> >> returns now.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >> This would line it up with our docs + other
>>platforms.
>> >> >>> >> >> >> >>
>> >> >>> >> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >>
>> >> >>> >> >> >
>> >> >>> >> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >>
>>
>>
Re: iOS' device API
Posted by Shazron <sh...@gmail.com>.
I have somewhat similar concern for iOS:
https://issues.apache.org/jira/browse/CB-1837
Wonder whether we should output the model number instead eg iPad2,5
This might solve the comical procedure to detect an iPad Mini (at least for
Cordova):
http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5
On Wed, Nov 14, 2012 at 11:14 AM, Filip Maj <fi...@adobe.com> wrote:
> Resurrecting this one.
>
> BlackBerry has the same issue sorta.
>
> I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx. When I
> ask for "device.version", I get "BlackBerry Playbook OS" for both.
>
> Device.name also returns weird stuff for the play books, seem like
> arbitrary numbers: 100669958.
>
> Also, device.platform returns "playbook". Shouldn't this be "BlackBerry" ?
>
> /cc anyone from RIM
>
> On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote:
>
> >thanks shaz
> >
> >
> >On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
> >
> >> Added:
> >>
> >> http://issues.cordova.io/1836
> >> http://issues.cordova.io/1837
> >> http://issues.cordova.io/1838
> >> http://issues.cordova.io/1839
> >> http://issues.cordova.io/1840
> >>
> >>
> >>
> >> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
> >>
> >> > Adding jira tasks as per Brian's last comment.
> >> >
> >> >
> >> > On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
> >> >
> >> >> +1 sounds like a plan
> >> >>
> >> >>
> >> >> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
> >> >>
> >> >>> +1
> >> >>>
> >> >>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >> >>>
> >> >>> >I think would it make sense to:
> >> >>> >
> >> >>> >1. align apis as orig msg from fil suggests
> >> >>> >2. drop in deprecation notice for sync usage and add to deprec page
> >> >>> >3. add async equiv and get it out of startup path as andrew
> >>suggests
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >>> >
> >> >>> >> Although I think we're close to being able to author
> >>cross-platform
> >> >>> apps
> >> >>> >> sans UA detection , I think people still have valid use cases to
> >>use
> >> >>> it.
> >> >>> >>
> >> >>> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org>
> wrote:
> >> >>> >>
> >> >>> >> >I like the idea of at least removing this from the start-up
> >>path.
> >> If
> >> >>> >>users
> >> >>> >> >want to know about the device, they could always call exec()
> >> >>> >>themselves.
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com>
> >>wrote:
> >> >>> >> >
> >> >>> >> >> Also, if we remove the device API like Brian suggested, it
> >>would
> >> be
> >> >>> >> >>good in
> >> >>> >> >> the sense that we won't have to call the CDVDevice plugin to
> >> >>> populate
> >> >>> >> >>some
> >> >>> >> >> js variables before deviceready can fire -- eliminating a
> >> >>> dependency.
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com>
> >> >>> wrote:
> >> >>> >> >>
> >> >>> >> >> > Agree with Fil to make it consistent - in essence this is an
> >> iOS
> >> >>> >>bug
> >> >>> >> >>:)
> >> >>> >> >> >
> >> >>> >> >> > Brian, there is one case I can think of -- detecting the
> >>iPad
> >> >>> >>mini's
> >> >>> >> >> > features using js - Max Firt investigated trying to do it
> >> >>> >> >> >
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >>
> >> >>> >>
> >> >>>
> >>
> >>
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
> >> >>> >> >>tthe only kludgy way right now using PG would be
> >>device.platform
> >> to
> >> >>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to
> >>detect
> >> >>> >>this to
> >> >>> >> >> > enlarge certain UI elements for the mini (since the physical
> >> area
> >> >>> >> >>will be
> >> >>> >> >> > smaller than a reg sized iPad)
> >> >>> >> >> >
> >> >>> >> >> >
> >> >>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com>
> >> >>> wrote:
> >> >>> >> >> >
> >> >>> >> >> >> CI implementation is what I am gunning for here (and can
> >> >>> actually
> >> >>> >>use
> >> >>> >> >> it).
> >> >>> >> >> >>
> >> >>> >> >> >> I don't like it either but reality is for people building
> >> >>> >> >>cross-platform
> >> >>> >> >> >> apps at some point you have to do:
> >> >>> >> >> >>
> >> >>> >> >> >> if (device.platform == 'android') // do some stuff
> >> >>> >> >> >>
> >> >>> >> >> >> For example, knowing when to attach to a back button vs
> >> >>> rendering
> >> >>> >> >>some
> >> >>> >> >> ui
> >> >>> >> >> >> to handle that.
> >> >>> >> >> >>
> >> >>> >> >> >> IMO we should set up deprecation for "name" and move to
> >> "model"
> >> >>> as
> >> >>> >> >>it's
> >> >>> >> >> >> clearer (and probably was the reason why iOS went for
> >>device's
> >> >>> >>custom
> >> >>> >> >> name
> >> >>> >> >> >> in the first place - semantic confusion :P )
> >> >>> >> >> >>
> >> >>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >> >>> >> >> >>
> >> >>> >> >> >> >This may get some rotton tomatoes thrown at me but I
> >>would be
> >> >>> in
> >> >>> >> >>favor
> >> >>> >> >> of
> >> >>> >> >> >> >axing these apis altogether. I think they are more
> >>dangerous
> >> >>> than
> >> >>> >> >> useful
> >> >>> >> >> >> /
> >> >>> >> >> >> >developers should favor browser feature detection for
> >>their
> >> UI
> >> >>> >>work.
> >> >>> >> >> >> >
> >> >>> >> >> >> >There is no programmatic reason to want these properties
> >> >>> >>otherwise
> >> >>> >> >> that I
> >> >>> >> >> >> >can think of?
> >> >>> >> >> >> >
> >> >>> >> >> >> >(But agree at least should be consistent as Fil suggests.)
> >> >>> >> >> >> >
> >> >>> >> >> >> >
> >> >>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com>
> >> >>> wrote:
> >> >>> >> >> >> >
> >> >>> >> >> >> >> Currently if you ask for device.platform you will get
> >> several
> >> >>> >> >> different
> >> >>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch,
> >>etc.
> >> >>> >>This
> >> >>> >> >> seems
> >> >>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> Related, device.name returns the custom device name as
> >>the
> >> >>> user
> >> >>> >> >> >> defines
> >> >>> >> >> >> >>it
> >> >>> >> >> >> >> in iTunes. IMO it should return the model name, I.e.
> >>What
> >> >>> >> >> >> >>device.platform
> >> >>> >> >> >> >> returns now.
> >> >>> >> >> >> >>
> >> >>> >> >> >> >> This would line it up with our docs + other platforms.
> >> >>> >> >> >> >>
> >> >>> >> >> >> >>
> >> >>> >> >> >>
> >> >>> >> >> >>
> >> >>> >> >> >
> >> >>> >> >>
> >> >>> >>
> >> >>> >>
> >> >>>
> >> >>>
> >> >>
> >> >
> >>
>
>
Re: iOS' device API
Posted by Filip Maj <fi...@adobe.com>.
Thx duder
On 11/14/12 11:20 AM, "Gord Tanner" <gt...@gmail.com> wrote:
>+1 that this is suspect.
>
>I know it just returns what webworks is telling us, we probably need to
>read the userAgent or go to native.
>
>Assign the jira to me and I can get this cleaned up for this version.
>
>Sent from my iPhone
>
>On 2012-11-14, at 2:14 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> Resurrecting this one.
>>
>> BlackBerry has the same issue sorta.
>>
>> I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
>>When I
>> ask for "device.version", I get "BlackBerry Playbook OS" for both.
>>
>> Device.name also returns weird stuff for the play books, seem like
>> arbitrary numbers: 100669958.
>>
>> Also, device.platform returns "playbook". Shouldn't this be
>>"BlackBerry" ?
>>
>> /cc anyone from RIM
>>
>> On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote:
>>
>>> thanks shaz
>>>
>>>
>>> On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
>>>
>>>> Added:
>>>>
>>>> http://issues.cordova.io/1836
>>>> http://issues.cordova.io/1837
>>>> http://issues.cordova.io/1838
>>>> http://issues.cordova.io/1839
>>>> http://issues.cordova.io/1840
>>>>
>>>>
>>>>
>>>> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
>>>>
>>>>> Adding jira tasks as per Brian's last comment.
>>>>>
>>>>>
>>>>> On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
>>>>>
>>>>>> +1 sounds like a plan
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>>>>>>
>>>>>>>> I think would it make sense to:
>>>>>>>>
>>>>>>>> 1. align apis as orig msg from fil suggests
>>>>>>>> 2. drop in deprecation notice for sync usage and add to deprec
>>>>>>>>page
>>>>>>>> 3. add async equiv and get it out of startup path as andrew
>>>> suggests
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
>>>>>>>>
>>>>>>>>> Although I think we're close to being able to author
>>>> cross-platform
>>>>>>> apps
>>>>>>>>> sans UA detection , I think people still have valid use cases to
>>>> use
>>>>>>> it.
>>>>>>>>>
>>>>>>>>> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>> I like the idea of at least removing this from the start-up
>>>> path.
>>>> If
>>>>>>>>> users
>>>>>>>>>> want to know about the device, they could always call exec()
>>>>>>>>> themselves.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Also, if we remove the device API like Brian suggested, it
>>>> would
>>>> be
>>>>>>>>>>> good in
>>>>>>>>>>> the sense that we won't have to call the CDVDevice plugin to
>>>>>>> populate
>>>>>>>>>>> some
>>>>>>>>>>> js variables before deviceready can fire -- eliminating a
>>>>>>> dependency.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Agree with Fil to make it consistent - in essence this is an
>>>> iOS
>>>>>>>>> bug
>>>>>>>>>>> :)
>>>>>>>>>>>>
>>>>>>>>>>>> Brian, there is one case I can think of -- detecting the
>>>> iPad
>>>>>>>>> mini's
>>>>>>>>>>>> features using js - Max Firt investigated trying to do it
>>>>
>>>>
>>>>http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
>>>>bu
>>>>>>>>>>> tthe only kludgy way right now using PG would be
>>>> device.platform
>>>> to
>>>>>>>>>>>> detect iPad2,5 and iPad2,6. I suppose ppl would need to
>>>> detect
>>>>>>>>> this to
>>>>>>>>>>>> enlarge certain UI elements for the mini (since the physical
>>>> area
>>>>>>>>>>> will be
>>>>>>>>>>>> smaller than a reg sized iPad)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com>
>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> CI implementation is what I am gunning for here (and can
>>>>>>> actually
>>>>>>>>> use
>>>>>>>>>>> it).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't like it either but reality is for people building
>>>>>>>>>>> cross-platform
>>>>>>>>>>>>> apps at some point you have to do:
>>>>>>>>>>>>>
>>>>>>>>>>>>> if (device.platform == 'android') // do some stuff
>>>>>>>>>>>>>
>>>>>>>>>>>>> For example, knowing when to attach to a back button vs
>>>>>>> rendering
>>>>>>>>>>> some
>>>>>>>>>>> ui
>>>>>>>>>>>>> to handle that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> IMO we should set up deprecation for "name" and move to
>>>> "model"
>>>>>>> as
>>>>>>>>>>> it's
>>>>>>>>>>>>> clearer (and probably was the reason why iOS went for
>>>> device's
>>>>>>>>> custom
>>>>>>>>>>> name
>>>>>>>>>>>>> in the first place - semantic confusion :P )
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This may get some rotton tomatoes thrown at me but I
>>>> would be
>>>>>>> in
>>>>>>>>>>> favor
>>>>>>>>>>> of
>>>>>>>>>>>>>> axing these apis altogether. I think they are more
>>>> dangerous
>>>>>>> than
>>>>>>>>>>> useful
>>>>>>>>>>>>> /
>>>>>>>>>>>>>> developers should favor browser feature detection for
>>>> their
>>>> UI
>>>>>>>>> work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is no programmatic reason to want these properties
>>>>>>>>> otherwise
>>>>>>>>>>> that I
>>>>>>>>>>>>>> can think of?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (But agree at least should be consistent as Fil suggests.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com>
>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Currently if you ask for device.platform you will get
>>>> several
>>>>>>>>>>> different
>>>>>>>>>>>>>>> responses on iOS. You'll get iPhone, iPad, iPod Touch,
>>>> etc.
>>>>>>>>> This
>>>>>>>>>>> seems
>>>>>>>>>>>>>>> backwards. IMO all of these should return 'iOS'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Related, device.name returns the custom device name as
>>>> the
>>>>>>> user
>>>>>>>>>>>>> defines
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> in iTunes. IMO it should return the model name, I.e.
>>>> What
>>>>>>>>>>>>>>> device.platform
>>>>>>>>>>>>>>> returns now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This would line it up with our docs + other platforms.
>>
Re: iOS' device API
Posted by Filip Maj <fi...@adobe.com>.
Gord I added https://issues.apache.org/jira/browse/CB-1848
On 11/14/12 11:20 AM, "Gord Tanner" <gt...@gmail.com> wrote:
>+1 that this is suspect.
>
>I know it just returns what webworks is telling us, we probably need to
>read the userAgent or go to native.
>
>Assign the jira to me and I can get this cleaned up for this version.
>
>Sent from my iPhone
>
>On 2012-11-14, at 2:14 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> Resurrecting this one.
>>
>> BlackBerry has the same issue sorta.
>>
>> I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx.
>>When I
>> ask for "device.version", I get "BlackBerry Playbook OS" for both.
>>
>> Device.name also returns weird stuff for the play books, seem like
>> arbitrary numbers: 100669958.
>>
>> Also, device.platform returns "playbook". Shouldn't this be
>>"BlackBerry" ?
>>
>> /cc anyone from RIM
>>
>> On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote:
>>
>>> thanks shaz
>>>
>>>
>>> On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
>>>
>>>> Added:
>>>>
>>>> http://issues.cordova.io/1836
>>>> http://issues.cordova.io/1837
>>>> http://issues.cordova.io/1838
>>>> http://issues.cordova.io/1839
>>>> http://issues.cordova.io/1840
>>>>
>>>>
>>>>
>>>> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
>>>>
>>>>> Adding jira tasks as per Brian's last comment.
>>>>>
>>>>>
>>>>> On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
>>>>>
>>>>>> +1 sounds like a plan
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>>>>>>
>>>>>>>> I think would it make sense to:
>>>>>>>>
>>>>>>>> 1. align apis as orig msg from fil suggests
>>>>>>>> 2. drop in deprecation notice for sync usage and add to deprec
>>>>>>>>page
>>>>>>>> 3. add async equiv and get it out of startup path as andrew
>>>> suggests
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
>>>>>>>>
>>>>>>>>> Although I think we're close to being able to author
>>>> cross-platform
>>>>>>> apps
>>>>>>>>> sans UA detection , I think people still have valid use cases to
>>>> use
>>>>>>> it.
>>>>>>>>>
>>>>>>>>> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>> I like the idea of at least removing this from the start-up
>>>> path.
>>>> If
>>>>>>>>> users
>>>>>>>>>> want to know about the device, they could always call exec()
>>>>>>>>> themselves.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Also, if we remove the device API like Brian suggested, it
>>>> would
>>>> be
>>>>>>>>>>> good in
>>>>>>>>>>> the sense that we won't have to call the CDVDevice plugin to
>>>>>>> populate
>>>>>>>>>>> some
>>>>>>>>>>> js variables before deviceready can fire -- eliminating a
>>>>>>> dependency.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Agree with Fil to make it consistent - in essence this is an
>>>> iOS
>>>>>>>>> bug
>>>>>>>>>>> :)
>>>>>>>>>>>>
>>>>>>>>>>>> Brian, there is one case I can think of -- detecting the
>>>> iPad
>>>>>>>>> mini's
>>>>>>>>>>>> features using js - Max Firt investigated trying to do it
>>>>
>>>>
>>>>http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent
>>>>bu
>>>>>>>>>>> tthe only kludgy way right now using PG would be
>>>> device.platform
>>>> to
>>>>>>>>>>>> detect iPad2,5 and iPad2,6. I suppose ppl would need to
>>>> detect
>>>>>>>>> this to
>>>>>>>>>>>> enlarge certain UI elements for the mini (since the physical
>>>> area
>>>>>>>>>>> will be
>>>>>>>>>>>> smaller than a reg sized iPad)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com>
>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> CI implementation is what I am gunning for here (and can
>>>>>>> actually
>>>>>>>>> use
>>>>>>>>>>> it).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't like it either but reality is for people building
>>>>>>>>>>> cross-platform
>>>>>>>>>>>>> apps at some point you have to do:
>>>>>>>>>>>>>
>>>>>>>>>>>>> if (device.platform == 'android') // do some stuff
>>>>>>>>>>>>>
>>>>>>>>>>>>> For example, knowing when to attach to a back button vs
>>>>>>> rendering
>>>>>>>>>>> some
>>>>>>>>>>> ui
>>>>>>>>>>>>> to handle that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> IMO we should set up deprecation for "name" and move to
>>>> "model"
>>>>>>> as
>>>>>>>>>>> it's
>>>>>>>>>>>>> clearer (and probably was the reason why iOS went for
>>>> device's
>>>>>>>>> custom
>>>>>>>>>>> name
>>>>>>>>>>>>> in the first place - semantic confusion :P )
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This may get some rotton tomatoes thrown at me but I
>>>> would be
>>>>>>> in
>>>>>>>>>>> favor
>>>>>>>>>>> of
>>>>>>>>>>>>>> axing these apis altogether. I think they are more
>>>> dangerous
>>>>>>> than
>>>>>>>>>>> useful
>>>>>>>>>>>>> /
>>>>>>>>>>>>>> developers should favor browser feature detection for
>>>> their
>>>> UI
>>>>>>>>> work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is no programmatic reason to want these properties
>>>>>>>>> otherwise
>>>>>>>>>>> that I
>>>>>>>>>>>>>> can think of?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (But agree at least should be consistent as Fil suggests.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com>
>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Currently if you ask for device.platform you will get
>>>> several
>>>>>>>>>>> different
>>>>>>>>>>>>>>> responses on iOS. You'll get iPhone, iPad, iPod Touch,
>>>> etc.
>>>>>>>>> This
>>>>>>>>>>> seems
>>>>>>>>>>>>>>> backwards. IMO all of these should return 'iOS'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Related, device.name returns the custom device name as
>>>> the
>>>>>>> user
>>>>>>>>>>>>> defines
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> in iTunes. IMO it should return the model name, I.e.
>>>> What
>>>>>>>>>>>>>>> device.platform
>>>>>>>>>>>>>>> returns now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This would line it up with our docs + other platforms.
>>
Re: iOS' device API
Posted by Gord Tanner <gt...@gmail.com>.
+1 that this is suspect.
I know it just returns what webworks is telling us, we probably need to read the userAgent or go to native.
Assign the jira to me and I can get this cleaned up for this version.
Sent from my iPhone
On 2012-11-14, at 2:14 PM, Filip Maj <fi...@adobe.com> wrote:
> Resurrecting this one.
>
> BlackBerry has the same issue sorta.
>
> I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx. When I
> ask for "device.version", I get "BlackBerry Playbook OS" for both.
>
> Device.name also returns weird stuff for the play books, seem like
> arbitrary numbers: 100669958.
>
> Also, device.platform returns "playbook". Shouldn't this be "BlackBerry" ?
>
> /cc anyone from RIM
>
> On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote:
>
>> thanks shaz
>>
>>
>> On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
>>
>>> Added:
>>>
>>> http://issues.cordova.io/1836
>>> http://issues.cordova.io/1837
>>> http://issues.cordova.io/1838
>>> http://issues.cordova.io/1839
>>> http://issues.cordova.io/1840
>>>
>>>
>>>
>>> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
>>>
>>>> Adding jira tasks as per Brian's last comment.
>>>>
>>>>
>>>> On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
>>>>
>>>>> +1 sounds like a plan
>>>>>
>>>>>
>>>>> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>>>>>
>>>>>>> I think would it make sense to:
>>>>>>>
>>>>>>> 1. align apis as orig msg from fil suggests
>>>>>>> 2. drop in deprecation notice for sync usage and add to deprec page
>>>>>>> 3. add async equiv and get it out of startup path as andrew
>>> suggests
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
>>>>>>>
>>>>>>>> Although I think we're close to being able to author
>>> cross-platform
>>>>>> apps
>>>>>>>> sans UA detection , I think people still have valid use cases to
>>> use
>>>>>> it.
>>>>>>>>
>>>>>>>> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>>>>>>>
>>>>>>>>> I like the idea of at least removing this from the start-up
>>> path.
>>> If
>>>>>>>> users
>>>>>>>>> want to know about the device, they could always call exec()
>>>>>>>> themselves.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com>
>>> wrote:
>>>>>>>>>
>>>>>>>>>> Also, if we remove the device API like Brian suggested, it
>>> would
>>> be
>>>>>>>>>> good in
>>>>>>>>>> the sense that we won't have to call the CDVDevice plugin to
>>>>>> populate
>>>>>>>>>> some
>>>>>>>>>> js variables before deviceready can fire -- eliminating a
>>>>>> dependency.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Agree with Fil to make it consistent - in essence this is an
>>> iOS
>>>>>>>> bug
>>>>>>>>>> :)
>>>>>>>>>>>
>>>>>>>>>>> Brian, there is one case I can think of -- detecting the
>>> iPad
>>>>>>>> mini's
>>>>>>>>>>> features using js - Max Firt investigated trying to do it
>>>
>>> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>>>>>>>>>> tthe only kludgy way right now using PG would be
>>> device.platform
>>> to
>>>>>>>>>>> detect iPad2,5 and iPad2,6. I suppose ppl would need to
>>> detect
>>>>>>>> this to
>>>>>>>>>>> enlarge certain UI elements for the mini (since the physical
>>> area
>>>>>>>>>> will be
>>>>>>>>>>> smaller than a reg sized iPad)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com>
>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> CI implementation is what I am gunning for here (and can
>>>>>> actually
>>>>>>>> use
>>>>>>>>>> it).
>>>>>>>>>>>>
>>>>>>>>>>>> I don't like it either but reality is for people building
>>>>>>>>>> cross-platform
>>>>>>>>>>>> apps at some point you have to do:
>>>>>>>>>>>>
>>>>>>>>>>>> if (device.platform == 'android') // do some stuff
>>>>>>>>>>>>
>>>>>>>>>>>> For example, knowing when to attach to a back button vs
>>>>>> rendering
>>>>>>>>>> some
>>>>>>>>>> ui
>>>>>>>>>>>> to handle that.
>>>>>>>>>>>>
>>>>>>>>>>>> IMO we should set up deprecation for "name" and move to
>>> "model"
>>>>>> as
>>>>>>>>>> it's
>>>>>>>>>>>> clearer (and probably was the reason why iOS went for
>>> device's
>>>>>>>> custom
>>>>>>>>>> name
>>>>>>>>>>>> in the first place - semantic confusion :P )
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> This may get some rotton tomatoes thrown at me but I
>>> would be
>>>>>> in
>>>>>>>>>> favor
>>>>>>>>>> of
>>>>>>>>>>>>> axing these apis altogether. I think they are more
>>> dangerous
>>>>>> than
>>>>>>>>>> useful
>>>>>>>>>>>> /
>>>>>>>>>>>>> developers should favor browser feature detection for
>>> their
>>> UI
>>>>>>>> work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is no programmatic reason to want these properties
>>>>>>>> otherwise
>>>>>>>>>> that I
>>>>>>>>>>>>> can think of?
>>>>>>>>>>>>>
>>>>>>>>>>>>> (But agree at least should be consistent as Fil suggests.)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com>
>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Currently if you ask for device.platform you will get
>>> several
>>>>>>>>>> different
>>>>>>>>>>>>>> responses on iOS. You'll get iPhone, iPad, iPod Touch,
>>> etc.
>>>>>>>> This
>>>>>>>>>> seems
>>>>>>>>>>>>>> backwards. IMO all of these should return 'iOS'.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Related, device.name returns the custom device name as
>>> the
>>>>>> user
>>>>>>>>>>>> defines
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> in iTunes. IMO it should return the model name, I.e.
>>> What
>>>>>>>>>>>>>> device.platform
>>>>>>>>>>>>>> returns now.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would line it up with our docs + other platforms.
>
Re: iOS' device API
Posted by Filip Maj <fi...@adobe.com>.
Resurrecting this one.
BlackBerry has the same issue sorta.
I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx. When I
ask for "device.version", I get "BlackBerry Playbook OS" for both.
Device.name also returns weird stuff for the play books, seem like
arbitrary numbers: 100669958.
Also, device.platform returns "playbook". Shouldn't this be "BlackBerry" ?
/cc anyone from RIM
On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote:
>thanks shaz
>
>
>On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
>
>> Added:
>>
>> http://issues.cordova.io/1836
>> http://issues.cordova.io/1837
>> http://issues.cordova.io/1838
>> http://issues.cordova.io/1839
>> http://issues.cordova.io/1840
>>
>>
>>
>> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
>>
>> > Adding jira tasks as per Brian's last comment.
>> >
>> >
>> > On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
>> >
>> >> +1 sounds like a plan
>> >>
>> >>
>> >> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
>> >>
>> >>> +1
>> >>>
>> >>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >>>
>> >>> >I think would it make sense to:
>> >>> >
>> >>> >1. align apis as orig msg from fil suggests
>> >>> >2. drop in deprecation notice for sync usage and add to deprec page
>> >>> >3. add async equiv and get it out of startup path as andrew
>>suggests
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
>> >>> >
>> >>> >> Although I think we're close to being able to author
>>cross-platform
>> >>> apps
>> >>> >> sans UA detection , I think people still have valid use cases to
>>use
>> >>> it.
>> >>> >>
>> >>> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >>> >>
>> >>> >> >I like the idea of at least removing this from the start-up
>>path.
>> If
>> >>> >>users
>> >>> >> >want to know about the device, they could always call exec()
>> >>> >>themselves.
>> >>> >> >
>> >>> >> >
>> >>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com>
>>wrote:
>> >>> >> >
>> >>> >> >> Also, if we remove the device API like Brian suggested, it
>>would
>> be
>> >>> >> >>good in
>> >>> >> >> the sense that we won't have to call the CDVDevice plugin to
>> >>> populate
>> >>> >> >>some
>> >>> >> >> js variables before deviceready can fire -- eliminating a
>> >>> dependency.
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com>
>> >>> wrote:
>> >>> >> >>
>> >>> >> >> > Agree with Fil to make it consistent - in essence this is an
>> iOS
>> >>> >>bug
>> >>> >> >>:)
>> >>> >> >> >
>> >>> >> >> > Brian, there is one case I can think of -- detecting the
>>iPad
>> >>> >>mini's
>> >>> >> >> > features using js - Max Firt investigated trying to do it
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >>
>> >>> >>
>> >>> >>
>> >>>
>>
>>http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>> >>> >> >>tthe only kludgy way right now using PG would be
>>device.platform
>> to
>> >>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to
>>detect
>> >>> >>this to
>> >>> >> >> > enlarge certain UI elements for the mini (since the physical
>> area
>> >>> >> >>will be
>> >>> >> >> > smaller than a reg sized iPad)
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com>
>> >>> wrote:
>> >>> >> >> >
>> >>> >> >> >> CI implementation is what I am gunning for here (and can
>> >>> actually
>> >>> >>use
>> >>> >> >> it).
>> >>> >> >> >>
>> >>> >> >> >> I don't like it either but reality is for people building
>> >>> >> >>cross-platform
>> >>> >> >> >> apps at some point you have to do:
>> >>> >> >> >>
>> >>> >> >> >> if (device.platform == 'android') // do some stuff
>> >>> >> >> >>
>> >>> >> >> >> For example, knowing when to attach to a back button vs
>> >>> rendering
>> >>> >> >>some
>> >>> >> >> ui
>> >>> >> >> >> to handle that.
>> >>> >> >> >>
>> >>> >> >> >> IMO we should set up deprecation for "name" and move to
>> "model"
>> >>> as
>> >>> >> >>it's
>> >>> >> >> >> clearer (and probably was the reason why iOS went for
>>device's
>> >>> >>custom
>> >>> >> >> name
>> >>> >> >> >> in the first place - semantic confusion :P )
>> >>> >> >> >>
>> >>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >>> >> >> >>
>> >>> >> >> >> >This may get some rotton tomatoes thrown at me but I
>>would be
>> >>> in
>> >>> >> >>favor
>> >>> >> >> of
>> >>> >> >> >> >axing these apis altogether. I think they are more
>>dangerous
>> >>> than
>> >>> >> >> useful
>> >>> >> >> >> /
>> >>> >> >> >> >developers should favor browser feature detection for
>>their
>> UI
>> >>> >>work.
>> >>> >> >> >> >
>> >>> >> >> >> >There is no programmatic reason to want these properties
>> >>> >>otherwise
>> >>> >> >> that I
>> >>> >> >> >> >can think of?
>> >>> >> >> >> >
>> >>> >> >> >> >(But agree at least should be consistent as Fil suggests.)
>> >>> >> >> >> >
>> >>> >> >> >> >
>> >>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com>
>> >>> wrote:
>> >>> >> >> >> >
>> >>> >> >> >> >> Currently if you ask for device.platform you will get
>> several
>> >>> >> >> different
>> >>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch,
>>etc.
>> >>> >>This
>> >>> >> >> seems
>> >>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
>> >>> >> >> >> >>
>> >>> >> >> >> >> Related, device.name returns the custom device name as
>>the
>> >>> user
>> >>> >> >> >> defines
>> >>> >> >> >> >>it
>> >>> >> >> >> >> in iTunes. IMO it should return the model name, I.e.
>>What
>> >>> >> >> >> >>device.platform
>> >>> >> >> >> >> returns now.
>> >>> >> >> >> >>
>> >>> >> >> >> >> This would line it up with our docs + other platforms.
>> >>> >> >> >> >>
>> >>> >> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >
>> >>> >> >>
>> >>> >>
>> >>> >>
>> >>>
>> >>>
>> >>
>> >
>>
Re: iOS' device API
Posted by Brian LeRoux <b...@brian.io>.
thanks shaz
On Tue, Nov 13, 2012 at 6:39 AM, Shazron <sh...@gmail.com> wrote:
> Added:
>
> http://issues.cordova.io/1836
> http://issues.cordova.io/1837
> http://issues.cordova.io/1838
> http://issues.cordova.io/1839
> http://issues.cordova.io/1840
>
>
>
> On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
>
> > Adding jira tasks as per Brian's last comment.
> >
> >
> > On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
> >
> >> +1 sounds like a plan
> >>
> >>
> >> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
> >>
> >>> +1
> >>>
> >>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >>>
> >>> >I think would it make sense to:
> >>> >
> >>> >1. align apis as orig msg from fil suggests
> >>> >2. drop in deprecation notice for sync usage and add to deprec page
> >>> >3. add async equiv and get it out of startup path as andrew suggests
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
> >>> >
> >>> >> Although I think we're close to being able to author cross-platform
> >>> apps
> >>> >> sans UA detection , I think people still have valid use cases to use
> >>> it.
> >>> >>
> >>> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >>> >>
> >>> >> >I like the idea of at least removing this from the start-up path.
> If
> >>> >>users
> >>> >> >want to know about the device, they could always call exec()
> >>> >>themselves.
> >>> >> >
> >>> >> >
> >>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:
> >>> >> >
> >>> >> >> Also, if we remove the device API like Brian suggested, it would
> be
> >>> >> >>good in
> >>> >> >> the sense that we won't have to call the CDVDevice plugin to
> >>> populate
> >>> >> >>some
> >>> >> >> js variables before deviceready can fire -- eliminating a
> >>> dependency.
> >>> >> >>
> >>> >> >>
> >>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com>
> >>> wrote:
> >>> >> >>
> >>> >> >> > Agree with Fil to make it consistent - in essence this is an
> iOS
> >>> >>bug
> >>> >> >>:)
> >>> >> >> >
> >>> >> >> > Brian, there is one case I can think of -- detecting the iPad
> >>> >>mini's
> >>> >> >> > features using js - Max Firt investigated trying to do it
> >>> >> >> >
> >>> >> >>
> >>> >> >>
> >>> >>
> >>> >>
> >>>
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
> >>> >> >>tthe only kludgy way right now using PG would be device.platform
> to
> >>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect
> >>> >>this to
> >>> >> >> > enlarge certain UI elements for the mini (since the physical
> area
> >>> >> >>will be
> >>> >> >> > smaller than a reg sized iPad)
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com>
> >>> wrote:
> >>> >> >> >
> >>> >> >> >> CI implementation is what I am gunning for here (and can
> >>> actually
> >>> >>use
> >>> >> >> it).
> >>> >> >> >>
> >>> >> >> >> I don't like it either but reality is for people building
> >>> >> >>cross-platform
> >>> >> >> >> apps at some point you have to do:
> >>> >> >> >>
> >>> >> >> >> if (device.platform == 'android') // do some stuff
> >>> >> >> >>
> >>> >> >> >> For example, knowing when to attach to a back button vs
> >>> rendering
> >>> >> >>some
> >>> >> >> ui
> >>> >> >> >> to handle that.
> >>> >> >> >>
> >>> >> >> >> IMO we should set up deprecation for "name" and move to
> "model"
> >>> as
> >>> >> >>it's
> >>> >> >> >> clearer (and probably was the reason why iOS went for device's
> >>> >>custom
> >>> >> >> name
> >>> >> >> >> in the first place - semantic confusion :P )
> >>> >> >> >>
> >>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >>> >> >> >>
> >>> >> >> >> >This may get some rotton tomatoes thrown at me but I would be
> >>> in
> >>> >> >>favor
> >>> >> >> of
> >>> >> >> >> >axing these apis altogether. I think they are more dangerous
> >>> than
> >>> >> >> useful
> >>> >> >> >> /
> >>> >> >> >> >developers should favor browser feature detection for their
> UI
> >>> >>work.
> >>> >> >> >> >
> >>> >> >> >> >There is no programmatic reason to want these properties
> >>> >>otherwise
> >>> >> >> that I
> >>> >> >> >> >can think of?
> >>> >> >> >> >
> >>> >> >> >> >(But agree at least should be consistent as Fil suggests.)
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com>
> >>> wrote:
> >>> >> >> >> >
> >>> >> >> >> >> Currently if you ask for device.platform you will get
> several
> >>> >> >> different
> >>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc.
> >>> >>This
> >>> >> >> seems
> >>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
> >>> >> >> >> >>
> >>> >> >> >> >> Related, device.name returns the custom device name as the
> >>> user
> >>> >> >> >> defines
> >>> >> >> >> >>it
> >>> >> >> >> >> in iTunes. IMO it should return the model name, I.e. What
> >>> >> >> >> >>device.platform
> >>> >> >> >> >> returns now.
> >>> >> >> >> >>
> >>> >> >> >> >> This would line it up with our docs + other platforms.
> >>> >> >> >> >>
> >>> >> >> >> >>
> >>> >> >> >>
> >>> >> >> >>
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>> >>
> >>>
> >>>
> >>
> >
>
Re: iOS' device API
Posted by Shazron <sh...@gmail.com>.
Added:
http://issues.cordova.io/1836
http://issues.cordova.io/1837
http://issues.cordova.io/1838
http://issues.cordova.io/1839
http://issues.cordova.io/1840
On Mon, Nov 12, 2012 at 11:14 AM, Shazron <sh...@gmail.com> wrote:
> Adding jira tasks as per Brian's last comment.
>
>
> On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
>
>> +1 sounds like a plan
>>
>>
>> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
>>
>>> +1
>>>
>>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>>
>>> >I think would it make sense to:
>>> >
>>> >1. align apis as orig msg from fil suggests
>>> >2. drop in deprecation notice for sync usage and add to deprec page
>>> >3. add async equiv and get it out of startup path as andrew suggests
>>> >
>>> >
>>> >
>>> >
>>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
>>> >
>>> >> Although I think we're close to being able to author cross-platform
>>> apps
>>> >> sans UA detection , I think people still have valid use cases to use
>>> it.
>>> >>
>>> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>> >>
>>> >> >I like the idea of at least removing this from the start-up path. If
>>> >>users
>>> >> >want to know about the device, they could always call exec()
>>> >>themselves.
>>> >> >
>>> >> >
>>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:
>>> >> >
>>> >> >> Also, if we remove the device API like Brian suggested, it would be
>>> >> >>good in
>>> >> >> the sense that we won't have to call the CDVDevice plugin to
>>> populate
>>> >> >>some
>>> >> >> js variables before deviceready can fire -- eliminating a
>>> dependency.
>>> >> >>
>>> >> >>
>>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com>
>>> wrote:
>>> >> >>
>>> >> >> > Agree with Fil to make it consistent - in essence this is an iOS
>>> >>bug
>>> >> >>:)
>>> >> >> >
>>> >> >> > Brian, there is one case I can think of -- detecting the iPad
>>> >>mini's
>>> >> >> > features using js - Max Firt investigated trying to do it
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>>> >> >>tthe only kludgy way right now using PG would be device.platform to
>>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect
>>> >>this to
>>> >> >> > enlarge certain UI elements for the mini (since the physical area
>>> >> >>will be
>>> >> >> > smaller than a reg sized iPad)
>>> >> >> >
>>> >> >> >
>>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com>
>>> wrote:
>>> >> >> >
>>> >> >> >> CI implementation is what I am gunning for here (and can
>>> actually
>>> >>use
>>> >> >> it).
>>> >> >> >>
>>> >> >> >> I don't like it either but reality is for people building
>>> >> >>cross-platform
>>> >> >> >> apps at some point you have to do:
>>> >> >> >>
>>> >> >> >> if (device.platform == 'android') // do some stuff
>>> >> >> >>
>>> >> >> >> For example, knowing when to attach to a back button vs
>>> rendering
>>> >> >>some
>>> >> >> ui
>>> >> >> >> to handle that.
>>> >> >> >>
>>> >> >> >> IMO we should set up deprecation for "name" and move to "model"
>>> as
>>> >> >>it's
>>> >> >> >> clearer (and probably was the reason why iOS went for device's
>>> >>custom
>>> >> >> name
>>> >> >> >> in the first place - semantic confusion :P )
>>> >> >> >>
>>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>> >> >> >>
>>> >> >> >> >This may get some rotton tomatoes thrown at me but I would be
>>> in
>>> >> >>favor
>>> >> >> of
>>> >> >> >> >axing these apis altogether. I think they are more dangerous
>>> than
>>> >> >> useful
>>> >> >> >> /
>>> >> >> >> >developers should favor browser feature detection for their UI
>>> >>work.
>>> >> >> >> >
>>> >> >> >> >There is no programmatic reason to want these properties
>>> >>otherwise
>>> >> >> that I
>>> >> >> >> >can think of?
>>> >> >> >> >
>>> >> >> >> >(But agree at least should be consistent as Fil suggests.)
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com>
>>> wrote:
>>> >> >> >> >
>>> >> >> >> >> Currently if you ask for device.platform you will get several
>>> >> >> different
>>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc.
>>> >>This
>>> >> >> seems
>>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
>>> >> >> >> >>
>>> >> >> >> >> Related, device.name returns the custom device name as the
>>> user
>>> >> >> >> defines
>>> >> >> >> >>it
>>> >> >> >> >> in iTunes. IMO it should return the model name, I.e. What
>>> >> >> >> >>device.platform
>>> >> >> >> >> returns now.
>>> >> >> >> >>
>>> >> >> >> >> This would line it up with our docs + other platforms.
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >>
>>> >>
>>>
>>>
>>
>
Re: iOS' device API
Posted by Shazron <sh...@gmail.com>.
Adding jira tasks as per Brian's last comment.
On Thu, Nov 8, 2012 at 9:52 AM, Shazron <sh...@gmail.com> wrote:
> +1 sounds like a plan
>
>
> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
>
>> +1
>>
>> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>
>> >I think would it make sense to:
>> >
>> >1. align apis as orig msg from fil suggests
>> >2. drop in deprecation notice for sync usage and add to deprec page
>> >3. add async equiv and get it out of startup path as andrew suggests
>> >
>> >
>> >
>> >
>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> >> Although I think we're close to being able to author cross-platform
>> apps
>> >> sans UA detection , I think people still have valid use cases to use
>> it.
>> >>
>> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >>
>> >> >I like the idea of at least removing this from the start-up path. If
>> >>users
>> >> >want to know about the device, they could always call exec()
>> >>themselves.
>> >> >
>> >> >
>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:
>> >> >
>> >> >> Also, if we remove the device API like Brian suggested, it would be
>> >> >>good in
>> >> >> the sense that we won't have to call the CDVDevice plugin to
>> populate
>> >> >>some
>> >> >> js variables before deviceready can fire -- eliminating a
>> dependency.
>> >> >>
>> >> >>
>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
>> >> >>
>> >> >> > Agree with Fil to make it consistent - in essence this is an iOS
>> >>bug
>> >> >>:)
>> >> >> >
>> >> >> > Brian, there is one case I can think of -- detecting the iPad
>> >>mini's
>> >> >> > features using js - Max Firt investigated trying to do it
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>> >> >>tthe only kludgy way right now using PG would be device.platform to
>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect
>> >>this to
>> >> >> > enlarge certain UI elements for the mini (since the physical area
>> >> >>will be
>> >> >> > smaller than a reg sized iPad)
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com> wrote:
>> >> >> >
>> >> >> >> CI implementation is what I am gunning for here (and can actually
>> >>use
>> >> >> it).
>> >> >> >>
>> >> >> >> I don't like it either but reality is for people building
>> >> >>cross-platform
>> >> >> >> apps at some point you have to do:
>> >> >> >>
>> >> >> >> if (device.platform == 'android') // do some stuff
>> >> >> >>
>> >> >> >> For example, knowing when to attach to a back button vs rendering
>> >> >>some
>> >> >> ui
>> >> >> >> to handle that.
>> >> >> >>
>> >> >> >> IMO we should set up deprecation for "name" and move to "model"
>> as
>> >> >>it's
>> >> >> >> clearer (and probably was the reason why iOS went for device's
>> >>custom
>> >> >> name
>> >> >> >> in the first place - semantic confusion :P )
>> >> >> >>
>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >> >> >>
>> >> >> >> >This may get some rotton tomatoes thrown at me but I would be in
>> >> >>favor
>> >> >> of
>> >> >> >> >axing these apis altogether. I think they are more dangerous
>> than
>> >> >> useful
>> >> >> >> /
>> >> >> >> >developers should favor browser feature detection for their UI
>> >>work.
>> >> >> >> >
>> >> >> >> >There is no programmatic reason to want these properties
>> >>otherwise
>> >> >> that I
>> >> >> >> >can think of?
>> >> >> >> >
>> >> >> >> >(But agree at least should be consistent as Fil suggests.)
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com>
>> wrote:
>> >> >> >> >
>> >> >> >> >> Currently if you ask for device.platform you will get several
>> >> >> different
>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc.
>> >>This
>> >> >> seems
>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
>> >> >> >> >>
>> >> >> >> >> Related, device.name returns the custom device name as the
>> user
>> >> >> >> defines
>> >> >> >> >>it
>> >> >> >> >> in iTunes. IMO it should return the model name, I.e. What
>> >> >> >> >>device.platform
>> >> >> >> >> returns now.
>> >> >> >> >>
>> >> >> >> >> This would line it up with our docs + other platforms.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >>
>> >>
>>
>>
>
Re: iOS' device API
Posted by Shazron <sh...@gmail.com>.
+1 sounds like a plan
On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fi...@adobe.com> wrote:
> +1
>
> On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>
> >I think would it make sense to:
> >
> >1. align apis as orig msg from fil suggests
> >2. drop in deprecation notice for sync usage and add to deprec page
> >3. add async equiv and get it out of startup path as andrew suggests
> >
> >
> >
> >
> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> Although I think we're close to being able to author cross-platform apps
> >> sans UA detection , I think people still have valid use cases to use it.
> >>
> >> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >>
> >> >I like the idea of at least removing this from the start-up path. If
> >>users
> >> >want to know about the device, they could always call exec()
> >>themselves.
> >> >
> >> >
> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:
> >> >
> >> >> Also, if we remove the device API like Brian suggested, it would be
> >> >>good in
> >> >> the sense that we won't have to call the CDVDevice plugin to populate
> >> >>some
> >> >> js variables before deviceready can fire -- eliminating a dependency.
> >> >>
> >> >>
> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
> >> >>
> >> >> > Agree with Fil to make it consistent - in essence this is an iOS
> >>bug
> >> >>:)
> >> >> >
> >> >> > Brian, there is one case I can think of -- detecting the iPad
> >>mini's
> >> >> > features using js - Max Firt investigated trying to do it
> >> >> >
> >> >>
> >> >>
> >>
> >>
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
> >> >>tthe only kludgy way right now using PG would be device.platform to
> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect
> >>this to
> >> >> > enlarge certain UI elements for the mini (since the physical area
> >> >>will be
> >> >> > smaller than a reg sized iPad)
> >> >> >
> >> >> >
> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com> wrote:
> >> >> >
> >> >> >> CI implementation is what I am gunning for here (and can actually
> >>use
> >> >> it).
> >> >> >>
> >> >> >> I don't like it either but reality is for people building
> >> >>cross-platform
> >> >> >> apps at some point you have to do:
> >> >> >>
> >> >> >> if (device.platform == 'android') // do some stuff
> >> >> >>
> >> >> >> For example, knowing when to attach to a back button vs rendering
> >> >>some
> >> >> ui
> >> >> >> to handle that.
> >> >> >>
> >> >> >> IMO we should set up deprecation for "name" and move to "model" as
> >> >>it's
> >> >> >> clearer (and probably was the reason why iOS went for device's
> >>custom
> >> >> name
> >> >> >> in the first place - semantic confusion :P )
> >> >> >>
> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >> >> >>
> >> >> >> >This may get some rotton tomatoes thrown at me but I would be in
> >> >>favor
> >> >> of
> >> >> >> >axing these apis altogether. I think they are more dangerous than
> >> >> useful
> >> >> >> /
> >> >> >> >developers should favor browser feature detection for their UI
> >>work.
> >> >> >> >
> >> >> >> >There is no programmatic reason to want these properties
> >>otherwise
> >> >> that I
> >> >> >> >can think of?
> >> >> >> >
> >> >> >> >(But agree at least should be consistent as Fil suggests.)
> >> >> >> >
> >> >> >> >
> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >> >> >
> >> >> >> >> Currently if you ask for device.platform you will get several
> >> >> different
> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc.
> >>This
> >> >> seems
> >> >> >> >> backwards. IMO all of these should return 'iOS'.
> >> >> >> >>
> >> >> >> >> Related, device.name returns the custom device name as the
> user
> >> >> >> defines
> >> >> >> >>it
> >> >> >> >> in iTunes. IMO it should return the model name, I.e. What
> >> >> >> >>device.platform
> >> >> >> >> returns now.
> >> >> >> >>
> >> >> >> >> This would line it up with our docs + other platforms.
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >>
> >>
>
>
Re: iOS' device API
Posted by Filip Maj <fi...@adobe.com>.
+1
On 11/8/12 4:01 AM, "Brian LeRoux" <b...@brian.io> wrote:
>I think would it make sense to:
>
>1. align apis as orig msg from fil suggests
>2. drop in deprecation notice for sync usage and add to deprec page
>3. add async equiv and get it out of startup path as andrew suggests
>
>
>
>
>On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> Although I think we're close to being able to author cross-platform apps
>> sans UA detection , I think people still have valid use cases to use it.
>>
>> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>
>> >I like the idea of at least removing this from the start-up path. If
>>users
>> >want to know about the device, they could always call exec()
>>themselves.
>> >
>> >
>> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:
>> >
>> >> Also, if we remove the device API like Brian suggested, it would be
>> >>good in
>> >> the sense that we won't have to call the CDVDevice plugin to populate
>> >>some
>> >> js variables before deviceready can fire -- eliminating a dependency.
>> >>
>> >>
>> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
>> >>
>> >> > Agree with Fil to make it consistent - in essence this is an iOS
>>bug
>> >>:)
>> >> >
>> >> > Brian, there is one case I can think of -- detecting the iPad
>>mini's
>> >> > features using js - Max Firt investigated trying to do it
>> >> >
>> >>
>> >>
>>
>>http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>> >>tthe only kludgy way right now using PG would be device.platform to
>> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect
>>this to
>> >> > enlarge certain UI elements for the mini (since the physical area
>> >>will be
>> >> > smaller than a reg sized iPad)
>> >> >
>> >> >
>> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com> wrote:
>> >> >
>> >> >> CI implementation is what I am gunning for here (and can actually
>>use
>> >> it).
>> >> >>
>> >> >> I don't like it either but reality is for people building
>> >>cross-platform
>> >> >> apps at some point you have to do:
>> >> >>
>> >> >> if (device.platform == 'android') // do some stuff
>> >> >>
>> >> >> For example, knowing when to attach to a back button vs rendering
>> >>some
>> >> ui
>> >> >> to handle that.
>> >> >>
>> >> >> IMO we should set up deprecation for "name" and move to "model" as
>> >>it's
>> >> >> clearer (and probably was the reason why iOS went for device's
>>custom
>> >> name
>> >> >> in the first place - semantic confusion :P )
>> >> >>
>> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >> >>
>> >> >> >This may get some rotton tomatoes thrown at me but I would be in
>> >>favor
>> >> of
>> >> >> >axing these apis altogether. I think they are more dangerous than
>> >> useful
>> >> >> /
>> >> >> >developers should favor browser feature detection for their UI
>>work.
>> >> >> >
>> >> >> >There is no programmatic reason to want these properties
>>otherwise
>> >> that I
>> >> >> >can think of?
>> >> >> >
>> >> >> >(But agree at least should be consistent as Fil suggests.)
>> >> >> >
>> >> >> >
>> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> >> >
>> >> >> >> Currently if you ask for device.platform you will get several
>> >> different
>> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc.
>>This
>> >> seems
>> >> >> >> backwards. IMO all of these should return 'iOS'.
>> >> >> >>
>> >> >> >> Related, device.name returns the custom device name as the user
>> >> >> defines
>> >> >> >>it
>> >> >> >> in iTunes. IMO it should return the model name, I.e. What
>> >> >> >>device.platform
>> >> >> >> returns now.
>> >> >> >>
>> >> >> >> This would line it up with our docs + other platforms.
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>>
>>
Re: iOS' device API
Posted by Brian LeRoux <b...@brian.io>.
I think would it make sense to:
1. align apis as orig msg from fil suggests
2. drop in deprecation notice for sync usage and add to deprec page
3. add async equiv and get it out of startup path as andrew suggests
On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj <fi...@adobe.com> wrote:
> Although I think we're close to being able to author cross-platform apps
> sans UA detection , I think people still have valid use cases to use it.
>
> On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
> >I like the idea of at least removing this from the start-up path. If users
> >want to know about the device, they could always call exec() themselves.
> >
> >
> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:
> >
> >> Also, if we remove the device API like Brian suggested, it would be
> >>good in
> >> the sense that we won't have to call the CDVDevice plugin to populate
> >>some
> >> js variables before deviceready can fire -- eliminating a dependency.
> >>
> >>
> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
> >>
> >> > Agree with Fil to make it consistent - in essence this is an iOS bug
> >>:)
> >> >
> >> > Brian, there is one case I can think of -- detecting the iPad mini's
> >> > features using js - Max Firt investigated trying to do it
> >> >
> >>
> >>
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
> >>tthe only kludgy way right now using PG would be device.platform to
> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect this to
> >> > enlarge certain UI elements for the mini (since the physical area
> >>will be
> >> > smaller than a reg sized iPad)
> >> >
> >> >
> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com> wrote:
> >> >
> >> >> CI implementation is what I am gunning for here (and can actually use
> >> it).
> >> >>
> >> >> I don't like it either but reality is for people building
> >>cross-platform
> >> >> apps at some point you have to do:
> >> >>
> >> >> if (device.platform == 'android') // do some stuff
> >> >>
> >> >> For example, knowing when to attach to a back button vs rendering
> >>some
> >> ui
> >> >> to handle that.
> >> >>
> >> >> IMO we should set up deprecation for "name" and move to "model" as
> >>it's
> >> >> clearer (and probably was the reason why iOS went for device's custom
> >> name
> >> >> in the first place - semantic confusion :P )
> >> >>
> >> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >> >>
> >> >> >This may get some rotton tomatoes thrown at me but I would be in
> >>favor
> >> of
> >> >> >axing these apis altogether. I think they are more dangerous than
> >> useful
> >> >> /
> >> >> >developers should favor browser feature detection for their UI work.
> >> >> >
> >> >> >There is no programmatic reason to want these properties otherwise
> >> that I
> >> >> >can think of?
> >> >> >
> >> >> >(But agree at least should be consistent as Fil suggests.)
> >> >> >
> >> >> >
> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >> >
> >> >> >> Currently if you ask for device.platform you will get several
> >> different
> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This
> >> seems
> >> >> >> backwards. IMO all of these should return 'iOS'.
> >> >> >>
> >> >> >> Related, device.name returns the custom device name as the user
> >> >> defines
> >> >> >>it
> >> >> >> in iTunes. IMO it should return the model name, I.e. What
> >> >> >>device.platform
> >> >> >> returns now.
> >> >> >>
> >> >> >> This would line it up with our docs + other platforms.
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >
> >>
>
>
Re: iOS' device API
Posted by Filip Maj <fi...@adobe.com>.
Although I think we're close to being able to author cross-platform apps
sans UA detection , I think people still have valid use cases to use it.
On 11/7/12 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>I like the idea of at least removing this from the start-up path. If users
>want to know about the device, they could always call exec() themselves.
>
>
>On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:
>
>> Also, if we remove the device API like Brian suggested, it would be
>>good in
>> the sense that we won't have to call the CDVDevice plugin to populate
>>some
>> js variables before deviceready can fire -- eliminating a dependency.
>>
>>
>> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
>>
>> > Agree with Fil to make it consistent - in essence this is an iOS bug
>>:)
>> >
>> > Brian, there is one case I can think of -- detecting the iPad mini's
>> > features using js - Max Firt investigated trying to do it
>> >
>>
>>http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>>tthe only kludgy way right now using PG would be device.platform to
>> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect this to
>> > enlarge certain UI elements for the mini (since the physical area
>>will be
>> > smaller than a reg sized iPad)
>> >
>> >
>> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> >> CI implementation is what I am gunning for here (and can actually use
>> it).
>> >>
>> >> I don't like it either but reality is for people building
>>cross-platform
>> >> apps at some point you have to do:
>> >>
>> >> if (device.platform == 'android') // do some stuff
>> >>
>> >> For example, knowing when to attach to a back button vs rendering
>>some
>> ui
>> >> to handle that.
>> >>
>> >> IMO we should set up deprecation for "name" and move to "model" as
>>it's
>> >> clearer (and probably was the reason why iOS went for device's custom
>> name
>> >> in the first place - semantic confusion :P )
>> >>
>> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >>
>> >> >This may get some rotton tomatoes thrown at me but I would be in
>>favor
>> of
>> >> >axing these apis altogether. I think they are more dangerous than
>> useful
>> >> /
>> >> >developers should favor browser feature detection for their UI work.
>> >> >
>> >> >There is no programmatic reason to want these properties otherwise
>> that I
>> >> >can think of?
>> >> >
>> >> >(But agree at least should be consistent as Fil suggests.)
>> >> >
>> >> >
>> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> >
>> >> >> Currently if you ask for device.platform you will get several
>> different
>> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This
>> seems
>> >> >> backwards. IMO all of these should return 'iOS'.
>> >> >>
>> >> >> Related, device.name returns the custom device name as the user
>> >> defines
>> >> >>it
>> >> >> in iTunes. IMO it should return the model name, I.e. What
>> >> >>device.platform
>> >> >> returns now.
>> >> >>
>> >> >> This would line it up with our docs + other platforms.
>> >> >>
>> >> >>
>> >>
>> >>
>> >
>>
Re: iOS' device API
Posted by Andrew Grieve <ag...@chromium.org>.
I like the idea of at least removing this from the start-up path. If users
want to know about the device, they could always call exec() themselves.
On Wed, Nov 7, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:
> Also, if we remove the device API like Brian suggested, it would be good in
> the sense that we won't have to call the CDVDevice plugin to populate some
> js variables before deviceready can fire -- eliminating a dependency.
>
>
> On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
>
> > Agree with Fil to make it consistent - in essence this is an iOS bug :)
> >
> > Brian, there is one case I can think of -- detecting the iPad mini's
> > features using js - Max Firt investigated trying to do it
> >
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbutthe only kludgy way right now using PG would be device.platform to
> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect this to
> > enlarge certain UI elements for the mini (since the physical area will be
> > smaller than a reg sized iPad)
> >
> >
> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> CI implementation is what I am gunning for here (and can actually use
> it).
> >>
> >> I don't like it either but reality is for people building cross-platform
> >> apps at some point you have to do:
> >>
> >> if (device.platform == 'android') // do some stuff
> >>
> >> For example, knowing when to attach to a back button vs rendering some
> ui
> >> to handle that.
> >>
> >> IMO we should set up deprecation for "name" and move to "model" as it's
> >> clearer (and probably was the reason why iOS went for device's custom
> name
> >> in the first place - semantic confusion :P )
> >>
> >> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >>
> >> >This may get some rotton tomatoes thrown at me but I would be in favor
> of
> >> >axing these apis altogether. I think they are more dangerous than
> useful
> >> /
> >> >developers should favor browser feature detection for their UI work.
> >> >
> >> >There is no programmatic reason to want these properties otherwise
> that I
> >> >can think of?
> >> >
> >> >(But agree at least should be consistent as Fil suggests.)
> >> >
> >> >
> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >
> >> >> Currently if you ask for device.platform you will get several
> different
> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This
> seems
> >> >> backwards. IMO all of these should return 'iOS'.
> >> >>
> >> >> Related, device.name returns the custom device name as the user
> >> defines
> >> >>it
> >> >> in iTunes. IMO it should return the model name, I.e. What
> >> >>device.platform
> >> >> returns now.
> >> >>
> >> >> This would line it up with our docs + other platforms.
> >> >>
> >> >>
> >>
> >>
> >
>
Accessibility + PhoneGap
Posted by Saurabh Kumar Singh <sk...@adobe.com>.
Hi,
I wanted to confirm one thing. What is the effort involved in making
PhoneGap based application accessible ?
Thanks & Regards,
Saurabh
Re: iOS' device API
Posted by Shazron <sh...@gmail.com>.
Also, if we remove the device API like Brian suggested, it would be good in
the sense that we won't have to call the CDVDevice plugin to populate some
js variables before deviceready can fire -- eliminating a dependency.
On Wed, Nov 7, 2012 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
> Agree with Fil to make it consistent - in essence this is an iOS bug :)
>
> Brian, there is one case I can think of -- detecting the iPad mini's
> features using js - Max Firt investigated trying to do it
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbut the only kludgy way right now using PG would be device.platform to
> detect iPad2,5 and iPad2,6. I suppose ppl would need to detect this to
> enlarge certain UI elements for the mini (since the physical area will be
> smaller than a reg sized iPad)
>
>
> On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com> wrote:
>
>> CI implementation is what I am gunning for here (and can actually use it).
>>
>> I don't like it either but reality is for people building cross-platform
>> apps at some point you have to do:
>>
>> if (device.platform == 'android') // do some stuff
>>
>> For example, knowing when to attach to a back button vs rendering some ui
>> to handle that.
>>
>> IMO we should set up deprecation for "name" and move to "model" as it's
>> clearer (and probably was the reason why iOS went for device's custom name
>> in the first place - semantic confusion :P )
>>
>> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>>
>> >This may get some rotton tomatoes thrown at me but I would be in favor of
>> >axing these apis altogether. I think they are more dangerous than useful
>> /
>> >developers should favor browser feature detection for their UI work.
>> >
>> >There is no programmatic reason to want these properties otherwise that I
>> >can think of?
>> >
>> >(But agree at least should be consistent as Fil suggests.)
>> >
>> >
>> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> >> Currently if you ask for device.platform you will get several different
>> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This seems
>> >> backwards. IMO all of these should return 'iOS'.
>> >>
>> >> Related, device.name returns the custom device name as the user
>> defines
>> >>it
>> >> in iTunes. IMO it should return the model name, I.e. What
>> >>device.platform
>> >> returns now.
>> >>
>> >> This would line it up with our docs + other platforms.
>> >>
>> >>
>>
>>
>
Re: iOS' device API
Posted by Shazron <sh...@gmail.com>.
Agree with Fil to make it consistent - in essence this is an iOS bug :)
Brian, there is one case I can think of -- detecting the iPad mini's
features using js - Max Firt investigated trying to do it
http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agent but
the only kludgy way right now using PG would be device.platform to detect
iPad2,5 and iPad2,6. I suppose ppl would need to detect this to enlarge
certain UI elements for the mini (since the physical area will be smaller
than a reg sized iPad)
On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj <fi...@adobe.com> wrote:
> CI implementation is what I am gunning for here (and can actually use it).
>
> I don't like it either but reality is for people building cross-platform
> apps at some point you have to do:
>
> if (device.platform == 'android') // do some stuff
>
> For example, knowing when to attach to a back button vs rendering some ui
> to handle that.
>
> IMO we should set up deprecation for "name" and move to "model" as it's
> clearer (and probably was the reason why iOS went for device's custom name
> in the first place - semantic confusion :P )
>
> On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>
> >This may get some rotton tomatoes thrown at me but I would be in favor of
> >axing these apis altogether. I think they are more dangerous than useful /
> >developers should favor browser feature detection for their UI work.
> >
> >There is no programmatic reason to want these properties otherwise that I
> >can think of?
> >
> >(But agree at least should be consistent as Fil suggests.)
> >
> >
> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> Currently if you ask for device.platform you will get several different
> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This seems
> >> backwards. IMO all of these should return 'iOS'.
> >>
> >> Related, device.name returns the custom device name as the user defines
> >>it
> >> in iTunes. IMO it should return the model name, I.e. What
> >>device.platform
> >> returns now.
> >>
> >> This would line it up with our docs + other platforms.
> >>
> >>
>
>
Re: iOS' device API
Posted by Filip Maj <fi...@adobe.com>.
CI implementation is what I am gunning for here (and can actually use it).
I don't like it either but reality is for people building cross-platform
apps at some point you have to do:
if (device.platform == 'android') // do some stuff
For example, knowing when to attach to a back button vs rendering some ui
to handle that.
IMO we should set up deprecation for "name" and move to "model" as it's
clearer (and probably was the reason why iOS went for device's custom name
in the first place - semantic confusion :P )
On 11/7/12 7:35 AM, "Brian LeRoux" <b...@brian.io> wrote:
>This may get some rotton tomatoes thrown at me but I would be in favor of
>axing these apis altogether. I think they are more dangerous than useful /
>developers should favor browser feature detection for their UI work.
>
>There is no programmatic reason to want these properties otherwise that I
>can think of?
>
>(But agree at least should be consistent as Fil suggests.)
>
>
>On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> Currently if you ask for device.platform you will get several different
>> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This seems
>> backwards. IMO all of these should return 'iOS'.
>>
>> Related, device.name returns the custom device name as the user defines
>>it
>> in iTunes. IMO it should return the model name, I.e. What
>>device.platform
>> returns now.
>>
>> This would line it up with our docs + other platforms.
>>
>>
Re: iOS' device API
Posted by Brian LeRoux <b...@brian.io>.
This may get some rotton tomatoes thrown at me but I would be in favor of
axing these apis altogether. I think they are more dangerous than useful /
developers should favor browser feature detection for their UI work.
There is no programmatic reason to want these properties otherwise that I
can think of?
(But agree at least should be consistent as Fil suggests.)
On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj <fi...@adobe.com> wrote:
> Currently if you ask for device.platform you will get several different
> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This seems
> backwards. IMO all of these should return 'iOS'.
>
> Related, device.name returns the custom device name as the user defines it
> in iTunes. IMO it should return the model name, I.e. What device.platform
> returns now.
>
> This would line it up with our docs + other platforms.
>
>