Is this field supported 'lightly' on purpose? Running quite a few test phones through the 1.4 Java API I don't get a value back for this field even on some common devices:
iPhone 3gs (apple_iphone_ver4_2_1)
HTC Incredible 2 (htc_desirehd_ver1)
HTC Inspire 4g (htc_adr6350_ver1_suban23_verizon)
I can get the user agent strings if needed (I didn't keep track of them while testing)
I do get a mobile_browser_version back on an iPhone 4, and on the BB I tested, but I'd like to know if I should rely on this attribute at all or if I need to get at the Version of the mobile browser a different way.
Thanks for any insight.
mobile_browser_version support
-
- Posts: 294
- Joined: Mon Jun 20, 2011 5:04 pm
Re: mobile_browser_version support
Hi there,
for webkit-based mobile browsers we have never explicitly assigned a browser version because there has never been a clear standard of what such a versioning number should be for all the different flavors of mobile webkit/safari out there.
Historical reasons, if you will
Those browsers can be different in subtle way also when the build number is the same. Nokia, Google and Apple have moved each in its own direction wrt this browser.
For practical purposes, developers have referred to the OS and OS Version for decisions about CSS, Javascript and "HTML5-related" capabilities.
This is going to change going ahead as we introduce new HTML5-related capabilities and bring more order to the way browsers are categorized.
one final note: you may want to read this good article about webkit in mobile: http://www.quirksmode.org/blog/archives ... o_web.html
Of course, if you and your team have suggestions about what such a version number should be, we would be happy to hear about them...
Thanks
for webkit-based mobile browsers we have never explicitly assigned a browser version because there has never been a clear standard of what such a versioning number should be for all the different flavors of mobile webkit/safari out there.
Historical reasons, if you will
Those browsers can be different in subtle way also when the build number is the same. Nokia, Google and Apple have moved each in its own direction wrt this browser.
For practical purposes, developers have referred to the OS and OS Version for decisions about CSS, Javascript and "HTML5-related" capabilities.
This is going to change going ahead as we introduce new HTML5-related capabilities and bring more order to the way browsers are categorized.
one final note: you may want to read this good article about webkit in mobile: http://www.quirksmode.org/blog/archives ... o_web.html
Of course, if you and your team have suggestions about what such a version number should be, we would be happy to hear about them...
Thanks
Re: mobile_browser_version support
Here are some more detailed examples:
Using an iPhone 3gs with iOS 4.3.3:
Actual user agent:
Actual user agent:
There are other attributes, such as the Safari build number (e.g. 6533.18.5) and AppleWebKit version (e.g. 533.17.9), but in order to be consistent mobile_browser_version would simply be the basic browser version (e.g. 5.0.2 or 4.0 in these cases).
This would be more consistent with the mobile_browser_version usage from our testing of some BB devices/WindowsPhone where we get back values such as '6' for BB (via Mozilla/5.0 (BlackBerry; U; BlackBerry 9780; en-GB) AppleWebKit/534.8+ (KHTML, like Gecko) Version/6.0.0.706 Mobile Safari/534.8+) and '9' for WindowsPhone. Also, iPhone 5s gives us 5.1 for the mobile_browser_version, not null.
Thoughts?
Using an iPhone 3gs with iOS 4.3.3:
Actual user agent:
- Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_3 like Mac OS X; en_us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/BJ2 Safari/6533.18.5
- Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_3 like Mac OS X; en_us) AppleWebKit/525.18.1 (KHTML, like Gecko)
- null
Actual user agent:
- Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; MB520 Build/Blur_Version.37.4.0.MB520.ATT.en.US Flex/P015) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
- Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; MB520 Build/Blur_Version.37.4.0.MB520.ATT.en.US Flex/P015) AppleWebKit/533.1+ (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
- null
There are other attributes, such as the Safari build number (e.g. 6533.18.5) and AppleWebKit version (e.g. 533.17.9), but in order to be consistent mobile_browser_version would simply be the basic browser version (e.g. 5.0.2 or 4.0 in these cases).
This would be more consistent with the mobile_browser_version usage from our testing of some BB devices/WindowsPhone where we get back values such as '6' for BB (via Mozilla/5.0 (BlackBerry; U; BlackBerry 9780; en-GB) AppleWebKit/534.8+ (KHTML, like Gecko) Version/6.0.0.706 Mobile Safari/534.8+) and '9' for WindowsPhone. Also, iPhone 5s gives us 5.1 for the mobile_browser_version, not null.
Thoughts?
-
- Posts: 294
- Joined: Mon Jun 20, 2011 5:04 pm
Re: mobile_browser_version support
We need to think about this. We agree that leaving that value empty is not very elegant, but we don't want to change anything that may break how people are using WURFL today.
Anyway, stay tuned.
Thanks
Anyway, stay tuned.
Thanks
Re: mobile_browser_version support
Any new updates on this topic or a time frame when there may be?
-
- Posts: 294
- Joined: Mon Jun 20, 2011 5:04 pm
Re: mobile_browser_version support
Hi there. We are thinking of leveraging the UA string to back populate the WURFL with the webkit version.
This is not as straightforward as one might assume because there are a lot of different permutations of webkit browsers and we certainly don't want to get a bloated WURFL just to keep track of revisions that are essentially insignificant.
if you can allocate a tiny bit of programming resources (any programmer in fact, Java, PHP, .NET or whatever), chances are that you can easily roll your own patch file that populates that capability in ways that fix the problem for you.
If you are a commercial licensee and this totally kills it for you, please contact us offline at wurfldb @ scientiamobiile [...] and we will try to assist from here.
Thanks
This is not as straightforward as one might assume because there are a lot of different permutations of webkit browsers and we certainly don't want to get a bloated WURFL just to keep track of revisions that are essentially insignificant.
if you can allocate a tiny bit of programming resources (any programmer in fact, Java, PHP, .NET or whatever), chances are that you can easily roll your own patch file that populates that capability in ways that fix the problem for you.
If you are a commercial licensee and this totally kills it for you, please contact us offline at wurfldb @ scientiamobiile [...] and we will try to assist from here.
Thanks
Re: mobile_browser_version support
Resurrecting this thread as it seems appropriate:
Question: Why are Safari 525 and 530 the only browser 'version' available for desktop Safari? Those versions of webkit are very old at this point and since an actual version is not also supplied by WURFL (e.g. 5.1.7), it seems there is no way currently to distinguish Safari versions. Let me know what you think and/or if there is some way to distinguish versions that I'm not seeing. Thanks.
Question: Why are Safari 525 and 530 the only browser 'version' available for desktop Safari? Those versions of webkit are very old at this point and since an actual version is not also supplied by WURFL (e.g. 5.1.7), it seems there is no way currently to distinguish Safari versions. Let me know what you think and/or if there is some way to distinguish versions that I'm not seeing. Thanks.
-
- Posts: 294
- Joined: Mon Jun 20, 2011 5:04 pm
Re: mobile_browser_version support
Hi Elliott, we really want to avoid having to add 20 entries for the same device in WURFL simply to map the Safari version.
Question for you, would an utility function (virtual capability) that parses the UA string be enough for your needs?
As an aside, we are working on a better solution for the next *major* release of the API
Thanks
Question for you, would an utility function (virtual capability) that parses the UA string be enough for your needs?
As an aside, we are working on a better solution for the next *major* release of the API
Thanks
Re: mobile_browser_version support
Yes, a virtual capability seems to be a good fit for this type of scenario. I'd just recommend that if that is the way it goes then support should be consistent for Chrome/IE/Firefox/etc. with that new virtual capability so that we can switch over to using that capability across the board (and don't need to have additional logic in our code to use the new field for Safari but some existing field for Chrome, etc.). That type of pattern seems to be the way we get burned the most frequently (e.g. right now some Windows phones define the device_os as 'Windows Mobile OS' while others set it to 'Windows Phone OS'. This is causing an issue for us as we speak).
-
- Posts: 294
- Joined: Mon Jun 20, 2011 5:04 pm
Re: mobile_browser_version support
We are handling Windows Mobile and Windows Phone as separate OSes because they really are.
Even wikipedia reports them as separate entities and one is not the evolution of the other (no compatibility between applications for example, completely new UI)
http://en.wikipedia.org/wiki/Windows_Mobile
http://en.wikipedia.org/wiki/Windows_Phone
We suspect that maintaining this distinction in your reports/analysis is the way to go for you too.
Actually, we got a doubt: are you looking at the 'model_name' capability to determine the OS for generic matches?
if that's the case, we recommend that you use device_os instead. Anyway, we can change the model_name for generic, if this causes confusion and rename it Windows Phone.
Thanks
Even wikipedia reports them as separate entities and one is not the evolution of the other (no compatibility between applications for example, completely new UI)
http://en.wikipedia.org/wiki/Windows_Mobile
http://en.wikipedia.org/wiki/Windows_Phone
We suspect that maintaining this distinction in your reports/analysis is the way to go for you too.
Actually, we got a doubt: are you looking at the 'model_name' capability to determine the OS for generic matches?
if that's the case, we recommend that you use device_os instead. Anyway, we can change the model_name for generic, if this causes confusion and rename it Windows Phone.
Thanks
Re: mobile_browser_version support
We are indeed using 'device_os' to make this distinction, but are using it as a more global 'iOS/Android/BlackBerry/WindowsPhone' reporting feature. In this case, we probably don't want to distinguish between the different OS since we're really recording the type of device.
Regardless, thanks for the additional info on that topic - we'll be able to resolve the issue how it best makes sense on our side.
Regardless, thanks for the additional info on that topic - we'll be able to resolve the issue how it best makes sense on our side.
Who is online
Users browsing this forum: No registered users and 5 guests