Content Delivery
Most modern mobile devices will let users store files that are downloaded from WAP or Web sites.
Depending on the delivery method, the device might be notified in advance of the content format (OMA Dowload Separate Delivery) or might “discover” it when starting the download (Direct Download).
Different behaviours might happen across different mobile devices and most notable across different browsers. It is good practice to provide a link to a real file and not a script or servlet that will stream the content. This way you should be able to avoid any problems of file type recognition.
The guidelines described below presume that the browser is able to download the content you are providing. If not, the browser will generally display an error to the user such as “Content not supported”.
How to deliver contents safely
Some content providers will simply want to serve contents to their users and let the users use these contents freely, without any restrictions. In these cases, the best thing to do is to provide links to the real files on the server’s file-system. It is important to set the appropriate MIME type in the server’s configuration files.
If the content provider wants to protect the files delivered there are a few different strategies that can be implemented. First of all, files should be stored in a safe area of the file-system, possibly not accessible from the web server.
Links to the content files can be provided in two ways, the real files or a script that will stream the content to the remote user. There is also a third method, but many developers reported many problems, which is to provide a script or servlet and a set of parameters that will let the script identify the file in the file-system and stream it. For this reason we will not go too much into details about this system.
Whatever delivery system you choose, it is important that the last part of the URI is the name that you want to give to the content. In most cases mobile devices will not allow the user to specify an alternative and the extension is often stored as-is and compared to the MIME type set while storing the file. Specifying a URI that ends with .php and sending a GIF image will often generate an unrecoverable error.
Provide the real file
The safest way to provide files to remote users is to provide the real files. It is important that you set the appropriate MIME types, then simply copy the files from your external directory into a temporary directory accessible by the website. Provide an anchor to it (or the appropriate syntax in the XML file, etc) and deliver the file. Files should be removed after a few days or hours. It is up to you. This is simple to create and manage and only needs the time to develop an automatic cronjob that will remove temporary files when “expired”.
Develop a script
This is a system that will let you protect your files 100%, but might generate some problems if you don’t handle the files correctly. Still works very well in many cases, of course.
Develop a script that according to the minimum parameters is able to recognize the file to be delivered. A couple of examples:
http://mobile.example.com/download/check.php/image.gif
http://mobile.example.com/download/check.php/123456789abcdef/image.gif
The difference is that in the first case you are passing a parameter, image.gif, and the script check.php will identify the file and deliver it. In the second case you are also passing a session id, 123456789abcdef. This can be another step further to log and protect your contents. Store session information in a database and get file and user info from your database. Very useful when you want to generate statistics about how many time a user downloaded a content, which user-agent requested the contents and so on.
Another easy thing to do to protect your content is to store the user-agent string and block any other request with a different user-agent string.
When delivering a content file with a script you will have to manage the HTTP headers. It is required that you set the appropriate MIME type and it is also good practice to specify the file size.
Download methods
You can deliver contents in many ways. The most common is what is generally called a “direct download”. Alternatives are Openwave’s “Downloadfun” and OMA’s “DD”. Sprint‘s GCD should also be mentioned.
Direct Download
Most devices sold in the GSM market starting from 2003-2004 allow users to store remote files locally. Since mobile devices have limited memory and CPU, in most cases users will be allowed to store only files that are in a supported format. Supported formats vary depending on the device, from images to audio and video. PDA‘s and smartphones might allow users to store any file and manually install a third party application, but this is very specific.
If you want to deliver a file simply provide an anchor to the file and the device will let the user store it (if supported!).
Some devices, notably SonyEricsson, might do a request prior to the real download. In general these requests use the HEAD method instead of the GET method. If you are using a script or servlet to serve the file make sure you handle this properly. Some devices might request the file twice. It is rare, but happened (Siemens S55 is an example).
WURFL capability: directdownload_support
DownloadFun
Use the specific URL format.
WURFL capability: downloadfun_support
Read more on the Openwave developer site
OMA Download
OMA Download defines a technology for confirmed download to be used to deliver digital content such as images, sounds, videos and more. The need for this new technology is given because the HTTP protocol itself did not provide the necessary features for content providers to have a check before the download and a confirmation once the download is completed. It happens that devices may not handle the content provided or that content providers need a confirmation once the download is completed. This technology aims at solving these gaps.
WURFL capability: oma_support
Architecture
The architecture is quite simple and straightforward, service providers will produce a Download Description (for this reason this technology is often referred as OMA DD) and the content file. The mobile browser will check if the content is supported (content format, size, etc), download the content, install if needed and, if requested by the service provider, confirm installation. All this is based on standard HTTP communication.
Download Descriptor
The Download Descriptor is a simple XML file that you can create manually or have your application server create it at run-time. The following list describes the required elements of the descriptor:
type - indicates the media type of the object to be executed or rendered. Refer to MIME Media Types
size - it MUST be a positive integer and indicates the size of the content to be downloaded
objectURI - The URI (usually URL) from which the media object can be loaded
The following parameters are optional:
installNotifyURI - The URI (or usually URL) to which a installation status report is to be sent, either in case of a successful completion of the download, or in case of a failure
nextURL - The URL to which the client should navigate in case the end user selects to invoke a browsing action after the download transaction has completed with either a success or a failure
DDVersion - The version of the Download Descriptor technology
name - A user readable name of the Media Object that identifies the object to the user
description - A short textual description of the media object
vendor - The organisation that provides the media object
infoURL - A URL for further describing the media object
iconURI - The URI of an icon
installParam - An installation parameter associated with the downloaded media object
installNotifyURI is the most important parameter and is also the main reason for the definition of the technology. While is left optional for addition in the descriptor is mandatory for the browser implementation. Here is where the notification of the download result will be posted. If you are not going to use this parameter there is probably no need for you to use this technology.
name and description are two very important parameters too. When the user is about to download the content will be presented with a message from the browser showing these parameters. Should be used to aid the user understand what he is downloading. These are optional for the browser implementation too.
nextURL can be very useful, but is optional for the browser implementation. Once the download is completed the user will be automatically redirected to a new page. Some content providers might use it to up-sell more contents, in other cases you might want to redirect to instruction on how to use the downloaded content or other resources.
The file will be downloaded via standard HTTP, this means that you will have to set the appropriate Content Encoding and Content Type. The Content-Type header of the download descriptor should be application/vnd.oma.dd+xml.
Delivery Methods
The DD file and the media object can be delivered all together (A.K.A. Combined Delivery) or separately (A.K.A. Separate Delivery).
The Combined Delivery is probably the fastest for the user as at the request for content, the server replies with a multi-part package that includes both the Download Descriptor and the media object. Once the download is completed, if an installNotifyURI is specified the browser will still confirm the download. The user will not get the notification about the download, there will be no check prior the download and the user will not get a chance to stop the download before it starts if any error such as size too big or format not supported is noticed.
The Separate Delivery is the option that gives the user most options. The browser should present an alert message about the content that is about to download and should do basic checks such as if the media object is supported and there is enough space to store the content. The user is able to confirm the download or block it. Download report will always be notified to the server if installNotifyURI is specified.
Installation status codes
This table is copied and pasted directly from the OMA specifications.
Status Code Status Message Informative description of Status Code usage
900 Success Indicates to the service that the media object was downloaded and installed successfully.
901 Insufficient memory Indicates to the service that the device could not accept the media object as it did not have enough storage space on the device. This event may occur before or after the retrieval of the media object.
902 User Cancelled Indicates that the user does not want to go through with the download operation. The event may occur after the analyses of the Download Descriptor, or instead of the sending of the Installation Notification (i.e. the user cancelled the download while the retrieval/installation of the media object was in process).
903 Loss of Service Indicates that the client device lost network service while retrieving the Media Object.
905 Attribute mismatch Indicates that the media object does not match the attributes defined in the Download Descriptor, and that the device therefore rejects the media object.
906 Invalid descriptor Indicates that the device could not interpret the Download Descriptor. This typically means a syntactic error.
951 Invalid DDVersion Indicates that the device was not compatible with the “major” version of the Download Descriptor, as indicated in the attribute Version (that is a parameter to the attribute Media).
952 Device Aborted Indicates that the device interrupted, or cancelled, the retrieval of the media object despite the fact that the content should have been executable on the device. This is thus a different case from “Insufficient Memory” and “Non-Acceptable content).
953 Non-Acceptable Content Indicates that after the retrieval of the media object, but before sending the installation notification, the Download Agent concluded that the device cannot use the media object.
954 Loader Error Indicates that the URL that was to be used for the retrieval of the Media Object did not provide access to the Media Object. This may represent for example errors of type server down, incorrect URL and service errors.
Sample XML
This example was taken from the OMA Specification document:
image/gif
http:/download.example.com/image.gif
100
http:/download.example.com/image.gif?id=image
Want to know more?
OMA has a specific section called Release Program, look for “Download”. Version 1.0 of the specification provides 3 documents. It is strongly suggested to read the document tagged as “Specification” as it provides all the above information in more detail.
Future version of the specification might provide different documents.
General Content Descriptor (GCD)
A General Content Descriptor (GCD) file is similar to a JAD file. While a JAD describes a J2ME MIDlet for download, a GCD describes downloads like ringtones and pictures. GCD’s are plain text files and you can create them using any simple text editor like Windows Notepad. If you’d like your phone to download your own picture, then you’ll need a GCD file.
http://sprintdeveloper.com/article16.html
http://web.ics.purdue.edu/~butta/vision.html
GCD Creator
Here are some C# Sample files.
GCD Install-Notify
Nokia COD
COD stands for Content Object Descriptor and is a proprietary technology of Nokia. It was developed around 2002 and only a few devices ever supported it. The technology was developed an implemented while waiting for the formal implementation of OMA DRM and OMA DD.
COD takes inspiration from Sun’s MIDP OTA delivery system, which means a file descriptor and the content itself. Download happens in two steps, the site should provide a link to a COD file which contains all the needed information to download the content file. The device will present the user with a short description of the content and content type. The user confirms and the download starts. The COD has a set of required parameters and optional parameters.
COD offers at least 2 advantages, first of all the user is presented with a nice menu with a short description of the content and may choose to download or not. This is certainly a nice feature for the end-users, but it will not change your life, of course. The BIG advantage of COD over Direct Download is that developers can specify a URL to be notified when the download is completed successfully, much like the Install-Notify URL of MIDP. It is not a case that the parameter name is COD-Install-Notify. This can be a life-saver!
COD was an in-between technology and when OMA DRM and OMA DD where formalized, Nokia abandoned the technology.
Useful links, if they don’t die:
OTA download for generic content - Service Developer's Guide
Nokia DRM AND DOWNLOAD FREQUENTLY ASKED QUESTIONS, 3.5 What is the relationship between OMA Download and COD?
引用
http://www.thewirelessfaq.com/
d> 縮圖檔成果（圖例為tn_PICT3527)；這支程式自動將縮圖檔名加上 tn_ 。
。
。
。
!!
