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 Tue, 13 Nov 2012 03:27:17 GMT
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