Call onCompleted only when the server response code is >= 200 and < 400

Actually the onError callback gets called only if the request cannot reach the server due to networking errors, even after the retries.

If the request successfully reaches the server, the onCompleted gets called with the server’s response.

This has to be changed, because it’s not intuitive and practical for error handling when the server responds with http codes which indicate errors, such as 4xx or 5xx and does not allow to show the error message configured for the notification.

The callback methods should be called in this way:

• onCompleted when the server responds with an HTTP code >= 200 and < 400
• onError if the request could not reach the server or if the server responds with a code >= 400

This means changing the public API of the callback’s onError method, which will be the following:

/**
 * Called when an error happens during the upload, after that all the retries have been 
 * completed without success. Override this method to add your own logic.
 *
 * @param context context
 * @param uploadInfo upload status information
 * @param serverResponse response got from the server
 * @param exception exception that caused the error
 */
void onError(final Context context, final UploadInfo uploadInfo, 
             final ServerResponse serverResponse, final Exception exception);

This issue is open for discussion

[gotev]

I’m no expert on requests but I think onError will not get the job done

Actually, I think it can solve the problem, and I’m going to explain why IMHO.

What if the request reached the server, and there was a custom error I created?

When implementing whatever endpoint, you should always follow the HTTP Status codes definition in RFC2616 to be standard compliant and to not reinvent the wheel.

For example: “max file size is 5mb”, its a simple if/else check on server-side where the request is received but the file did not moved to folder to say its “uploaded”.

Fail fast is a good approach when dealing with requests to a server. If the client is not allowed to perform an action, you should kick it as soon as possible. Following the RFC, to implement your example, you should simply return 413 Request Entity Too Large and not accept the request at all, so you don’t consume network bandwidth and resources both on the client and the server. When you have to check the length of the upload, always use fixed length streaming mode on the client, which is supported by Upload Service. This results in the Content-Length header being sent in the request, so you can inspect it on the server and act accordingly.

You can always return a response body with HTTP status 4xx. In fact, if you have more complex checks which does not match any of the 4xx error codes, practice suggests to send a 400 Bad Request with the error detail in the response body.

E.g.: HTTP Status: 400 Bad Request Response body:

{
  "error": "you should accept the privacy policy agreements in your profile to be able to upload photos"
}

Let’s examine a more complex scenario. You upload a file which has to be validated by the server after it has been uploaded. You let the client perform the upload, and after it has been completed you perform the server-side checks. After the checks have been performed, you return a 2xx if everything is ok or a 4xx with all the relevant details which tells the client exactly what has gone wrong.

Having said that, I like your idea to be able to modify the notification message from the callbacks, because it allows you to display more details to the user after the request has been completed (either successfully or with an error), though I’m not sure if it’s possible with the actual architecture, because each upload task manages its own notification and then sends broadcasts to notify the status outside the task.

[gotev]

This is getting OT here as new ideas comes. Let’s continue the discussion about notifications on #260