Android developer uses Webuploader to solve the bug_android of uploaded images in an Android micro-mail browser

First of all to analyze the micro-letter browser upload image bug Reason

In its new version, the micro-letter uses its own X5 kernel browser, and in older versions it could be Android's native browser. I don't know much about the environment, but with the actual number of Android tests, I've taken the initiative to basically ensure the successful uploading of the micro-browser in Android. The Apple model is fine because the micro-mail iOS client uses the Safari kernel, with no pits and the best results.

Here is a Webuploader official issues link to the mobile end adaptation. The method provided here is really effective, but the solution is not clearly demonstrated, from the issues several individual users to propose how to modify it can be known.

Problems encountered at the beginning

Environment

Using Spring MVC [V 4.08] in the background, the front-end uses an open source HTML5 framework

Problem

iOS is a perfect upload, more than half of Android phones are not supported, a progress bar is stuck, pictures cannot be uploaded successfully and can only upload PNG format pictures (later proved to be caused by compression failure, in the resolution). Published to the server after the official operation, found that some users only fill in the text information, can not upload pictures, bad statistics, but such a BUG rate is obviously not, and then give my solution, after the actual test should be no problem, not guaranteed to be completely effective, because the principle is not too clear, only for reference.

Later solutions

The first step, sendasbinary:true

First of all, I follow the issues to give a solution, set the Sendasbinary:true, the background does not make any changes in the case will produce 500 of the error, but this time to solve the progress bar card dead (of course!). The picture is uploaded directly failed! ）...... According to the answer in issues 2betop, getting the file at this time should be a direct fetch of the binary stream of the file.

The way to get a picture before is to use the multiparthttpservletrequest of Spring to transform the HttpServletRequest instance request, and then get the information for multiple files. The code below is based on the actual code that cuts unnecessary details.

 Multiparthttpservletrequest multipartrequest = (multiparthttpservletrequest) Request
;
Gets the list of uploaded files map<string, multipartfile> filemap = Multipartrequest.getfilemap ();
Image upload before the original name String Originalname; Loop to get multiple file uploads each file object in the file list for (map.entry<string, multipartfile> entity:fileMap.entrySet ()) {//upload file Multipartfil
e MF = entity.getvalue ();
The original name originalname = Mf.getoriginalfilename () before the file is uploaded;
File name extension String fileext = originalname.substring (Originalname.lastindexof (".") + 1). toLowerCase ();
File's absolute path file file UploadFile = new file (Uploadabsolutepath + "/" + newName); try {filecopyutils.copy (mf.getbytes (), uploadfile);} catch (IOException IOException) {logger.error ("Picture saved in folder Error! ", IOException);} 
catch (Exception e) {logger.error ("File not copied to specified directory", e);}} 

This is the original way to get, 500 when the error indicates that the first line of code error, cannot be converted, because at this time Webuploader set the sendasbinary:true and did not use content-type:multipart/form-data upload files , but Content-type:application/ocet-stream, the source code is written in this, but actually get the request header did not see this field, but only the type of picture. The following gives me the devtools of using Chrome Saved request information, only the field values in the headers are posted (for the same upload API):

500 the request header at error

