04-13-2010 06:29 AM
Hi All,
I met problem when reading from the SharedInputStream on BlackBerry9000. The device has been updated to OS5.0
Here is my codes:
private void test() {
try{
String host = "socket://192.168.2.104:6000;interface=wifi";
StreamConnection ms_client = (StreamConnection) Connector.open(host);
if(ms_client == null){
System.out.println("TCP open error");
return;
}
InputStream is = ms_client.openInputStream();
SharedInputStream readAhead = SharedInputStream.getSharedInputStream(is);
int len;
byte[] data = new byte[1024];
while (-1 != (len = readAhead.read(data))){
System.out.println("len = "+len);
}
System.out.print("len = "+len);
System.out.println(" Exit test, close connection");
readAhead.close();
ms_client.close();
}
catch(Exception e)
{
System.out.println("Test connection Exception:"+e.getMessage());
}
}
I create a TCP server on PC monitoring port 6000. When the test code start running, the server creates the connection then send out data continuously, but my code always jump out the while() loop and print out
"len = -1 Exit test, close connection"
after reading for 1~4 times on BlackBerry9000. The same code runs fine(it can keep reading for a long time) on BlackBerry8320.
I tested that the directly reading from "InputStream is" works fine on BlackBerry9000&8320. But I want to read from SharedInputStream to create a LimitedRateStreamingSource.
Appreciate for your help!
04-13-2010 08:31 PM - edited 04-13-2010 08:31 PM
Does anybody meet the same problem with SharedInputStream on BlackBerry9000?
06-07-2010 02:52 AM
it seems that everywhere you open a subject like this one no one cares from RIM.
Quite frustrating as they have their own code sample and it fails as well...
How can someone provide a code sample and not upgrade it to work on future releases?
Cheers,
Ernani
06-07-2010 11:35 AM
I SharedInputStream must somehow internally store all the data it has read from the underlying input stream to make sure that another 'copy' of the shared input stream can read the data as well. I don't know how the SharedInputStream is implemented but I guess they are using a byte array to cache the data. What might happen is that the internal buffers are different for different OS versions. At some point if more data is read than the internal buffer the SharedInputStream should somehow stop reading more data (if not you will run out of memory).
Why do you need to use a SharedInputStream?
06-08-2010 02:46 AM
The buffered player demo uses this class from RIM api.
All code that relies on that logic or similar items using that while not -1 when reading a stream, either a ContentInputStream it all of the sudden breaks.
It wasn't breaking on 4.5 to 4.7 releases.
Very weird way to keep backward compatibility.
Cheers,
Ernani
09-07-2010 12:55 AM
Just simple dont use the the SharedInputStream. Just InputStream is fine
09-07-2010 02:38 AM
Do not check for -1 in while loop. Instead of it, you can use While(true) and then inside loop you can check for readAhead.available() and then break the loop accordingly.
Also, shared input stream creates internal buffer for storing data. If you start providing data to shared input stream then after some time it will run out of memory as you cant store unlimited data in shared input stream. To resolve this issue, probably you need to implement CircularByteBuffer and then manually manage the stream.
10-14-2010 05:12 PM
So what you are telling is that the code samples of Buffered Playback are resource restraining?
This is basically what is in the samples
It wiorks great with devices of OS 4, on OS5 and up it breaks.
Isn't that weird at all?
Cheers.
12-27-2010 07:44 AM
12-27-2010 07:45 AM