client-sdk-android
                                
                                 client-sdk-android copied to clipboard
                                
                                    client-sdk-android copied to clipboard
                            
                            
                            
                        receive RoomEvent.DataReceived, participant parameter is null
excuse me,
In my understanding, I think that as long as someone is in the room, he should be a participant, then the participant in the room calls publishData(), and other people in the room receive the RoomEvent.DataReceived event At this time, the participant parameter should not be null.
From this understanding, then I have a problem,eg:
Two people need to talk (assume it is A and B), where A first uses room.connect() to successfully enter the room and uses setCameraEnabled(true) to push the stream.
B waited for a while before entering the room (it can be sure to enter successfully), at the moment of successfully connecting to the room or very quickly using publishData() to send a message to the room, at this time A received the event DataReceived, But the participant parameter is null.
Note what I mean: quickly, instantly.
If B waits 30s - 1m after entering the room before using publishData(), there will be no problem, the DataReceived event carries the participant parameter.
In theory, DataReceived can be received, which proves that both A and B are in the room, why participant parameter is null?
In the above example, B did not push the stream (meaning that the two methods setMicrophoneEnabled(true) and setCameraEnabled(true) were not called)
but immediately called LocalParticipant.publishData API at the moment of entering the room, or within 1 second` will have this kind of problem
if there is a problem with the connection, then publishData() should not succeed, is it that publishData() has nothing to do with the connection,is it using other methods alone?
Looks like there's a race condition where the data packet comes in before the connection is finished processing the join response. I'll look into fixing this.