"url": "Http://localhost:8787/lostFound/front/release/upload?releaseType=0&orderId=330&id=WU_FILE_1 &name=20140120_035024000_ios.jpg&type=image%2fjpeg&lastmodifieddate=sat+jan+31+2015+01%3a32%3a34+ gmt%2b0800+ (%c3%a4%c2%b8%c2%ad%c3%a5%c2%9b%c2%bd%c3%a6%c2%a0%c2%87%c3%a5%c2%87%c2%86%c3%a6%c2%97%c2%b6%c3%a9% C2%97%C2%B4) &size=81666 "," httpversion ":" http/1.1 "," headers ": [{" Name ":" Origin "," Value ":" http://localhost : 8787 "}, {" Name ":" Accept-encoding "," Value ":" Gzip, deflate "}, {" Name ":" Host "," Value ":" localhost:8787 "}, {" Name " : "Accept-language", "Value": "zh-cn,zh;q=0.8"}, {"Name": "User-agent", "Value": "mozilla/5.0 (IPhone; CPU iPhone os 9_1 like Mac os X applewebkit/601.1.46 (khtml, like Gecko) version/9.0 mobile/13b143 "}, {" NA Me ":" Content-type "," Value ":" Image/jpeg "}, {" Name ":" Accept "," Value ":" */* "}, {" Name ":" Referer "," value ":" http:// Localhost:8787/lostfound/"}, {" Name ":" Cookie "," Value ":" Jsessionid=2839511c91e9ece62d155c6ee18f3259; Jsessionid=64b53863e1c7d82b96927f298a864e18 "}, {" Name ":" Connection "," Value ":" Keep-alive "}, {" Name ":" Content-length "," Value ":" 81666 "}]," querystring ": [{" Name ":" ReleaseType "," value ":" 0 "}, {" Name ":" OrderId "," Val  UE ":" "{"}, {"name": "id", "value": "Wu_file_1"}, {"name": "Name", "Value": "20140120_035024000_ios.jpg"}, {"Name": ' Type ', ' value ': ' Image%2fjpeg '}, {' name ': ' LastModifiedDate ', ' value ': ' sat+jan+31+2015+01%3a32%3a34+gmt%2b0800+ (% C3%A4%C2%B8%C2%AD%C3%A5%C2%9B%C2%BD%C3%A6%C2%A0%C2%87%C3%A5%C2%87%C2%86%C3%A6%C2%97%C2%B6%C3%A9%C2%97%C2%B4) "} , {"Name": "Size", "value": "81666"}], "Bodysize": 0

Request headers that were successfully uploaded before Sendasbinary:true is modified

 "url": "Http://localhost:8787/lostFound/front/release/upload", "httpversion": "http/1.1" , "headers": [{"Name": "Origin", "Value": "http://localhost:8787"}, {"Name": "Accept-encoding", "Value": "Gzip, Deflat E "}, {" Name ":" Host "," Value ":" localhost:8787 "}, {" Name ":" Accept-language "," Value ":" zh-cn,zh;q=0.8 "}, {" Name ":" User-agent "," Value ":" mozilla/5.0 (IPhone; CPU iPhone os 9_1 like Mac os X applewebkit/601.1.46 (khtml, like Gecko) version/9.0 mobile/13b143 "}, {" NA Me ":" Content-type "," Value ":" Multipart/form-data; boundary=----Webkitformboundarylevpfviklf1xldir "}, {" Name ":" Accept "," Value ":" */* "}, {" Name ":" Referer "," Value ":" H Ttp://localhost:8787/lostfound/"}, {" Name ":" Cookie "," Value ":" jsessionid=a76c40d04276501f54675aa02ae61467; Jsessionid=64b53863e1c7d82b96927f298a864e18 "}, {" Name ":" Connection "," Value ":" Keep-alive "}, {" Name ":" Content-length "," Value ":" 44210 "}]," querystring ": []," bodysize ": 929, 

Compare the difference between the two and find the difference:

Content-type: After being modified to sendasbinary:true, this value changes to Image/jpeg, which is multipart/form-data, so you can no longer use multiparthttpservletrequest , the back-end fetch is changed to get the file stream.

QueryString: When binary uploads are enabled, parameters are added directly to the URL.

Bodysize: Turned 0 after enabled, not 0 before enabling

Modify the backend capture first, and the code changes as follows:

File File = new file (Uploadabsolutepath);
if (!file.exists () &&!file.mkdirs ()) {
//If the file object does not exist, create a folder directory that does not exist in the path name of the object
}
//file name
extension String Fileext = name.substring (Name.lastindexof (".") + 1). toLowerCase ();
File's absolute path file file
uploadfile = new file (Uploadabsolutepath + "/" + newName);
try {
//Save the uploaded image binary stream as a file filecopyutils.copy (
request.getinputstream (), New FileOutputStream (UploadFile));
catch (IOException IOException) {
logger.error ("The picture was saved in the folder was wrong!") ", IOException);
} catch (Exception e) {
logger.error ("File not copied to specified directory", e);
}

The back end is able to get the front end upload picture, the iOS model (IPhone 6s) is still no problem, Android upload PNG format pictures without any problems, but JPG is still unable to upload. At the back end, print request headers, found that the Android model upload JPG image is lost Content-type, the value is empty. Combined with the judgment in the issues, perhaps the Android model in the compression JPG image when the problem, the first solution to try again!

Step Two: Add Androidpatch

According to the official instructions, the use of Webuploader.custom.js, which will runtime/html5/androidpatch.js packaged in.

And then without modifying any of the code, after five mobile phone testing, the new and old models: Huawei Glory, Charm Blue, Lenovo and so on test, Android can be in the micro-letter upload pictures at random. This is a big pit! Description can not upload jpg image of the reason is compressed JPG image when the error, resulting in the progress bar card dead, upload failed.

Summary of the use of experience

According to the above summary, I think next time I should be able to use this once again to solve the micro-letter upload image of the Pit ~ also know from request headers to find the cause of the bug, Webuploader is a very good open source Plug-ins, the source code is also written very organized, clear and easy to read, Although I did not finish reading. Now reading frame source is more and more relaxed, refueling, the next goal is learning react.js.

The above is a small set to introduce the Android development using Webuploader solution to Android micro-letter browser upload photos encountered in the bug, I hope to help you, if you have any questions please give me a message, small series will promptly reply to everyone. Here also thank you very much for the cloud Habitat Community website support!