Home/ Questions/Q 366325
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T13:37:19+00:00

I am currently writing an app on the Blackberry to do a simple send

  • 0

I am currently writing an app on the Blackberry to do a simple send and receive of some raw data to another TCP based device on my network. I am having the same problem in the Blackberry simulator w/ an MDS simulator running and using a physical phone talking to my company’s MDS server. Note this problem does not happen when using wifi directly and not via MDS.

The problem is that the available() function on the InputStream returns zero unless I call read() first. If I call read first (knowing there is some data available .. thank you wireshark) the data comes back, and the subsequent call to available() indicates what data is left that I did not read. The problem is that I am not always going to be guaranteed that data will be there and so I could block. Is anyone aware of this, and is this a problem or something that is by design?

Is anyone aware of a way to test if the read() method(s) will block before calling them aside from available?

Here is basically what I am doing:

SocketConnection s = (SocketConnection)Connector.open("socket://1.2.3.4:port;deviceside=false", Connector.READ_WRITE);

OutputStream o = ((StreamConnection)s).openOutputStream();
InputStream i = ((StreamConnection)s).openInputStream();

o.write("hello");
Thread.sleep(sometime);
if (i.available() > 0) {
   byte[] data = new data[10];
   int bytesRead = i.read(data);
   System.out.println("Read [" + new String(data) + "] (bytes = " + bytesRead + ")");
}

I have to comment out the if conditional for this to work.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    As I indicated in a comment above, I needed a way to determine if a device I am connecting to is not there, and I do that by seeing if our ‘ping’ returns any data. If the device is not there it will block. I cannot rely on that behavior. Another issue that crept up while solving this is that the read(…) methods of the RIM InputStream class block if you provide a buffer bigger than the data you want back. But how am I supposed to know how much data is there if available() returns 0? Reading byte-by-byte is about the only way to do this, but it still blocks if there is no data.

    To address this I followed the theme of the 1st answer, but I put this method on its own thread and had it write to a separate byte buffer. I created a class that extended InputStream and implemented available() and read(…). Available returns how many bytes are in the byte buffer, and read only gives back however much is in the buffer or however much the caller requests, whichever is less.

    This setup lets me use an InputStream interface, but behind the scenes it is just a continuously running reader thread that is alive until the connection is dropped. At that time the read, if blocked, will throw an exception to indicate the connection closed. This behavior is fine as it can be easily handled.

    Thanks to all above who helped with this issue. Your thoughts help move towards the solution.

    • 0