> > > We're wondering why you need polling access to the stream. > InputStream.available() is documented as not being very useful: > > I'm not sure why android's version of javadoc includes this passage. But from common sense - the available() method's efficiency depends etirely on the underlying implementation. And in case of network streams and bluetooth streams (which are BTW essentially the same nature) - data availability check is a common sence. Even .net's NetworkStream has its DataAvailable.
I mean yes, think I can workaround this by creating a separate thread and data queue (or using BeginRead), and essentially implementing my own buffering logic and available() check. But thats just another layer over the data stream abstraction - because network and bluetooth streams are for sure already contains internal queue/buffer. > In particular, is there a reason you don't want to use Stream.BeginRead() > or some other async mechanism? Why do you need polling? > > We need polling because our current interaction model is based on polling. > If there's a good need for polling, we're considering providing a `bool > DataAvailable(this Stream stream)` extension method (thus translating the > dubious `int` InputStream.available() return value into a `bool`, and this > mechanism could also check for NetworkStream and return > NetworkStream.DataAvailable), but before we provide this we'd like to know > how useful it actually is. > Think thats logical to provide access to the information underlying stream already has. I was just surprised abit that no direct api mapping was done here. I understand InputStream and IO.Stream are different, but still. I'll anyway do my own buffering to move forward and see how port works.
_______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
