Page 1 of 1

device_os_version value type

Posted: Tue Jan 26, 2016 5:16 pm
by romaxion
Hi,

According to the spec (http://scientiamobile.com/wurflCapability) device_os_version value is string.
I use java client and get double when the value is set and string ("") when it is not.

Log snippets:
double example:

Code: Select all

[INFO] 01:03:57.482 [388357135@qtp-404214852-0] INFO  c.s.wurflcloud.CloudClient - message: {"apiVersion":"WurflCloud 1.5.0.2","mtime":1452529268,"id":"google_nexus7_ver1_suban51","capabilities":{"brand_name":"Google","model_name":"Nexus 7","device_os":"Android","device_os_version":5.1,"mobile_browser":"Chrome Mobile"},"errors":{}}
String example:

Code: Select all

[INFO] 02:15:55.140 [388357135@qtp-404214852-0] INFO  c.s.wurflcloud.CloudClient - message: {"apiVersion":"WurflCloud 1.5.0.2","mtime":1452529268,"id":"generic_web_browser","capabilities":{"brand_name":"generic web browser","model_name":"","device_os":"","device_os_version":"","mobile_browser":""},"errors":{}}
This is rather a bug of the cloud service.

Simple bash cloud client proves that device_os_version data type is wrong before any client processing.

Simple bash client:

Code: Select all

#!/bin/bash

API_KEY="<api key>"

if [[ "$#" -lt 2 ]]; then
  echo "usage: wcurl <capability> <user agent string>"
  exit 1
fi

curl -u "$API_KEY" -A "$2" "http://api.wurflcloud.com/v1/json/search:($1)"

echo

Code: Select all

$ ./wcurl device_os_version "Mozilla/5.0 (iPhone; CPU iPhone OS 9_2_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13D15 Safari/601.1"
gives

Code: Select all

{"apiVersion":"WurflCloud 1.5.0.2","mtime":1452529571,"id":"apple_iphone_ver9_2","capabilities":{"device_os_version":9.2},"errors":{}}
while

Code: Select all

$ ./wcurl device_os_version "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36"
returns

Code: Select all

{"apiVersion":"WurflCloud 1.5.0.2","mtime":1452529571,"id":"generic_web_browser","capabilities":{"device_os_version":""},"errors":{}}
Thanks.

Edits:
- Updated the log snippets.
- Add bash client results.

Re: device_os_version value type

Posted: Wed Jan 27, 2016 12:33 pm
by aaronp
Hi Roman,

The value for `device_os_version` may return a value as a string or numeric value, but should be treated as a string.

For reference to all possible return values for the capability: http://scientiamobile.com/download/capabilities.json.

Let me know if you have any other questions or concerns.

Thanks,
Aaron

Re: device_os_version value type

Posted: Wed Jan 27, 2016 1:00 pm
by romaxion
Hi Aaron,

According to the both sources
(http://scientiamobile.com/wurflCapability and http://scientiamobile.com/download/capabilities.json) the type of the `device_os_version` must be string.

From http://scientiamobile.com/download/capabilities.json

Code: Select all

"name": "device_os_version",
            "description": "Which version of the hosting OS\r\n",
            "group": "product_info",
            "type": "string",
            "values": [
                "",
                "4.4",
                "4.2",
                "4.0",
...
From http://scientiamobile.com/wurflCapability
device_os_version / string / Which version of the hosting OS
There is nothing about
may return a value as a string or numeric value
Also there is no at least one example that would not be a string for that capability. Unlike the actual behavior.

That means that numeric values must be first converted to a string and then returned.
But the cloud service does not do that.

Re: device_os_version value type

Posted: Wed Jan 27, 2016 2:09 pm
by aaronp
Roman,

I have spoken to my engineering team and we aware of this behavior. We are looking for a solution, however due to the breaking nature of this change, I cannot guarantee any timeline. For now, I would recommend casting the value to a string.

Thanks,
Aaron

Re: device_os_version value type

Posted: Wed Jan 27, 2016 2:31 pm
by romaxion
Thanks, Aaron.

I am already casting it, of course.
I wanted to make sure we would not find there another value type tomorrow (since it does not conform to the spec today).

Thanks,
Roman