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