Use a custom UI when a meeting has a waiting room. Callback order 1. DestructionZoomMeetingVC 2. OnInitMeetingView.
Hi @15604510000,
Thanks for the post. Could you elaborate on the issue you are facing? Could you provide the following information?
Description
A clear and concise description of what the question is.
Which version?
Knowing the version can help us to identify your issue faster.
To Reproduce(If applicable)
Steps to reproduce the behavior:
- Go to ‘…’
- Click on ‘…’
- Scroll down to ‘…’
- See error
Screenshots
If applicable, add screenshots to help explain your problem.
Smartphone (please complete the following information):
- Device: [e.g. iPhone6]
- OS: [e.g. iOS8.1]
- Version [e.g. 22]
Additional context
Add any other context about the problem here.
Thanks!
Waiting room callback sequence problem
The first is a custom UI that shows the waiting room interface when you join a meeting with a waiting room. Upon the moderator’s agreement, DestructionZoomMeetingVC will receive a callback that will lead me to believe that the meeting is closed. How can I do agree to join the meeting not to go DestructionZoomMeetingVC but to directly inform me of the status of the waiting room to send changes. I handle the UI myself.
Current version 4.6.21666.0428.
IPhoneX, iOS13.0
I am having the same issue.
I am using v5.4.54520.1229
When the waiting room is enabled, the sequence of events is.
Connecting
Reconnecting
Meeting Ended
Connecting
WaitingFor Host
Connecting
InWaitingRoom
Connecting
Reconnecting
InMeeting
This clearly seems like a bug because when our business logic sees Meeting Ended we simply cleanup the UI but zoom is still trying to connect in the background
Hey @nitin1,
Thanks for using the dev forum!
This order of events also confused me, and I thought it was a bug as well. However, this is actually intended behavior. Under the hood, the waiting room is treated as a special type of meeting. So when the user is admitted to the waiting room a meeting technically ends (the waiting room), so that the user can join the actual meeting.
Thanks!
Michael
Hi Michael,
Thanks for you reply.
I understand it is the intended behavior however, the behavior is creating problems for us to maintain a consistent state in the application layer. I will try to explain with the help of example
- When the user is allowed to enter the meeting (with waiting room enabled)
onMeetingStateChange:1
onMeetingStateChange:1
onMeetingStateChange:1
**onMeetingStateChange:11 [**MobileRTCMeetingState_InWaitingRoom] - In waiting room callback - true
**onMeetingStateChange:11 [**MobileRTCMeetingState_InWaitingRoom]
**onMeetingStateChange:11 [**MobileRTCMeetingState_InWaitingRoom]
onMeetingStateChange:1 [MobileRTCMeetingState_Connecting] - In waiting room callback - false
onMeetingStateChange:5 [MobileRTCMeetingState_Reconnecting]
onMeetingStateChange:7 [MobileRTCMeetingState_Ended] <— Was I kicked out allowed in ??
onMeetingStateChange:1
onMeetingStateChange:1
onMeetingStateChange:3
onMeetingStateChange:4
onMeetingStateChange:1
onMeetingStateChange:7
- when the user is not allowed to join the meeting is
onMeetingStateChange:1
onMeetingStateChange:1
onMeetingStateChange:1
onMeetingStateChange:11 **[**MobileRTCMeetingState_InWaitingRoom] - In waiting room callback - true
onMeetingStateChange:11 **[**MobileRTCMeetingState_InWaitingRoom]
onMeetingStateChange:11 **[**MobileRTCMeetingState_InWaitingRoom]
onMeetingStateChange:4 [MobileRTCMeetingState_Disconnecting] - In waiting room callback - false
onMeetingStateChange:1 [MobileRTCMeetingState_Connecting]
onMeetingStateChange:7 [MobileRTCMeetingState_Ended] <— Was I kicked out allowed in ??
So when MobileRTCMeetingState_Ended comes, unless I track all the sequence of states the system has gone through, I won’t know if the meeting ended because I will rejoin or meeting ended because the user was not allowed to join. Also, I have seen scenarios where we do get re-connecting when the user is waiting in the room for 2-3 minutes.
As you can see this is making things unduly complicated. I have a solution if you tell me the sequence is correct and will be the same in this case no matter what the scenario. I have created a state machine for Zoom teams review, to make sure I am not missing anything.
Your help is much appreciated
Regards
Nitin
Hey @nitin1,
I understand that this can start a strange loop of state handling. To help with this scenario there are callbacks specifically related to entering or leaving the waiting room:
onWaitingRoomStatusChange: ← For handling when the user has entered a waiting room or left a waiting room
onJBHWaitingWithCmd: ← For handling the waiting room in the situation where the user joined before the host
There is also the callback
onMeetingEndedReason: ← Provides the reason the meeting was ended.
Thanks!
Michael
Thanks Michael,
I could not find documentation for MobileRTCMeetingEndReason
Also, does this callback comes before or after the meeting has ended?
Best
Hey @nitin1,
It will come very shortly after. So if the host pressed “End meeting” the callback will be triggered right after for all the participants.
Thanks!
Michael
So basically, the flow I created is the only way it works for now. Just making sure. This was working for us earlier. After the latest SDK update it appears the sequence has changed a bit more than what it used t be in the past.
Thanks
Hey @nitin1,
What was the behavior you experienced prior to this version? I don’t think there were intentional changes around this area of the SDK, but I can follow up.
Thanks!
Michael
So, I had been doing some research at my end and clearly this part of the SDK needs to be more resilient and developer friendly. The diagram I shared earlier is what i am following to ensure that the users who have been approved can move into the meeting but it is too complicated. Given the only difference between checking if you were approved or not was getting a reconnecting event. The reason it becomes so messy is that I also got reconnecting when I switched between wifi and cellular. So there are definitely scenarios where the diagram I made above is not fool proof.