I like device.model. Should we adopt it for all the platforms? +1 for me
On Wed, Nov 14, 2012 at 11:44 AM, Filip Maj <f...@adobe.com> wrote: > Yeah. Device.name is an ambiguous-sounding API. Thus my original > recommendation to deprecate device.name and add device.model or > device.hardware. > > Basically, this API should return a string that makes it clear what > hardware or model of device it is. > > On 11/14/12 11:28 AM, "Shazron" <shaz...@gmail.com> wrote: > > >I have somewhat similar concern for iOS: > >https://issues.apache.org/jira/browse/CB-1837 > > > >Wonder whether we should output the model number instead eg iPad2,5 > >This might solve the comical procedure to detect an iPad Mini (at least > >for > >Cordova): > >http://stackoverflow.com/questions/13248493/detect-ipad-mini-in-html5 > > > > > >On Wed, Nov 14, 2012 at 11:14 AM, 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. > >> >> >>> >> >> >> >> > >> >> >>> >> >> >> >> > >> >> >>> >> >> >> > >> >> >>> >> >> >> > >> >> >>> >> >> > > >> >> >>> >> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> > >> >> >>> > >> >> >> > >> >> > > >> >> > >> > >> > >
