Solución:
Bien. Finalmente me di cuenta de eso por mi cuenta.
¿Cómo manejo el (Object... args) sobre el EVENT_CONNECT del oyente call¿método?
Aún no me he dado cuenta de eso. Pero estoy mirando.
¿Cuál es un buen conjunto mínimo de eventos que puedo implementar para estar informado sobre la conexión?
Estos tres métodos serían suficientes:
conectar : Se activa tras una conexión satisfactoria.
connect_error : Se activa tras un error de conexión.
connect_timeout : Se activa tras un tiempo de espera de conexión.
Fuente: Socket.io Docs
¿Cómo se supone que debo procesar el (Object... args) en un acuse de recibo emitido?
Así que estaba buscando en los documentos y encontré esto:
Servidor (app.js)
var io = require('socket.io')(80); io.on('connection', function (socket) { socket.on('ferret', function (name, fn) { fn('woot'); }); });Cliente
socket.on('connect', function () { // TIP: you can avoid listening on `connect` and listen on events directly too! socket.emit('ferret', 'tobi', function (data) { console.log(data); // data will be 'woot' }); });
Entonces, los argumentos serán los que el servidor envió como parámetro en la devolución de llamada. Así que así es como escribirías Java código de cliente para el código de servidor anterior:
public void call(Object... args) {
String response = (String)args[0]; //this will be woot
}
El parámetro también puede ser JSON o cualquiera de los tipos de datos admitidos en socket.io:
enviamos una cadena, pero también puede hacer datos JSON con el paquete org.json, ¡e incluso se admiten datos binarios!
No, en Android funciona así
la carga útil puede ser de JSONOBJECT / JSONArray
import com.github.nkzawa.socketio.client.Ack
socket.emit("EVENT_NAME", payload, Ack {
val ackData = it[0]
Logger.e(TAG, "ackData $ackData")
})
lado del servidor
socket.on('EVENT_NAME', (payload, callback) => {
callback("success");
});