Caution: The documentation you are viewing is
for an older version of Zend Framework.
You can find the documentation of the current version at:
The UserAgent Device Interface - Zend_Http
Once the User-Agent has been parsed and capabilities retrieved from the Features adapter, you will be returned an object that represents the discovered brower device. This interface describes the various capabilities you may now introspect.
Additionally, the various device classes define algorithms for matching the devices they describe. By implementing this interface, you may provide additional logic around these capabilities.
The Zend_Http_UserAgent_Device interface defines the following methods.
The static function match() should be used to determine whether the provided User-Agent and environment (represented by the $server variable) match this device. If they do, the Zend_Http_UserAgent class will then create an instance of the class, passing it the User-Agent, $server array, and any configuration available; at this time, it is expected that the Device class will consult with a features adapter, if present, and populate itself with discovered capabilities.
In practice, you will likely extend Zend_Http_UserAgent_AbstractDevice, which provides functionality around discovering capabilities from the User-Agent string itself, as well as discovering and querying a Features adapter.
Configuration options are defined on a per-device basis. The following options are defined in Zend_Http_UserAgent_AbstractDevice. Like all options, the "." character represents an additional level of depth to the configuration array.
The name of a Features adapter class that has either been previously loaded or which is discoverable via autoloading, or used in conjunction with the features.path option. This class must implement the Zend_Http_UserAgent_Features_Adapter interface.
If provided, the filesystem path to the features adapter class being used. The path must either be an absolute path or discoverable via the include_path.
Expects a User-Agent string, an array representing the HTTP environment, and an array of configuration values. The values are all optional, as they may be populated during deserialization.
This method is static.
Provided the $userAgent string and an array representing the HTTP headers provided in the request, determine if they match the capabilities of this device. This method should return a boolean.
Returns an array of key/value pairs representing the features supported by this device instance.
Similar to getAllFeatures(), this retrieves all features, but grouped by type.
Query the device to determine if it contains information on a specific feature.
Retrieve the value of a specific device feature, if present. Typically, this will return a boolean false or a null value if the feature is not defined.
Returns the browser string as discoverd from the User-Agent string.
Retrieve the browser version as discovered from the User-Agent string.
Get all features from a given feature group.
Retrieve a list of supported image types.
Alias for getImageFormatSupport().
Retrieve the maximum supported image height for the current device instance.
Retrieve the maximum supported image width for the current device instance.
Retrieve the physical screen height for the current device instance.
Retrieve the physical screen width for the current device instance.
Retrieve the preferred markup format for the current device instance.
Retrieve the User-Agent string for the current device instance.
Retrieve the supported X/HTML version for the current device instance.
Determine if the current device instance supports Flash.
Determine if the current device instance supports PDF.
Determine if the device has an associated phone number. Note: does not retrieve the phone number. This can be useful for determining if the device is a mobile phone versus another wireless capable device.
Determine if the current device instance supports HTTPS.
Example #1 Determining Supported Features
You may wish to direct the user to specific areas of your site based on features supported by the device they are using. For instance, if a particular app works only in Flash, you might direct a non-Flash-capable device to a page indicating the application will not work on their device; or for a device not capable of HTTPS, you may indicate certain actions, such as purchases, are not available.
Example #2 Dynamically Scaling Images
You may wish to alter the image sizes present in order to achieve a specific design within mobile devices. You may use a variety of methods in the device object to make this happen.
Note: Markup- based scaling is not ideal
Markup-based scaling such as in the example above is not the best approach, as it means that the full-sized image is still delivered to the device. A better approach is to pre-scale your images to a variety of sizes representing the devices you wish to support, and then using the device capabilities to determine which image to use.
Another approach is to use third-party services. Zend Framework provides one such capability via the TinySrc view helper.