I'm currently using OpenDDR on a number of php sites to get the browser type (ie desktop, smartphone, bot, etc) and the browser name (ie Chrome, Firefox, etc) . These are then recorded for analytics and passed to the backend to allow for the detection for mobile sites.
On the PHP side it has got a built-in feature (http://php.net/manual/en/function.get-browser.php) that uses a .ini file and regular expressions, however this is relatively slow and is reliant on the http://browscap.org/ project. Most of the frameworks have stopped integrating with the browser detection libraries as they are mainly commercial. I use https://github.com/TheWeatherChannel/dClass module built into Varnish for the detection and then set additional headers that are passed to the backend. Regards Adam On 30/07/2014 02:34, Werner Keil wrote: > Simply assuming every desktopDevice must now have 1600x900 pixel is > dangerous and does not add much value to layout or responsive design, etc. > > I spoke to a friend from the PHP camp who was also in Nürnberg as speaker, > and not only in this area he once again confirmed, a majority of users > probably would not use any of these repositories, neither Open Source (like > DeviceMap/OpenDDR) nor the commercial closed-source alternatives directly > in PHP. A vast majority of "end users" or web designers rely on a framework > or content engine like Zend, Typo3, or WordPress and those engines have to > provide some level of device regognition. > > Similar for Java, the PoC (and if some of them work on the Apache site it > is nice to test it against a variety of devices before thinking to use it) > is OK as a demonstrator, but people would prefer to have the Spring Mobile, > or the JSF library of their choice use it where necessary, or Portal > servers like Liferay or Pluto. > > Werner > > On Wed, Jul 30, 2014 at 3:18 AM, Reza <[email protected]> > wrote: > >> We can definitely extend our desktop detection to do OS detection too. >> >> So the reason that we have desktop detection is for backend >> responsive/adaptive web design. Desktop users have a mouse and a much >> larger viewing area. Phone users have a touch screen and a much smaller >> viewing area. That is an extremely important distinction to be made when >> you are serving a responsive/adaptive layout. So I would be careful when >> you say that desktopDevice is quite meaningless :) >> >> Sure, there are other use cases for DeviceMap where you want to know more >> specific information about a desktop. So maybe we should step back and >> better understand who are our potential users and how they plan on using >> DeviceMap? Are they doing responsive/adaptive web design? Web analytics? >> Something else? >> >> Just an FYI, I spend a *lot* of time working with frontends, responsive, >> and adaptive designs, so my opinion is always heavily steered towards this >> use case. >> >> >> ________________________________ >> From: Werner Keil <[email protected]> >> To: "[email protected]" < >> [email protected]> >> Sent: Tuesday, July 29, 2014 8:59 PM >> Subject: Re: Take stock >> >> >> >> Based on initial OpenDDR (desktopDevice is not new btw. only got a few >> extra properties or screen "assumption" changed from 800x600 to 1600x900, >> whether that makes sense is another question) experience told us, that e.g. >> Apple devices of all kind, including MacBook, etc. had a more descriptive >> recognition based on "genericApple". >> >> Hence it is dangerous and leads to missing even the most trivial >> information like the "Windows" string for the OS if the fallback is too >> generic. >> There is a "genericLG" which could under certain circumstances act as the >> most common fallback for an LG phone with Firefox OS, but now there is a >> generic OS root, too. >> >> W3C DDR and implementations like Open/DeviceMap DDR know at least 3 >> "aspects", if you want those are extensible, so having a fallback >> "hardware" or "OS" may conflict with each other, see the "desktop" which is >> quite meaningless and loses the information that this is a "Windows" >> desktop at the moment >> >> Werner >> >> >> >> >> On Wed, Jul 30, 2014 at 2:43 AM, Werner Keil <[email protected]> >> wrote: >> >> Well there are 2 aspects, one API, the "new/alternate" client may evolve, >> and putting those things in JIRA is not wrong. >>> Whether the person responsible for a component (i.E. Reza for the Java >> client or yourself for .NET) just picks something or there is some sort of >> "voting process" (with a series of +1 or similar, see Eclipse, I also >> recall having heard about that somewhere here) that is probably worth >> considering. >>> >>> Even though design patterns are applied in most modern languages, not >> everything might be applied exactly the same way on the .NET side, so if >> you don't see the need of a "factory" for something there, just leave it. >>> >>> The data can use some care, not just for brand new platforms, and IMHO >> adding a reliable recognition of new families like Firefox OS, Blackberry >> 10 or Windows Phone 7 or 8, the certain age of the baseline means there's a >> lot to do and no need to wait. We may rarely have JIRA tickets other than >> from actual committers now, but even on GitHub there are one or two ODDR >> either overlooked or did not consider a high priority including a fix for >> BlackBerry OS which we are probbly still missing in the current device-data. >>> >>> I'm afraid, the "desktopDevice" doesn't add that much value right now, >> given I see: >>> model: browser >>> ajax_support_getelementbyid: true >>> marketing_name: - >>> displayWidth: 1600 >>> id: desktopDevice >>> device_os: - >>> xhtml_format_as_attribute: false >>> is_crawler: false >>> dual_orientation: false >>> nokia_series: 0 >>> device_os_version: - >>> nokia_edition: 0 >>> vendor: desktop >>> mobile_browser_version: - >>> ajax_support_events: true >>> is_desktop: true >>> ajax_support_inner_html: true >>> image_inlining: false >>> mobile_browser: - >>> ajax_support_event_listener: true >>> ajax_manipulate_css: true >>> displayHeight: 900 >>> is_tablet: false >>> inputDevices: - >>> ajax_support_javascript: true >>> is_wireless_device: false >>> ajax_manipulate_dom: true >>> xhtml_format_as_css_property: false >>> >>> >>> running the console demo or any comparable Java client app against a >> local Windows 7. >>> So "is_crawler" or even a new "pixel_density" which might be of relevance >> to Retina screens, could be a nice extra gimick but a default display of >> 1600x900 is meaningless for a desktop and >> http://www.useragentstring.com/index.php tells me this >>> >>> Chrome 36.0.1985.125 >>> Mozilla MozillaProductSlice. Claims to be a Mozilla based user agent, >> which is only true for Gecko browsers like Firefox and Netscape. For all >> other user agents it means 'Mozilla-compatible'. In modern browsers, this >> is only used for historical reasons. It has no real meaning anymore >>> 5.0 Mozilla version >>> Windows NT 6.1 Operating System: >>> Windows 7 >>> WOW64 (Windows-On-Windows 64-bit) A 32-bit application is running on a >> 64-bit processor >>> AppleWebKit The Web Kit provides a set of core classes to display web >> content in windows >>> 537.36 Web Kit build >>> KHTML Open Source HTML layout engine developed by the KDE project >>> like Gecko like Gecko... >>> Chrome Name : >>> Chrome >>> 36.0.1985.125 Chrome version >>> Safari Based on Safari >>> 537.36 >>> >>> >>> based on the same UA: Mozilla/5.0 (Windows NT 6.1; WOW64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36 >>> >>> So we are far from that I'm afraid, >>> Whether it's the hierarchy, that is rather likely something not only to >> be fixed or introduced for Firefox OS. >>> >>> I added an initial "genericFirefoxOS", feel free to experiment with >> extensions to that. As of now I didn't add a child device that would detect >> say: >>> Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0 >>> >>> >>> >>> Werner >>> >>> >>> On Wed, Jul 30, 2014 at 1:59 AM, eberhard speer jr. <[email protected]> >> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hey guys, >>>> >>>> can you please "hold your horses" for a minute ? >>>> >>>> I think we all agree a review of the Vocabulary is in order -- for >>>> example -- but 'quickly' adding "is_somethingOrOther" to a 'patch' >>>> file and mentioning it in JIRA does not strike me as proper. >>>> >>>> And I think the same goes for 'quickly' turning this, that and the >>>> other into a "Factory" and adding a 'this' and a 'that' left, right >>>> and center to the API. >>>> >>>> It seems to me that after the recent votes, we should take stock of >>>> the situation, agree on what's next and *then* do the next thing. >>>> >>>> esjr >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2.0.22 (MingW32) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iQEcBAEBAgAGBQJT2DV8AAoJEOxywXcFLKYcYwsH/RdIh7MmDONA9J0/CeSpES+B >>>> iEcK235gz+YkJtV7pmm/XhMsRs4CDAYBIqpCNik7DR7Im1PAdgElSEliXc/4uQoQ >>>> vWIBXqpb/KyVab8Q74GX9obHezAIOBGZW/+ZCWcmuNceCSLYBiA5DT5Ym0nyC6+Q >>>> 4cRL1iQtfdewaAWblijEQG80QV0bfBBVhycHR0FZB1a8i+IXyQTcltP9LnngGy4L >>>> +wk8FkbdvnE9LftezvpZQz4Z9dxf+8n1Q7+T1zS9s82Q93EmrpClVveEbv6/emBN >>>> byayrXInTksgDiLRTx5ZFYq5W4AofxBTfue0/9MJ24uQKzoa5TKqjM2BpVePCZA= >>>> =Fsfe >>>> -----END PGP SIGNATURE----- >>>>
