J2me, data input stream, Sony Ericsson's K750i,

[Boki]

Hi All,
Before optimize the JPG code, here is a branch problem on Sony
Ericsson's K750i
I don't know why, it seems that very strange, the code will just stop there.

I can't sure which line, but it seems stops! ( stay(stop) in a line until I
send data from client )

I will find another JSR-82 supported phone, just feel very strange here..

Originally, I want to code as:

polling incoming data, when data stops, I will collect them and decode as
JPG, but right now, I can't know when it stops... because the code didn't go
through~~~


----------------------------
int bytesToRead = in.available();
if (bytesToRead > 0) {
// Initialize buffer
byte[] byteBuffer = new byte[bytesToRead];
// Read bytes
nbrOfBytesRead = in.read(byteBuffer);
------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the code will not go to next line until I send data from clinet @@


do you have the same experiance ?

Best regards,
Boki.

 

[Roedy Green]

int bytesToRead = in.available();
if (bytesToRead > 0) {
// Initialize buffer
byte[] byteBuffer = new byte[bytesToRead];
// Read bytes
nbrOfBytesRead = in.read(byteBuffer);

Please see http://mindprod.com/jgloss/readBlocking.html

Your code is probably behaving like a 4 year old, in a tight loop
saying, "Can a have cookie now?." "No dear. I have to wait for the
bread man to come in his truck." "Can I have a cookie now?" No dear,
I have to wait for the bread man to come in his truck."

 

[Boki]

Hi Green,
I want to do polling, I don't know the data length first, I
want the code can polling data, when there is no more data in a timer time,
exit and then show that jpg file.

do you mean when I write code as example, and my problem will disappear ?

Best regards,
Boki.

int bytesToRead = in.available();
if (bytesToRead > 0) {
// Initialize buffer
byte[] byteBuffer = new byte[bytesToRead];
// Read bytes
nbrOfBytesRead = in.read(byteBuffer);

Please see http://mindprod.com/jgloss/readBlocking.html

Your code is probably behaving like a 4 year old, in a tight loop
saying, "Can a have cookie now?." "No dear. I have to wait for the
bread man to come in his truck." "Can I have a cookie now?" No dear,
I have to wait for the bread man to come in his truck."

 

[Roedy Green]

I want to do polling, I don't know the data length first, I
want the code can polling data, when there is no more data in a timer time,
exit and then show that jpg file.

do you mean when I write code as example, and my problem will disappear ?

You need a time delay after a getAvailable() == 0 since if you ask
right awy there will will rarely be anything for a good many
iterations, and you are just gobbling CPU time.

Loo at how the code I gave you does it.

 

[Boki]

OK, thanks, I will try it

Best regards,
Boki.

 

[Darryl L. Pierce]

You need a time delay after a getAvailable() == 0 since if you ask
right awy there will will rarely be anything for a good many
iterations, and you are just gobbling CPU time.

You don't need a delay if you ask for data in discrete packets rather
than asking for one byte at a time:

byte[] buffer = new byte[4096];
boolean done = false;

while(!done)
{
int read = istream.read(buffer);
if(read != -1)
{/* process the bytes received */}
else done = true;
}

No blocking, no fiddling with delays between reads, and the thread will
block on InputStream.read() until data is returned.

 

[Boki]

Very good, it works!

btw, nit-pick, it seems that the max incoming data block/packet is 4096
bytes, right?

or I have to check that first?

Best regards,
Boki.

You need a time delay after a getAvailable() == 0 since if you ask
right awy there will will rarely be anything for a good many
iterations, and you are just gobbling CPU time.

You don't need a delay if you ask for data in discrete packets rather than
asking for one byte at a time:

byte[] buffer = new byte[4096];
boolean done = false;

while(!done)
{
int read = istream.read(buffer);
if(read != -1)
{/* process the bytes received */}
else done = true;
}

No blocking, no fiddling with delays between reads, and the thread will
block on InputStream.read() until data is returned.

 

[Boki]

I don't know why,

sometimes, it can't work again...

still be blocked again, my final "read " == 22 ( not -1 ), and then be
blocked.

Does it possible the K750i's problem?

Best regards,
Boki.

Very good, it works!

btw, nit-pick, it seems that the max incoming data block/packet is 4096
bytes, right?

or I have to check that first?

Best regards,
Boki.

You need a time delay after a getAvailable() == 0 since if you ask
right awy there will will rarely be anything for a good many
iterations, and you are just gobbling CPU time.

You don't need a delay if you ask for data in discrete packets rather
than asking for one byte at a time:

byte[] buffer = new byte[4096];
boolean done = false;

while(!done)
{
int read = istream.read(buffer);
if(read != -1)
{/* process the bytes received */}
else done = true;
}

No blocking, no fiddling with delays between reads, and the thread will
block on InputStream.read() until data is returned.

 

[Roedy Green]

btw, nit-pick, it seems that the max incoming data block/packet is 4096
bytes, right?

or I have to check that first?

No. Read just reads a buffer full. It looks at the length of the
buffer you give it to know the max you are willing to accept. You may
get less, but you won't get more. You don't have to worry about an
index out of bounds exception.

 

[Boki]

Hi Green,
I don't know why, it can't work now..

===========================
while ( !done )
{
gui.repaint();

bytesToRead = in.available();
if (bytesToRead > 0 )
{
nbrOfBytesRead = in.read(byteBuffer);

if ( nbrOfBytesRead == -1 ) done = true ;

for (count_jpg=0;count_jpg<nbrOfBytesRead;count_jpg++)
{
imageData[GUI.ggg+count_jpg]=byteBuffer[count_jpg];
}
GUI.ggg+=nbrOfBytesRead;
}
else if ( GUI.ggg>0 ) done=true;
}
========================
The program still be blocked, never exit the while loop even I stop the data
transfer a while already...

Best regards,
Boki.

 

[Roedy Green]

still be blocked again, my final "read " == 22 ( not -1 ), and then be
blocked.

My readBlocking code has been posted a long time. I have used
successfully without incident. I suspect it works. Just use it
verbatim.

 

[Roedy Green]

if ( nbrOfBytesRead == -1 ) done = true ;

you also want to break out of the look at that point.

In that case, you don't need a done boolean.

 

[Darryl L. Pierce]

Very good, it works!

btw, nit-pick, it seems that the max incoming data block/packet is 4096
bytes, right?

or I have to check that first?

The code receives at most 4096 bytes *each time* it reads from the input
stream. There's no limit on the size that it will read, it will just do
it in discrete packets of 4096 bytes. If there is less than that
remaining in the input stream, it will read what's remaining and return.

 

[Darryl L. Pierce]

I don't know why,

sometimes, it can't work again...

still be blocked again, my final "read " == 22 ( not -1 ), and then be
blocked.

Does it possible the K750i's problem?

The final read() returns 22 because it read 22 bytes from the input
stream. It seems the handset might not be returning -1 (which it should)
and is instead blocking waiting for more data when none is available. A
change to the code like this should get past it, assuming you know the
total size of the incoming data stream:

int length = connection.getLength();
byte[] buffer = new byte[4096];
boolean done = false;
int totalread = 0;

while(!done && totalread < length)
{
int read = istream.read(buffer);
if(read != -1)
{
totalread += length;
/* process the bytes received */
}
else done = true;
}

 

[Darryl L. Pierce]

My readBlocking code has been posted a long time. I have used
successfully without incident. I suspect it works. Just use it
verbatim.

He's referring to the code I posted in the message to which he was
replying...

 

[Boki]

Thanks, but I don't know the data length.. because user will send a jpg file
....

Best regards,
Boki.

I don't know why,

sometimes, it can't work again...

still be blocked again, my final "read " == 22 ( not -1 ), and then be
blocked.

Does it possible the K750i's problem?

The final read() returns 22 because it read 22 bytes from the input
stream. It seems the handset might not be returning -1 (which it should)
and is instead blocking waiting for more data when none is available. A
change to the code like this should get past it, assuming you know the
total size of the incoming data stream:

int length = connection.getLength();
byte[] buffer = new byte[4096];
boolean done = false;
int totalread = 0;

while(!done && totalread < length)
{
int read = istream.read(buffer);
if(read != -1)
{
totalread += length;
/* process the bytes received */
}
else done = true;
}

 

[Roedy Green]

Thanks, but I don't know the data length.. because user will send a jpg file
...

Re-read what I have already given about sockets, http, and
readBlocking.

The practical answer if you stay baffled in to get the guy written the
server code to give you the length both in the http header and just
ahead of the jpg image.

 

[Darryl L. Pierce]

Thanks, but I don't know the data length.. because user will send a jpg file

You're writing the code to send the image, aren't you? Then encode the
length in bytes of the image and send that first.

 

[bokiteam]

got you~ : )

Best regards,
Boki.

 

[bokiteam]

no, due to the image is coming from cmos sensor part, I will not
control that part of code.

I have already requested it, and they will support that.


Best regards,
Boki.