# DeviceAtlas Cloud Client API #
DeviceAtlas Cloud is a web service that can return device information such
as screen width, screen height, is mobile, vendor, model etc. To see a full
list of properties, please visit
https://deviceatlas.com/resources/available-properties .
This Client API provides an easy way to query DeviceAtlas Cloud. It provides the
ability to cache returned data locally to greatly improve performance and has
automatic failover should one of the global DeviceAtlas Cloud endpoints become
unavailable. As of version 1.2, the Client API is able to leverage data
collected by the DeviceAtlas Client Side Component. This data is sent to
DeviceAtlas Cloud to augment the data found from the normal HTTP headers and
also allows the detection of the various iPhone and iPad models.
### Compatibility ###
The DeviceAtlas Cloud Ruby gem is compatible with Ruby 1.8.7, 1.9.3 and 2.0
releases. It can be used inside any stand-alone script or Rails project.
### Dependencies ###
The Ruby Cloud API depends on the following libraries and gems:
- socket
- tmpdir
- cgi
- json
- digest
### Configuration ###
The DeviceAtlas Cloud Client is configured by setting the "settings" property of
the client instance (e.g. client.settings).
The only required property is your DeviceAtlas licence key:
client.settings.licence_key
Note: as of version 1.4 the API throws exceptions on errors and failures unless
the class attribute "debug_mode" in Settings is set to false. It is recommended
to keep "debug_mode" set to true during implementation time.
### Basic Usage ###
The DeviceAtlas Cloud Client API can be used as follows:
#### Installation ####
```bash
gem install Api/deviceatlas_cloud_client-1.4.1.gem
# Add the installed "deviceatlas_cloud_client" gem to the Gemfile of your
# Rails project if needed.
```
#### Detection In A Web Controller ####
Please note that this web controller example requires the [Sinatra DSL](http://sinatrarb.com/).
However the DeviceAtlas Cloud client is designed to work in any Ruby based web context
including in a Rails controller.
##### Example Setup #####
This step is only required for this example and is not a dependency of the API itself.
Sinatra can be installed as follows:
```bash
gem install sinatra
```
##### Obtain Device Data #####
```ruby
# Client API gem
require 'deviceatlas_cloud_client'
# Sinatra is only required for this example
require 'sinatra'
# Include the Controller helper
include DeviceAtlasCloudClient::ControllerHelper
get '/' do
# Create a DeviceAtlas client instance
deviceatlas_client = get_deviceatlas_cloud_client_instance
deviceatlas_client.settings.licence_key = 'YOUR-DA-LICENCE-KEY'
# Get the device properties
device_data = deviceatlas_client.get_device_data
# Print the device data
content_type :txt
device_data.to_s
end
```
#### Detection In A Standalone Script ####
Device data can be obtained via two methods in a standalone script. The
first method is by passing a set of HTTP headers and the second method is
by passing a User-Agent string.
##### Obtain And Instance Of The DeviceAtlas Cloud Client #####
```ruby
# Client API gem
require 'deviceatlas_cloud_client'
# Create a DeviceAtlas client instance
deviceatlas_client = DeviceAtlasCloudClient.get_instance
deviceatlas_client.settings.licence_key = 'YOUR-DA-LICENCE-KEY'
```
##### Obtain Device Data Via A Set Of Headers #####
```ruby
headers = {
'accept-language' => 'en',
'user-agent' => 'Mozilla/5.0 (Linux; Android 7.0; Pixel C Build/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36',
}
device_data = deviceatlas_client.get_device_data(headers)
# Print the device data
print device_data
```
##### Obtain Device Data Via A User-Agent String #####
```ruby
user_agent = 'Mozilla/5.0 (Linux; Android 7.0; Pixel C Build/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Safari/537.36'
device_data = deviceatlas_client.get_device_data(user_agent)
# Print the device data
print device_data
```
#### Using The Device Data ####
Now that we have shown how to obtain device data we can now use it.
```ruby
# Obtain the properties
if device_data.has_key?DeviceAtlasCloudClient::KEY_PROPERTIES
properties = device_data[DeviceAtlasCloudClient::KEY_PROPERTIES]
end
# Use the device properties
vendor = properties.has_key?(:vendor) ? properties[:vendor] : nil
year_released = properties.has_key?(:yearReleased) ? properties[:yearReleased] : nil
# Print the properties
print ({
'vendor' => vendor,
'year_released' => year_released
})
```
See the list of all property names here:
https://deviceatlas.com/resources/available-properties
The availability of a property depends on the device and your licence,
before accessing a property always check if it exists in the set or not.
### Examples ###
Various examples are included in this package to clearly demonstrate the API
features, usage and some use cases. These examples are very simple and are
heavily commented.
#### Basic Usage ####
Includes two examples. One simple command line examples which use API to detect
and get properties from header sets. The other example is a web application.
The web application example uses the API with the request object
to automatically detect and get the properties for the request. Using custom API
configs and the client-side-component is shown in this example.
##### Command Line Example #####
```
# Update the `@licence_key` variable in `detect.rb` with your licence key
cd Examples/BasicUsage/cli
ruby detect.rb
```
##### Web Application Example #####
```
# Update the `@licence_key` variable in `run_example.rb` with your licence key
gem install sinatra
cd Examples/BasicUsage/web
ruby run_example.rb
```
Once the above commands have been run the example may be accessed by visiting
http://localhost:3000/cloud_basic_usage_examples from a web browser.
#### Redirection ####
This web example uses the API to get properties for the current request and then
uses some basic property values to decide which website provides the most
suitable content for the device making the request.
```
# Update the `@licence_key` variable in `run_example.rb` with your licence key
gem install sinatra
cd Examples/Redirection
ruby run_example.rb
```
Once the above commands have been run the example may be accessed by visiting
http://localhost:3000/cloud_redirection_example from a web browser.
#### Content Adaptation ####
This web example uses the API to get properties for the device making the current
request and then uses some basic property values to choose a suitable template to
wrap around the content.
```
# Update the `@licence_key` variable in `run_example.rb` with your licence key
gem install sinatra
cd Examples/ContentAdaptation
ruby run_example.rb
```
Once the above commands have been run the example may be accessed by visiting
http://localhost:3000/cloud_content_adaptation_example from a web browser.
#### Analytics ####
This web example uses the API to get properties for user-agents from a given list.
Some properties such as vendor, browser name and device type are aggregated and
the results are displayed as graphs and numbers.
```
# Update the `@licence_key` variable in `run_example.rb` with your licence key
gem install sinatra
cd Examples/Analytics
ruby run_example.rb
```
Once the above commands have been run the example may be accessed by visiting
http://localhost:3000/cloud_analytics_example from a web browser.
#### Content Targeting ####
This example uses the API to detect the device and use some of its properties to
show certain advertisements and download links which may be related or of interest
to the user, considering their device.
```
# Update the `@licence_key` variable in `run_example.rb` with your licence key
gem install sinatra
cd Examples/ContentTargeting
ruby run_example.rb
```
Once the above commands have been run the example may be accessed by visiting
http://localhost:3000/cloud_content_targeting_example from a web browser.
Note that in the web examples which use the API, the client side properties are
taken into account automatically by the API if the cookie exists on the browser.
This means if the cookie already exists within your browser you will still see
the client side properties in the result even when the DeviceAtlas client side
component is not added to the page. You can delete the cookie manually to see the
differences between the results from examples which use the client side component
and those that don't.
### Caching ###
The API can cache the returned data after a call to the DeviceAtlas Cloud service,
this will speed up subsequent requests.
The API has a file caching mechanism. It is recommended to always use the file
cache if possible.
The file cache stores the returned properties on your server disk. The cache
location is typically the system temp directory but this can be overridden with
the "client.settings.custom_cache_dir" constant. Items in the cache expire after
a set time period to ensure the data is up-to-date. This cache is enabled by
default. It is recommended to always have file caching enabled even when you are
using cookie cache.
Items in the cache expire after a set time period to ensure the data is up-to-date.
### Client Side Component ###
In addition to the properties from the data file, properties can be gathered
from the client's browser and used both on the client side and on the server
side. Please see the [ClientSide readme file](README.ClientSide.html) for more
information.
#### Usage with Client Side Component ####
In addition to normal usage, DeviceAtlas has the capability to capture client
side properties and merge them into the server side properties.
The "deviceatlas.min.js" file must be included on your webpage in order for it
to detect the client side properties. The contents of this cookie are
automatically detected with the request headers. Both sets of properties are
used in additional logic to determine other properties such iPhone and iPad
models which are normally not detectable.
By default, if the cookie exists it will be used by the API. To disable using
the client side cookie:
```ruby
client.settings.use_client_cookie = false
```
### DeviceAtlas Cloud Service End-points ###
The DeviceAtlas Cloud Service is powered by independent clusters of servers
spread around the world. This ensures optimum speed and reliability. The API is
able to automatically switch to a different end-point if the current end-point
becomes unavailable. It can also (optionally) auto-rank all of the service
end-points to choose the end-point with the lowest latency for your location.
The Cloud service provider servers are defined in the "client.settings.servers"
variable when a client instance is created.
```ruby
client.settings.servers = [
{:host => 'server1-url', :port => server1-port},
{:host => 'server2-url', :port => server2-port},
{:host => 'server3-url', :port => server3-port}
]
```
By default the API will analyze the end-points from time to time to rank them by
their stability and response speed. The ranked list is then cached and used
whenever the Client API needs to query the DeviceAtlas Cloud Service. If an end-
point fails, the Client API will automatically switch to the next end-point on
the list.
There is no need to set the servers array if auto-ranking is turned on. If you
wish, you may re-order the array and turn auto-ranking off. In this case the API
will respect your preferred order of end-points and only switch to a different
end-point should the primary one fail to resolve.
#### Notes ####
* With the default auto-ranking settings, the ranking is done every 24 hours.
The actual time may be more than 24 hours as the ranking is only triggered by
a request to the Client API and the cached server list is older than value
set to client.settings.auto_server_ranking_lifetime.
* During end-point analysis a number of requests are made to each end-
point. Please note that these requests count towards your total hits to
the Cloud service.
e.g:
```ruby
if
client.settings.server contains 3 servers
client.settings.auto_server_ranking_lifetime = 1440
client.settings.auto_server_ranking_num_requests = 3
then
auto ranking will add 9 (3x3) hits per day
```
#### Methods ####
* Get the ranked server list:
```ruby
ranked_server_list = client.servers
```
The first end-point in the list will be used to make a request to the cloud, if
it fails the next end-point will be take it's place.
* Get the end-point used for the last request:
```ruby
server = client.get_cloud_url
```
Note that if data comes from cache this method will return "nil".
* Get end-point info. This is useful when you want to manually rank the server list:
```ruby
server = client.get_servers_latencies
```
Please see https://deviceatlas.com/resources/cloud-service-end-points for more
information.
#### Cloud Server end-point settings ####
You can set multiple server end-point settings from the "client.settings"
property of your client instance.
##### auto_server_ranking = true #####
To turn auto ranking on/off. To manually rank the servers set to "false"
and edit the SERVERS list to set your preferred order of end-points.
The API will not rank the servers and will use the SERVERS list items
directly with the topmost server used first to get device data. On fail-
over the next end-point in the list will be used.
##### cloud_service_timeout = 2 #####
Time in seconds. If an end-point fails to respond in this amount of time
the API will fail-over to the next end-point on the list.
##### auto_server_ranking_max_failures = 1 #####
When auto ranking servers, if a server fails more than this number of
times it will not be included in the list.
##### auto_server_ranking_num_requests = 3 #####
When auto ranking servers, number of requests to perform for service
speed calculation.
##### auto_server_ranking_lifetime = 1440 #####
Time in minutes. How often to auto rank servers.
0 = servers will be ranked and cached only once and this list will not
be updated automatically. You can update this list manually:
client.rank_servers
Note: auto_server_ranking must be set to true so this cached server list
will be used by the API even if auto_server_ranking_lifetime is set to 0
Note: If auto_server_ranking = false then the cached server list will be
totally ignored.
##### server_phaseout_lifetime = 1440 #####
Used when auto ranking is OFF. Specifies how long to use the fail-over
endpoints before the preferred end-point is re-checked. If the preferred
end-point is available it will be added back into the list of end-points
and used for future requests.
### Extra Tools ###
This package comes with extra tools that can help you enhance your mobile websites.
#### DeviceAtlas Client Side Component ####
This is the DeviceAtlas Client Side component which discovers device info on
client side to augment the server data.
This library is used in the DeviceAtlas Cloud Client API examples.
#### Latency Checker ####
There are two command line tools included in this package to help you tweak the
DeviceAtlas Cloud API end-point selecting.
##### Check Server Latency #####
This tool can be used to get info about the DeviceAtlas Cloud Service end-points.
The info shown can be used for manually setting up the DeviceAtlas Clous service
end-points in the API. To access the cloud servers a valid DeviceAtlas licence
would be required.
Usage (command line):
```ruby
ruby /path/to/ExtraTools/LatencyChecker/check_server_latency.rb
```
##### Update Server Ranking Cache #####
When client.settings.auto_ranking is set ON you can use this tool to re rank the DeviceAtlas Cloud
end-points. All you need to do is to run this script in regular intervals which
are smaller than the client.settings.auto_server_ranking_lifetime.
Usage (command line):
```ruby
ruby /path/to/ExtraTools/LatencyChecker/update_server_ranking_cache.rb
```
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
_ Copyright (c) DeviceAtlas Limited 2021. All Rights Reserved. _