Select a fixed buffer size first.
Then start writing the byte array to a file. Once the file size reaches the
buffer size configured, copy that file to a temporary location (a temp
file). Then transfer this temp file to the web server. Once transferred
successfully, make sure to delete this temp
I think you are on the right track. I have had very similar problems
in the past. For me the temporary file solution was obvious because I
had to modify the media before I uploaded it. Once you have a
temporary file, then you have the generic problem of uploading a large
file to a web server,
Why are you reading the entire file into a byte array?
That sounds right there like the OutOfMem error.
public static byte[] getBytesFromFile(ContentResolver cR, String
fileUriString) throws IOException {
Uri tempuri = Uri.parse(fileUriString);
InputStream is =
Why are you reading the entire file into a byte array?
That sounds right there like the OutOfMem error.
Because it's the only way that I know to get from a content Uri to the byte
array that I use to create the FilePart element of the multipart message.
It is possible to create the FilePart
I suppose when you say FilePart, you mean this
org.apache.commons.httpclient.methods.multipart.FilePart
I'm thinking along these lines after looking at that API (I haven't
tested this)
final File theFile = new File(yourFileLargerThan2Mb.ext);
//Implement your own PartSource to feed your File
On 9 April 2010 18:19, Gubatron gubat...@gmail.com wrote:
I suppose when you say FilePart, you mean this
org.apache.commons.httpclient.methods.multipart.FilePart
I'm thinking along these lines after looking at that API (I haven't
tested this)
final File theFile = new
On 9 April 2010 19:35, Anna Powell-Smith annapowellsm...@googlemail.comwrote:
On 9 April 2010 18:19, Gubatron gubat...@gmail.com wrote:
I suppose when you say FilePart, you mean this
org.apache.commons.httpclient.methods.multipart.FilePart
I'm thinking along these lines after looking at
1. Why are you using a ContentProvider?
Because that seemed to be the best way to get from a content URI
(returned from the Android video camera intent) to a byte stream.
Happy to do it another way, though.
2. What are you doing with the 2MB byte array when you get it on the
ContentResolver
I got the same problem, when I uploaded the videos to Facebook, I have got
the same issue while uploading big files, have you found any workarround,
even I flushed the outstream on every read. but it did not also seems be the
solution.
On Fri, Apr 9, 2010 at 2:23 AM, Anna PS
Anna PS wrote:
1. Why are you using a ContentProvider?
Because that seemed to be the best way to get from a content URI
(returned from the Android video camera intent) to a byte stream.
Happy to do it another way, though.
Oh. I thought you had perhaps written the ContentProvider in
I suspect your problem is not in reading the InputStream, but rather in
how FilePart does what it does. Since that isn't part of Android, it was
probably developed without tight memory constraints in mind. If you hand
it 1 KB chunks each time, it is probably going to allocate a 1 KB byte
Anna PS wrote:
OK, I see. Although, I do get the OutofMemoryError on the
byteBuffer.write(buffer, 0, len), well before I do anything with the
FilePart.
That doesn't make sense. What are you doing with the 1 KB you read in
each time? I assumed you were feeding that into the FilePart.
It is my
It is my Web server, so I can rewrite it to accept a PUT request. Are
you suggesting that I do something like this, for each 1MB of the
data?
HttpPut httpPut = new HttpPut(url);
httpPut.setEntity(new StringEntity(data));
I'd use ByteArrayEntity.
what about streaming it with
On Apr 8, 11:00 pm, Mark Murphy mmur...@commonsware.com wrote:
Anna PS wrote:
OK, I see. Although, I do get the OutofMemoryError on the
byteBuffer.write(buffer, 0, len), well before I do anything with the
FilePart.
That doesn't make sense. What are you doing with the 1 KB you read in
:: smacks forehead ::
This is why I really shouldn't try to answer questions when I'm
seriously short on sleep.
Anna PS wrote:
But I get the error on the first line of that code, in the readBytes
that's called from getBytesFromFile.
Actually, you get it from the ByteArrayOutputStream. It's
To ask a dumb question, as someone who hasn't used chunked uploading
before: how can I indicate to the server the order in which to glue
the chunks back together? (Tell me to go away and ask a Java forum if
you want.)
If you're designing your own protocol, you do it however you want.
I'm a bit puzzled why the other respondents didn't pick up this, maybe
I missed something in the discussion?
But anyway, the basic flaw in your strategy is reading it all into
memory at once. There's no need to do so, and that is ALWAYS going to
impose a limit on the size of file you can handle,
Bob Kerns wrote:
I'm a bit puzzled why the other respondents didn't pick up this, maybe
I missed something in the discussion?
But anyway, the basic flaw in your strategy is reading it all into
memory at once. There's no need to do so, and that is ALWAYS going to
impose a limit on the size
18 matches
Mail list logo