Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative ways of obtaining device information (other than UA string)? #118

Open
demianrenzulli opened this issue Feb 4, 2020 · 4 comments

Comments

@demianrenzulli
Copy link

HI folks,

This is a great project. I'm starting to get into the details of this solution, as companies are starting to ask for it.

Reading the docs, it seems like you are using the UA string to obtain some device info. Now that there's an ongoing proposal to deprecate and freeze the UA, are you thinking on alternative ways of obtaining this info?

Seems like the most obvious one would be using client-hints (which you have already discussed here). The current limitation being that you can't get these signals in the first page load (although that might change).

I'm wondering if you guys are contemplating this scenario, and have any thoughts or recommendations around it.

@anton-karlovskiy
Copy link
Contributor

anton-karlovskiy commented Feb 4, 2020

@demianrenzulli cc @addyosmani

I have investigated a lot for getting device information from some reliable source with @addyosmani .
As far as I know, DeviceAtlas is the most reliable source for it.
We also have the demo project for it. https://github.com/GoogleChromeLabs/adaptive-loading/tree/master/cra-device-class-aware-code-splitting

@demianrenzulli
Copy link
Author

Thanks for the info @anton-karlovskiy!

Taking a look at the page, it seems like DeviceAtlas is User-agent based too, is that correct? I guess that, if the UA string is deprecated, they'll change their current approach as well.

Also, it seems like this solution is paid, which might create some additional barriers for developers.

In any case, it seems like you guys have already explored the available alternatives, so I assume there's nothing else at this point.

@passani
Copy link

passani commented Feb 21, 2020

If we are talking about Device Detection, historically and practically, WURFL (by ScientiaMobile) is the most well known and reliable way to get device info. It's been around for 20 years (I know I created it)

For the purpose of integrating with React or other client side, may I suggest that anyone interested takes a look at WURFL.js lite?

While WURFL.js BE is a commercial product, "lite" edition comes free of charge, so you can play around with it freely.

Just add this script reference and you will end up with Device Info as a JSON object:

<script type="text/javascript" src="//wurfl.io/wurfl.js"></script>

(the JSON is dynamically generated server-side. There's no point in copying and pasting the JSON object you obtain from a single request. WURFL needs to look at your HTTP headers before the JSON object is generated).

@ronancremin
Copy link

Thanks for the info @anton-karlovskiy!

Taking a look at the page, it seems like DeviceAtlas is User-agent based too, is that correct? I guess that, if the UA string is deprecated, they'll change their current approach as well.

Also, it seems like this solution is paid, which might create some additional barriers for developers.

In any case, it seems like you guys have already explored the available alternatives, so I assume there's nothing else at this point.

Yes, DeviceAtlas used to primarily rely on the User-Agent header but we have added support for User-Agent Client Hints (and combinations of UA-CH headers and UAs also). It's worth noting that UA-CHs complicate many aspects of server-side adaptation due to the fact that they are not available on the first request and there are limits on their availability to third-party origins and iframes. We have written about these issues in a set of pages on our website.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants