Resumable download on Android

Let's talk about the principle of resumable upload: This is part of the HTTP 1.1 protocol and does not require the client to do anything complicated. I have read a technical bidding document from a company before, and the requirement for resumable download exists. The offer is quite high...

 

Simply put, as long as the use of the HTTP protocol (http://www.ietf.org/rfc/rfc2616.txt) in the following fields to interact with the server side, you can achieve the resumable upload of File Download:

Range: used for client-to-server requests. You can use this field to specify the size and unit of a file to be downloaded. Typical formats include:

Range: bytes = 0-499 download content in the range of bytes 0-499

Range: bytes = 500-999 download content in the range of 500-999 bytes

Range: bytes =-500 download the last 500 bytes of content

Range: bytes = 500-download content starting from 500th bytes to the end of the file (this is the most common format)

Range: bytes = 0-0,-1 download the content of the first and last bytes (this seems abnormal ...)

 

Accept-ranges: Used for the response from the server to the client. The client can use this field to determine whether the server supports resumable data transfer (note that this part is not required in RFC ). The format is as follows:

Accept-ranges: bytes indicates that transmission in bytes is supported.

Accept-ranges: None indicates not supported

 

Content-ranges: Used for the response from the server to the client. In the same message as accept-ranges, this field specifies the byte range of the returned file resources. The format is as follows:

Content-ranges: bytes 0-499/1234 content in the range of bytes between 0 and 499 for a file with a size of 1234

Content-ranges: bytes 734-1233/1234 content in the 1234-ending range of a 734th-Byte File

 

Based on this, we can know that the resumable upload function can be completed only when both the client and the server are supported.

 

The Android platform provides developers with the downloadmanager service, which can be used for downloading and receiving real-time update prompts about the download progress asynchronously. This interface is used by native browsers, Android Market, Gmail, and other clients. This interface also provides the resumable upload function. If a network error occurs during the download process, such as a signal interruption, downloadmanager will attempt to resume the download when the network recovers. However, user-initiated pause and resumable data transfer are not supported.

 

It is not difficult to extend this function. You only need to add a new State (similar to paused_by_user) for the download task and related logic. I will not repeat it here to introduce the topic to some common problems.

 

1. About etag

The definition in RFC is abstract. In short, etag can be used to identify/ensure the uniqueness or integrity of a file. You can regard it as the Unique Identifier value produced by the server for a file, this value changes every time the file is updated. Through this mechanism, the client can check whether a file has been changed before and after resumable upload (of course, it is not only used for resumable upload: if etag changes, you should re-download the entire file to ensure its integrity.

 

However, in the real environment, some servers do not return the etag field and support resumable data transfer. In this case, native Android considers that the server does not support resumable data transfer. This should not be a bug, but it is just so implemented. The more troublesome situation is that some servers have given the wrong etag, but the file has never been changed. In this case, to modify this "bug" from the client, it is estimated that the etag value can only be ignored.

 

2. About HTTP 206

The RFC defines the server response when a breakpoint is resumed: If the content that is supported and returned is part of the file as required by the request, the HTTP 206 status code is used; if not, or the entire file needs to be returned, the HTTP 200 status code is used. However, some servers in the real network, regardless of 200, return. No way. If you still want to modify this "bug" from the client, make more judgments: if the server specifies "content-ranges", ignore the HTTP 200 status code.

 

The following figure shows the process.

 

 

Note: I was once asked how to pause a download task on a native Android phone and resume the download. I wonder if I can disable the mobile phone signal during the download process. When I enable the mobile phone signal next time, the download task can be automatically resumed (of course, the premise is server support )... this use case has little practical value and is too lazy to be tested.

Link: http://blog.csdn.net/Oneway102/article/details/6060961