cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: iOS' device API
Date Thu, 08 Nov 2012 12:01:50 GMT
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