No, we syndicate a compact serialisation of our data to be placed on the web server, and also provide APIs that offer speedy, optimised access to the data. It's a lightweight JSON file.
The API software is not updated very frequently, we want to make sure that the load on developers is as low as possible. The JSON file (the device profiles, in fact) are updated constantly. Depending on the licence you purchased, you may be entitled to daily, weekly or monthly updates. Developer licences are entitled to daily updates, so you will always get the best!
We strongly suggest that you make sure that every time you want to update the JSON file, the download was completed successfully and that the file is valid and complete. If the download was broken, your application will not work properly. See the manual on Automatic download of JSON updates and how to verify file integrity.
We provide a range of APIs for use in your own applications, and these are available on our downloads page.
During our testing we have done some benchmarks. We are now publishing the resulting performance.
We like to think of DeviceAtlas as the place to share information, knowledge and experience about devices and the mobile in general. Our preferred method to collect device data is via our test site, TA-DA. We have also turned our website in a real read/write website so if you are registered you may add information about devices simply using your web browser. If you have a large amount of data already stored in some database or file such as XML, get in touch with us, because we have some import API's available. As a last resort, if you really cannot share the information because, for example, you do not own it, let us know, because we are working on a solution for this too.
The association between an HTTP request and a device is not one to one, but many to one, so yes, we are able to detect devices that use different user-agent strings and HTTP request headers.
This is the OpenWeb proxy, not a real device. You should contact the network operator and ask them to whitelist your sites.
You might find useful these two articles we published on mobiForge.com:
Content Transformation Addendum to Web Browsing Style Guide
Setting HTTP headers to advise transcoding proxies...
Please note that the practices suggested here are for XHTML only. If you serve any WML/WAP 1 pages you should not use the Cache-Control headers suggested in those articles. If you do not get whitelisted, you will receive this user-agent string and a generic HTTP request FROM ANY mobile device and will not be able to detect it.
Fatal error: Uncaught exception 'Mobi_Mtld_Da_Exception_InvalidPropertyException' with message 'The property "mobileDevice" is invalid for the User Agent:"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1"' in /path/DA/Api.php:357 Stack trace:
#0 /path/DA/Api.php(230): Mobi_Mtld_DA_Api::_getProperty(Array, 'Mozilla/5.0 (Ma...', 'mobileDevice', true)
#1 /path/index.php(49): Mobi_Mtld_DA_Api::getPropertyAsBoolean(Array, 'Mozilla/5.0 (Ma...', 'mobileDevice')
All our API's generate exceptions, your code should handle them. Refer to the specific documentation included with our API's to have a full list of the exceptions that might be generated
Our tutorials are collected in our community site, mobiForge, but you can see a list from here, DeviceAtlas tutorials.
 |  |  |  |
 |  |  |  |
 |  |
 |  |