cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: iOS' device API
Date Wed, 14 Nov 2012 20:00:06 GMT
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 <fil@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" <shazron@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 <fil@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message