Upload progress bar possible?

[pillar]

Hello, I am trying to accomplish an upload progress bar for my application. It will send large files, so it would be very important to show this information to the end user. Is there way to get information about how much has actually sent?

I have tried sending 1024 bytes at a time (to OutputStream), but I guess it all gets buffered before sending, because it shows it has sent it all before it actually has even started.

If this is not possible, any viable workarounds for this?

[shmoove]

Have you tried using OutputStream.flush() to work around the bufferring?

shmoove

[pillar]

Yes. Doing the OutputStream.flush() seems to send everything sent so far and anything after that gets ignored.

I just found out another problem with the buffering. There seems to be a limit the buffer can handle. If the data size grows too big (not sure yet where the limit is - I'll test it right away) then the application will throw an unhandled exception.

[shmoove]

So you're using http, right? When you flush, the buffer is sent, the server sends a response and the connection can't be used anymore (that's why everything after the flush() gets ignored). If you want to do this with http I think you'll need to send the data in multiple requests (ie, multiple connections from a Java standpoint), like one file or data chunk per request. The performance shouldn't suffer too much from this because the vast majority of phones have linger time and will reuse the same socket for every request.

Otherwise I'm afraid your only other option is using tcp sockets (where you can flush() and then keep on sending). You can keep the http server if you want, but that would mean you'd have to construct an http request manually and send it over the socket.

shmoove

[pillar]

shmoove:

Yes, I've been using Http. Thank you for your helpful reply. Just to clarify what would be needed with the different options:

1 option: Is there an existing way for the server to receive multiple part upload and be able to put them together or should I make it myself?

2 option: This would be done with SocketConnection?

[axs]

Hi!

shmoove is right. As long as we had such things under development, we simply put a package of data on a single http connection. Actually flushing the OutputStreams in Java doesn't mean flushing the real OS buffers, because this is the subject of OS schedules, optimizations, etc., so sending one packet of data per connection was the only option. Ofcourse, for enabling continuous uploads we used the http headers and stored there session information.

SocketConnections are more efficient for such applications, but sockets are not supported on all MIDP 2.0 mobile phones (if you are thinking about the portable mobile application)

[pillar]

How can I know which mobile devices support SocketConnection? I'm mainly developing for Nokia N93, but it will be probably used in other phones as well. Axs: Would you be so kind and show how you used the http headers to continue the upload in many packages?

[shmoove]

1 option: Is there an existing way for the server to receive multiple part upload and be able to put them together or should I make it myself?

I'm not a server side expert but I think you would have to do that yourself. As axs mentioned, you can add your own http headers that the server can use to keep track of which part it is getting.

2 option: This would be done with SocketConnection?

Yes, that's what I meant.
In this case you could keep using the old http server if you "wrap" the message you are sending in an http request (ie, sending the http headers manually before you start sending the data).

shmoove

[pillar]

Okay, this is the situation right now:

I am developing this so that I will use the session to track down multiple http sessions where I upload packages of the data. The server side has a php script that will return the phpsessid with the first connection. I succesfully read that to a variable in my j2me.

I then try to do following:

String phpSID = "PHPSESSID=" + nSessId;
http.setRequestProperty("Cookie", phpSID);

which should set the http header to look like there is a cookie with the phpsessid. But when I check the values of any cookie data from the script it tells me that there is a cookie called PHPSESSID, but it is empty. So it gets set, but for some beyond-me-reason it is empty.

Other than that, everything is looking like working, so if someone can please help me with this. Thank you

[axs]

Hi (and sorry for my late answers)!

pillar, the main idea behind the http headers is just to ensure that your server component is putting or appending received data to the right file (or database entry, what so ever). There is no magic about the http headers, and there is no common way to implement such "uploading and tracking" functionalities through the http headers. The main thing is just to tell what is the session ID (or client ID, or file path, etc.), and what is the data offsets and length you are currently sending to the server. The rest is just to put correct data in http headers and request body, and correctly interpret and utilize it on the server side.

It is up to you and your solution what data you will put in your http headers and how your server will interpret it. The main thing is that your server will interpret your http-packets correctly and will put right amount of bytes in right file or database entry. I just put here my very-very old solution (just to show you the idea - may be even not so efficient one):


// send "length" bytes of data to the server, on UPLOADING_URL, starting from the "offset"

HttpConnection httpConnection = (HttpConnection) Connector.open(UPLOADING_URL);

// specify the type of HTTP request

httpConnection.setRequestMethod(HttpConnection.POST);

// session ID is received from the server earlier (it could be user ID, of simply the path of the file you are currently working with)
httpConnection.setRequestProperty("sessionID", sessionID);

// length (in bytes) of the data you are uploading to the server
httpConnection.setRequestProperty("length", length);

// offset in file on the server (for appending to)
httpConnection.setRequestProperty("offset", offset);

...

send data to the server and "flush"

...

close http connection

...

send another portion of data, while you haven't reach the end of file.


I have to say that on socket connections the functionality is looking like the same, but if you are keeping socket connections alive, you have to separate requests and responses from each other in some unique way. I highly recommend you to use the XML tags, which later can let you to run a few versions of server-functionalities in parallel, and make you free from the data missinterpretings problems later. However, such XML- and socket-based functionality is more complicated then one based on the HTTP-communications.

If you are dealing with binary formats (images, videos, non-ASCII formats), I just can suggest you to convert binary data into the Base64 format, put it into the communication channel, and decode it back to the binary form on the server side. (Otherwise in too many ways the non-ASCII bytes of your data could affect not so desired functionalities of your solution).