Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
03-29-2011 09:46 AM
Hello, I am trying to send an image to the server using the HTTP connection. What I am doing is the following:
1- Read the image Bytes
2- Convert the image to a Base64 String
3- Send the String to the server
The problem is that when sending a big base64 String to the server, this doesn't work!!!
I followed the code and the problem appears on the outputStream.flush() method. I don't know what's wrong, but as a solution I added 8 lines of outputStream.flush(), this works!! But i need a good solution because when the image size augments, i need to flush again more than 8 times. The code of the connection is as follows:
private OutputStream os = null;
os = _httpConnection.openOutputStream();
03-29-2011 03:30 PM
Are you immediately calling the close() method after the flush(). I got an error when I did that, my workaround was to comment out the flush method and call close() after I do a write().
Hope this helps!
03-29-2011 06:01 PM
These both seem like work arounds, is there an OS problem here?
Can you tell us what size the images are and what connection method you are using? Also what OS levels are involved (for compilation and device/simulator).
03-30-2011 02:54 AM
The image size is about 30 Kb and the OS involved is 5.0 (the simulator OS). But I want that to work also on 4.6 devices.
The class used to connect is the following:
03-30-2011 04:29 AM
First a couple of minor comments
1) the following code creates an Integer object that is then immediately discarded:
instead do this:
2) If you want this code to work in 4.6, you should be compiling and running in 4.6. OS 5.0 code is not supported on OS 4.6. OS 4.6 code is supported on OS 5.0. However there are issues of APIs that you might want to use not available in OS 4.6. For me these are mostly around the detection of touch events. SO I end up doing a pre OS 4.7 build and an OS 4.7 and above build (at least).
Now onto the problem. You code looks fine, the size of file should be able to be sent. There is an issue with the encoding:
URL encoding will replace + with spaces, or is it the other way round? Can't remember. Result is that this corrupts Base 64 encoded data. Talk to your Server people about using another encoding method.
However this does not explain your problem, at least I don't think it does. This problem would cause corruption in the image sent.
Can you change your Server processing so that it just logs the posted data and does not try to process it., This should work regardless of the encoding. And if it does work, then you have a Server issue.
But this is only a guess. From my review, your code looks fine.
Actually there is potential problem in your processing of the response. Another encoding issue. Your code will assume ISO-8859-1 encoding in the response. But we can look at this another time.