Keeping browser versions up to date

[elrichar]

What is your stance on keeping up with the latest versions of browsers?

For example: Firefox 15 was released in August, and Firefox 16 was released in October, but the weekly snapshot has not been updated to specify either of those new versions.

We're using the Java API (1.4.1), and while the browser is correctly detected as Firefox it does not have a version associated with it with those latest versions of the browser.

• Is your goal to keep the definitions file up to date with the latest browser versions and they just haven't been?
• Could you enhance the APIs to find the browser version in the user agent string without having to update the definitions file with every release of a new browser version?
• Is this something that you have decided you are not going to attempt to keep current?
• Other thoughts?

Any information on the topic would help me with figuring out how to use this moving forward.

Thanks.

[kamermans]

Hi,

While our primary focus is on the accurate detection of mobile devices, we do maintain desktop browsers in the WURFL data as well. As you can see from the latest WURFL snapshot, there are plenty of Firefox entries:

Code: Select all

# grep '"firefox_' wurfl.xml
  <device id="firefox_1" user_agent="Firefox/1.0" fall_back="firefox">
  <device id="firefox_2" user_agent="Firefox/2.0" fall_back="firefox">
  <device id="firefox_3" user_agent="Firefox/3.0" fall_back="firefox">
  <device id="firefox_3_5" user_agent="Firefox/3.5" fall_back="firefox">
  <device id="firefox_4_0" user_agent="Firefox/4.0" fall_back="firefox">
  <device id="firefox_5_0" user_agent="Firefox/5.0" fall_back="firefox">
  <device id="firefox_6_0" user_agent="Firefox/6.0" fall_back="firefox">
  <device id="firefox_7_0" user_agent="Firefox/7.0" fall_back="firefox">
  <device id="firefox_10_0" user_agent="Firefox/10.0" fall_back="firefox">
  <device id="firefox_11_0" user_agent="Firefox/11.0" fall_back="firefox">
  <device id="firefox_12_0" user_agent="Firefox/12.0" fall_back="firefox">
  <device id="firefox_8_0" user_agent="Firefox/8.0" fall_back="firefox">
  <device id="firefox_9_0" user_agent="Firefox/9.0" fall_back="firefox">
  <device id="firefox_13_0" user_agent="Firefox/13.0" fall_back="firefox">
  <device id="firefox_14_0" user_agent="Firefox/14.0" fall_back="firefox">
  <device id="firefox_15_0" user_agent="Firefox/15.0" fall_back="firefox">
  <device id="firefox_16_0" user_agent="Firefox/16.0" fall_back="firefox">
  <device id="firefox_17_0" user_agent="Firefox/17.0" fall_back="firefox">

It sounds like your API needs to be updated. We released version 1.4.3 of the API a few days ago, and it has improved support for desktop browser detection as well.

Allowing the API to parse the version string out of the user agent directly without cross-checking our data would be dangerous since there is virtually no way for us to verify the version number. For example, Opera decided that updating the version string in the UA from 9 to 10 was too painful since sites were detecting v10 as v1, and they left the version as "9.80", then appended another version string with the real version number. This would require a significant change to the API to detect. Keeping things like this in WURFL means that we can release updates to the data without necessarily changing the API.

If your application relies on the version of desktop browsers, you should determine this programmatically in your application, as we do not go out of our way to detect the versions of desktop browsers.

[elrichar]

Thanks for the quick response.

This all makes sense and I'll update our definitions.

It must have been a mistake on my part when searching the latest definition file that I didn't see the newer Firefox versions in there. I'll post back if they are indeed missing in my download, but I bet I overlooked them.

Thanks again.

[rjanicki]

Hello,

IMO this problems are not solved yet. My FF UA is Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 and it is recognized as generic web browser. The same is for my Chrome UA (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.60 Safari/537.11). I've tested it on 1.4.3.1 API DB from 2012-11-04 and checked WURFL DB from 2012-11-08 but it had the same UA strings for those browsers.
I've also checked this UAs on your tools.scientamobile.com and it shown generic web browser as well.

[kamermans]

By default, our APIs run in "High Performance Mode" which makes no attempts to specifically recognize desktop web browsers for the sake of performance. If you want the particular brand and version, like Firefox 20, you will need to set your API to "High Accuracy Mode". In Java, for example, here is the documentation bit about changing modes (from http://wurfl.sourceforge.net/njava_index.php):

To configure WURFL API to run in High-Performance or High-Accuracy mode, you can edit the XML /META-INF/wurfl-config.xml configuration file (the Java API refers to this at engine-target).

for High-Accuracy mode:

Code: Select all

<wurfl-api-config engine-target="accuracy">

for High-Performance mode:

Code: Select all

<wurfl-api-config engine-target="performance">

High-Performance is the default target.

As well you can change the HP/HA configuration mode by program call trough the method setEngineTarget(EngineTarget target) of the GeneralWURFLEngine object.

[rjanicki]

Now that is clear

However, I have problems with setting the enging-target. I'm using spring and want to set it by spring (also I don't where wurfl-config.xml comes from - I don't have it in my project). I try to do it in that way:

Code: Select all

<bean id="WurflHolder" class="net.sourceforge.wurfl.core.GeneralWURFLEngine">
		<constructor-arg index="0" value="classpath:/wurfl.zip" />

		<property name="engineTarget" value="performance" />
	</bean>

As it works w/o setting propery engineTarget, I can't manage to run it with this config. I get the NPE:

PropertyAccessException 1: org.springframework.beans.MethodInvocationException: Property 'engineTarget' threw exception; nested exception is java.lang.NullPointerException

I'm using spring 3.1.

[fulvio.crivellaro]

Hello Rafal,
the wurfl-config.xml file is placed in the META-INF folder, inside the jar file of the library.
Otherwise, you can set it programmatically; assuming you get the GeneralWURFLEngine instance from Spring called engine, you should call:

Code: Select all

engine.getWURFLManager().setEngineTarget(EngineTarget.accuracy);

[rjanicki]

Yes, but I can't overwrite it otherwise than setting my custom (only for Wurfl configuration and init beans) package to be web and having a WEB-INF dir then, is that right?

I also cannot set it programmatically unless its initialized what doesn't conform with standards in Spring library as WurflManager is null before init(); As I understand, the WurflManager is initialized after start of the app to load the wurfl.xml which is correct. However, I don't see the reason to not to set engine target before - in spring, using <property> and then, WurflManager would be initialized and set the engine target.
If I do it your way, it'll surely work, but it makes me to set it in every project where I want to use Wurfl instead of letting me decide if I want it either as a configuration part (in spring xml files) or set in project.
As I can see now, there can be also another discussion why not init it at the constructor. It might be only my case, but I'd like context to start those 2 seconds (time of init on my test machine) longer than having my user to wait those 2 seconds longer when first request to Wurfl is made.

I know it sounds like I'm old and grumpy and I'm sorry

[fulvio.crivellaro]

Ok, I think I have understood what you aim to do, and I think I figured out why Spring complains about your configuration for what concerns the GeneralWURFLEngine.

I will try to implement a solution, and hopefully to provide it to you soon.

Regards,
Fulvio

[rjanicki]

Thanks!
Can't wait for the new version.

Best,
Rafal

[kamermans]

Hi Rafal,

We will be including an update that will allow the configuration as you've requested in version 1.4.4 of the API, which is in the final stages of development and will be released shortly.