I am currently getting a base64 encoded image from a mobile device's camera using PhoneGap, I would like to upload the image to a server to then store. Not sure what the right approach is?
As expected, if I try to include the base64 string as a parameter I get the Error 414 (Request-URI Too Large)
Even if you use POST the server accepting the POST will need to be capable of decoding the base64 parameter. Luckily the PhoneGap API provides a better way to do this with FileTransfer.
You need to get the file handle to the image instead of the base64 encoding. Using the file handle resolves the issue of getting a JavaScript out of memory error. This also removes any cross-site scripting issues since PhoneGap is using native code to perform the post instead of using the browser. Hope that helps.
I agree with Chuck you are better off using the FileTransfer object. Large Base64 strings will cause out of memory errors in your app. Zac has a good tutorial on the subject:
http://zacvineyard.com/blog/2011/03/25/upload-a-file-to-a-remote-server-with-phonegap/
Why not use HTTP POST instead of HTTP GET?
Related
My app uses the NetworkIamgeView class in the Volley library to show the images. For some urls the images are not shown correctly. I noticed that these links point to png files, however the content type is image/jpeg. Is that the cause of the problem?
http://baseurl/Standard1280x720.jpg/jcr:content/renditions/cq5dam.thumbnail.744.415.png
However these links are all rendered correctly on the browser app on Android phones. Are there some simple fixes to handle this?
Thanks
Ray
Q1: No, Volley does not use the content type when parsing the image. It delegates the task to the BitmapFactory. This means that it could work differently on different devices and also that supported formats can vary.
Q2:
Are there some simple fixes to handle this?
By
For some urls the images are not shown correctly
It is not clear what the issue is. I suggest enabling logs to see what exactly is received form the server. You can also just extend ImageRequest, add it to the queue and log the bytes there.
Figured out the problem. Volley does not support redirection.Had to modify the library to handle http 301 results.
I want to send a picture from my mobile to my server, and i know how to send it using base64 but i've heard that base64 is not recommended to use because base64 encoding increases the size of image by 37%, which in case slows down the performance of server because there will be too many images shared by users on the server.
can anyone recommend me the efficient technique than base64 encoding for the mobile based image sharing application (client-server app)?
You could simply POST your image (in regular UTF-8 encoding) as explained here: NSData and Uploading Images via POST in iOS. You will need to have some server-side servlet or php page to decode the image and save it.
You can use FTP, for uploading and downloading images from iPhone. The main advantage of using FTP over other methods is that we can set the bytes width per second to certain limit and can detect how much data has been transferred till Particular event.
Here is the code given by apple documentation to illustrate the uploading and downloading of any data (image, pdf, video or audio anything) over FTP.
http://developer.apple.com/iphone/library/documentation/Networking/Conceptual/CFNetwork/CFFTPTasks/CFFTPTasks.html#//apple%5Fref/doc/uid/TP30001132-CH9-SW1
Also refer this PDF for better understanding
http://developer.apple.com/iphone/library/documentation/Networking/Conceptual/CFNetwork/CFNetwork.pdf
Just wanted to know if it is better to have "Accept-Encoding", "gzip" in request headers while making HTTP request in android?
If not then in which cases it is not preferable? Also can it be used for requests returning XML or JSON as response?
Thanks in advance!
The gzip encoding is used to cut down the size of the data being transmitted over the netwrok. It compresses it into a zip and gives you a smaller compressed version which in turn reduces bandwidth usage and makes for faster programs. So i would say there is no harm in adding the "gzip" tag as it would definitely speed up the get process in most cases. A good site you should probably look at:
Is this
And yes. It can be used with xml.
Some of the issues are
Most of the images are already highly compressed and cant be
compressed further.
Some of the older versions have problems with compression but this
should not be an issue for you.
I'm looking for a complete example for uploading an image + some text fields from Android to a WCF service. I've been searching for days without finding any useful examples. What I need is the code for both the client and server.
I've been able to make it work with JSON and Base64 encoding the image as a string, but this is way too slow with images around 500KB. What I'm looking for has to be efficient. Probably using a stream.
Can anyone please give me a complete sample code? I've seen a lot of snippets on each side, but not a complete sample. From getting the image from a path on the phone to posting it to the server and consuming it on the server in C#? How to get the image as a bytearray on the server and the text into string variables?
Thanks for listening.
For setting up WCF streaming on the server side see : http://msdn.microsoft.com/en-us/library/ms789010.aspx
You could also try just using basic http binding and MTOM.
For the android part you will need to get help from someone else, sorry.
I have a WCF REST service built with C# and it returns an image as part of a CPU intensive operation. The client is running on Android (Java) By default, it will return a text JSON object that looks something like this:
{"d",[9,0,77,12,11,...]}
Those are they bytes of the image. Fine. However, all the solutions for decoding this JSON are intolerably slow. I've tried Gson, Jackson, and the built-in Android JSONObject class. I have no idea why they are so slow.
As an alternative solution, I have my REST service return a GUID, and then that GUID can be used by the Android client to go to a regular URL that serves up the image as a regular binary stream, via an MVC controller.
This works well, and it fast, and is pretty easy to handle on the Android side. However, it does feel like a bit of kludge and kind of a violation of the REST design principles.
Am I missing something here? Is there a better way to do this?
How about your REST service return a Redirect 303 with a Location header that has an URL that points to the image? Or why not just return the bytes directly from the first URL?
As far as RESTful or not, returning a JSON encoded image is not exactly in the spirit of the REST self-descriptive constraint.
Just make sure the endpoint that returns the image stream of bytes, actually uses an image/* media type in the content header.
Well, on of your main problems is trying to transmit binary data using a text format.
Most if not all java json libraries will try to recognize the type of the field. It'll take a long time if there's a lot of fields.
Yeah, streaming it directly is a lot faster. Maybe you can use XML since it supports binary or blob data.
As Darrel wrote above, if the URL computes and returns an Image, simply return that Image with an appropriate content-type, for e.g., as a PNG image. Transmitting the image encoded within JSON is a strange choice, to say the least.
There is a great talk about developing rest client application on android form Google IO 2010.
http://www.youtube.com/watch?v=xHXn3Kg2IQE
This session will present architectural considerations for developing RESTful applications on the Android platform. It focuses on design patterns, platform integration and performance issues specific to the Android platform.
A great resource and must watch.