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 shazron@gmail.com designates
 209.85.220.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAE6O_-bjmOHcPEtW3d2R40fk+FB6bWWp97aSsTMK-oQuGdauGw@mail.gmail.com>
References: 
 <CADVgkyNZVKCMYsxiz4iHExMv3bMaL0bhoabLUsJ0ZPkdw=QX=Q@mail.gmail.com>
 <CCBFE29F.10E9D%fil@adobe.com>
 <CAE6O_-bjmOHcPEtW3d2R40fk+FB6bWWp97aSsTMK-oQuGdauGw@mail.gmail.com>
From: Shazron <shazron@gmail.com>
Date: Wed, 7 Nov 2012 13:57:45 -0800
Message-ID: 
 <CAE6O_-YTZon4uQ9Pn-U-Z831Rsmi+P2F_9jrAiGaFtpm6rVk5Q@mail.gmail.com>
Subject: Re: iOS' device API
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b111a2765225f04cdeed187

--047d7b111a2765225f04cdeed187
Content-Type: text/plain; charset=ISO-8859-1

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-agentbut the 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.
>> >>
>> >>
>>
>>
>

--047d7b111a2765225f04cdeed187--