You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when a text frame is received, ReadingThread automatically converts this to a UTF8 String. This is obviously expected behaviour for most use cases, but in my use case I'll immediately parse this information using a library which will call String.getBytes().
That's a lot of un-necessary work, which can be entirely avoided by receiving the byte[] directly.
I have hacked ReadingThread.callOnTextMessage(byte[] data) myself to call ReadingThread.onBinaryMessage(byte[]) to bypass the string allocation, however it would be great if there was a standard mechanism to directly obtain the byte[] when it's a text message.
(Thanks for a great library by the way!)
The text was updated successfully, but these errors were encountered:
Released nv-websocket-client 2.6 including the feature described below.
Direct Text Message
When a text message was received, onTextMessage(WebSocket, String) is called. The implementation internally converts the byte array of the text message into a String object before calling the listener method. If you want to receive the byte array directly without the string conversion, call setDirectTextMessage(boolean) with true, and onTextMessage(WebSocket, byte[]) will be called instead.
// Receive text messages without string conversion.ws.setDirectTextMessage(true);
Currently, when a text frame is received, ReadingThread automatically converts this to a UTF8 String. This is obviously expected behaviour for most use cases, but in my use case I'll immediately parse this information using a library which will call
String.getBytes()
.That's a lot of un-necessary work, which can be entirely avoided by receiving the byte[] directly.
I have hacked
ReadingThread.callOnTextMessage(byte[] data)
myself to callReadingThread.onBinaryMessage(byte[])
to bypass the string allocation, however it would be great if there was a standard mechanism to directly obtain the byte[] when it's a text message.(Thanks for a great library by the way!)
The text was updated successfully, but these errors were encountered: