+1 sounds like a plan

On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj <f...@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 <f...@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" <agri...@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 <shaz...@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 <shaz...@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 <f...@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 <f...@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.
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >>
> >>
>
>

Reply via email to