cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: iOS' device API
Date Wed, 14 Nov 2012 19:14:02 GMT
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 <shazron@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 <shazron@gmail.com> wrote:
>>
>> > Adding jira tasks as per Brian's last comment.
>> >
>> >
>> > On Thu, Nov 8, 2012 at 9:52 AM, Shazron <shazron@gmail.com> wrote:
>> >
>> >> +1 sounds like a plan
>> >>
>> >>
>> >> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <fil@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 <fil@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" <agrieve@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 <shazron@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 <shazron@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 <fil@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 <fil@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.
>> >>> >> >> >> >>
>> >>> >> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >>
>> >>> >> >> >
>> >>> >> >>
>> >>> >>
>> >>> >>
>> >>>
>> >>>
>> >>
>> >
>>


Mime
View raw message