+1 that this is suspect. I know it just returns what webworks is telling us, we probably need to read the userAgent or go to native.
Assign the jira to me and I can get this cleaned up for this version. Sent from my iPhone On 2012-11-14, at 2:14 PM, Filip Maj <f...@adobe.com> wrote: > Resurrecting this one. > > BlackBerry has the same issue sorta. > > I have two play books. One is running 2.0.1.xxx, another 2.1.0.xxx. When I > ask for "device.version", I get "BlackBerry Playbook OS" for both. > > Device.name also returns weird stuff for the play books, seem like > arbitrary numbers: 100669958. > > Also, device.platform returns "playbook". Shouldn't this be "BlackBerry" ? > > /cc anyone from RIM > > On 11/12/12 7:27 PM, "Brian LeRoux" <b...@brian.io> wrote: > >> thanks shaz >> >> >> On Tue, Nov 13, 2012 at 6:39 AM, Shazron <shaz...@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 <shaz...@gmail.com> wrote: >>> >>>> Adding jira tasks as per Brian's last comment. >>>> >>>> >>>> On Thu, Nov 8, 2012 at 9:52 AM, Shazron <shaz...@gmail.com> wrote: >>>> >>>>> +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. >
