I am sending multiple PDF files through SOAP which will be received by an Android client. But when receiving the SOAP response, it is throwing OutOfMemoryException.
I want to know whether its a limitation of kSOAP or Android. Please guide me how to overcome it.
Thanks.
I would suggest to not do that. Just put the raw url to the pdf file into the soap message and download the pdf separately independent of soap. That works great for me with PDF files as well as images..
So in a bit more detail:
One of your results from the SOAP request should contain a full public url to the PDF file somewhere on the internet.
Then use DownloadManager or whatever you want in terms of Android development to get the file downloaded by using the url you got from the soap response. But dont have the PDF wrapped within the soap request. That way you can also show a progress bar during download and so on nicely. Downloading files on Android is documented everywhere..
I now that this is old question but maybe I help other developers. The most efficient way to sending a large binary content from/to web service is MTOM transfer (SOAP with attachments). The problem is that ksoap2 library doesn't support this feature, but you can try http://easywsdl.com generator. What I know is that it supports MTOM transfer and allows you to send/retrieve very large binary files. Of course MTOM transfer has to be enabled also on the web service side.
Related
I have integrated socket.io into my android application to make a chat application. Now I wants to upload and share files like images, mp3 or doc file etc. How do I upload a file with socket.io I cannot find any documentation for doing.
It is not a good practice. This may lead blocking heartbeat messages between client and server if upload progress is long.
You may upload file with http post and send download link to chat peer. By doing this, a new connection is established for uploading and never breaks socket.io session.
I believe it should be a good practice to do in Android, as it works pretty well on web JS for small files such as Images, PDFs, etc.
But ya sending the whole file in a single shot is not a good practice(theoretically there should be no problem in doing that using socket.io), but it's better if you can the fragment the file into smaller pieces (maybe 2^10 to 2^20 bytes), and send it in pieces, doing so will also allow you to know the percentage of file's data transferred.
I am not good with JAVA, but I hope you can find a way to do that fragmentation thing.
But there is no inbuilt resource available in socket.io to transfer files, but you won't have any problem in sending pure Buffer(including '\0' in it) if you can manage to create a JSON object in JAVA without involving strings. As '\0' inside Strings messes them up.
I am trying to download a file from server, what I have in mind to get filename in json response and the content and write same in assets or on sdcard. should i go and implement same, or there can be some other way we can achieve the same.
Actually you know you control the way you expose the content from the server - you can just make the file itself (its bytes) exposed at certain url. If you need to keep the name of the file posting as json seems to be good solution.
However, there is one trick here: I don't know how big the file you refer to is and also how reliable the network will be. For every bigger file I will recommend to implement resumable upload via byte serving. You can read about the byte serving client consumer in Android in this thread. Then just go and see on how to implement byte serving server side - it definitely depends on the platform in the only case in which I used such mechanism I actually had to mimic the byte-serving with my custom url parameter. If you need further help on server side write back and I will extend my answer.
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.
In my app, I have to present a few numbers from a .csv file that's accessible from the web. Now, this .csv is quite big. I don't want to download and process the whole thing, there's no point. My numbers are always in the beginning of the file, in well specified positions - lets say position 5 to 10.
Could you give me some tips on how to implement this? I know how to download the whole thing, but don't know how to download only a part of it.
Thanks.
Psuedo:
BufferedReader br = new BufferedReader (new InputStreamReader(remoteStream));
String sFirstLine = br.readLine();
remoteStream is the stream of the connection to the remote server. Getting a handle to the stream is not the same as actually downloading. Only the BufferedReader.readLine() actually downloads anything
Do you have access to the server the file is on? You could do your processing on the server.
For example, if the file is at /myfile.csv, you could open a stream to mycsvfile.php on the server, which does the processing and returns the positions you're interested in. Of course you'd also have to write the PHP code (or whatever) to do this.
You don't say what protocol the file is served under, but assuming something standard like an http or ftp there should be nothing to stop you from starting the download and then aborting it once you've gotten as much of the file as you need, provided that you implement the android end of the protocol yourself rather than using one of the built in mechanisms (unless you find the built in mechanism also gives you the ability to abort).
I don't believe the implementation of a simple http downloader in java or ndk to be too complicated. Doing it on android should not be uniquely challenging as you have all of the normal java and underlying linux network sockets mechanisms readily available.
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.