Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of fil@adobe.com designates
 64.18.1.236 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Thu, 8 Nov 2012 09:34:19 -0800
Subject: Re: iOS' device API
Thread-Topic: iOS' device API
Thread-Index: Ac2910cXwnXxmEpmTiOVcE9bl8bhgA==
Message-ID: <CCC12D1A.10FA4%fil@adobe.com>
In-Reply-To: 
 <CADVgkyNHXcx3Yf07Pq=eJ4u4dWoc7bpMiVES3RkQp22nsC+ScA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.4.120824
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

+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
>> >> >
>> >>
>> >>
>>=20
>>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 =3D=3D '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.
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>>
>>