Description
I use zoom sdk in my android app. I setup the meeting from zoom app with the feature “put in the waiting room”. I tried to listen to InMeetingServiceListener to see the ending reason.
When the the app is in waiting room, the host (using zoom app) admits the user (from android sdk), the InMeetingServiceListener throws the event onMeetingLeaveComplete with the meetingEndReason = 0. (meaning END_BY_SELF). I don’t know if it is an error, or it is your feature. But it’s kind of weird for me. Error
Bellow is the log I capture from MeetingServiceListener and InMeetingServiceListener
Meeting state is changed to MEETING_STATUS_CONNECTING error 0 internal error 0
Meeting state is changed to MEETING_STATUS_IN_WAITING_ROOM error 0 internal error 0
Meeting state is changed to MEETING_STATUS_RECONNECTING error 0 internal error 0
(I admit the user who is in the android sdk app in here)
onMeetingLeaveComplete zoomMeetingEndReason 0
Meeting state is changed to MEETING_STATUS_IDLE error 0 internal error 0
Meeting state is changed to MEETING_STATUS_CONNECTING error 0 internal error 0
Meeting state is changed to MEETING_STATUS_INMEETING error 0 internal error 0
Which Web Client SDK version?
Knowing the version can help us to identify your issue faster. [e.g. 1.9.0]
Device (please complete the following information):
The behavior you are observing is correct. When you are admitted to the main meeting from the waiting room, you are actually leaving one meeting instance in order to join the main meeting instance.
@jon.zoom So, how can I know the actual ending reason, because it returns the ending code is 0 (mean end by user), but actually the user does not do any thing. My expectation is the ending reason should be the other one. Or the event onMeetingLeaveComplete should not occur.
When you are admitted to the main meeting, you are actually leaving a meeting and joining the main meeting. If you need to differentiate between leaving the main meeting or leaving the waiting room, you can watch for whether or not you’ve seen the MEETING_STATUS_IN_WAITING_ROOM status.
Thanks, @jon.zoom. But if I am in the waiting room then I call leaveCurrentMeeting function, or the user click on end meeting button, it would be the same, right. I cannot know which one happened.
In both instances, there is a point in time at which the user is no longer connected to any meeting. The only difference will come from when the user joins the main meeting after a short delay. Can you provide some context around your use case so that I can see if there is another approach that could work for you?
In my case, if the call manually ended by user. My application will end another process. Let’s say the X process. So I look at the onMeetingLeaveComplete event to check the reason. First I check if the endReason == 0 (meaning END_BY_SELF), but still have the problem like I explained. Now, I probably solved the problem but don’t know if there is any case that goes out of my logic.
So I check the onMeetingStatusChanged event.
switch (zoomMeetingState) {
case MEETING_STATUS_IN_WAITING_ROOM:
meetingState = MyEnum.MEETING_STATE_IN_WAITING_ROOM;
break;
case MEETING_STATUS_RECONNECTING:
meetingState = MyEnum.MEETING_STATUS_RECONNECTING;
if (meetingState ==MyEnum.MEETING_STATE_IN_WAITING_ROOM) {
meetingState = MyEnum.MEETING_STATE_LEAVING_WAITING_ROOM;
}
break;
Then I check on the onMeetingLeaveComplete event and check if it is leaving the waiting, I will not end the X process.
if (meetingState == MyEnum.MEETING_STATE_LEAVING_WAITING_ROOM) {
Log.i(TAG, "Leave the waiting room, waiting to join in the main meeting");
return;
} else {
// check some other variables to end the xProcess
xProcess.finish();
}
That’s good to hear you found a potential workaround! Since there are a lot of possible meeting statuses, this approach could still be tricky to handle. A couple of edge cases I can think of off the top of my head are: 1. The user disconnects from the waiting room due to network connectivity issues and then reconnects to the waiting room, and 2. The user loses the meeting connection before attempting to join the main meeting but after leaving the waiting room.
I faced the same problem a while back. What I do is watch for MEETING_STATUS_DISCONNECTING to come through. If I see that, I set a flag for later so that when MEETING_STATUS_IDLE comes through I check to see if MEETING_STATUS_DISCONNECTING came through right before it. That way I can tell the difference between transitioning from waiting room to actual meeting and leaving the meeting completely. So far it’s continued to work well for me. Not sure if it helps, but thought I’d share.
Your best bet seems to be implementing some sort of state management in your app to handle this. The recommendation made by @vuzix_greg could also be helpful.
It is unlikely that there will be any changes to this flow, since it is a result of how the back end handles the waiting room.