Reference Applications

In general, it is much easier to program to the high-level API calls. As such, we have provided reference applications for each platform to demonstrate how a given user interface can utilize these calls to produce a simple meeting application. Given that the APIs on each platform are slightly different, we will present a general flow description here for what an application written against the high-level API calls will do. Please consult the source code (and any platform-specific documentation) for more precise information on how to implement this flow on the platform you are developing for.

When creating a "meeting" application, you will always follow this general flow:

Your platform may require an SDK initialization step. Once that step is completed, you will need to "register" your callback methods (be they in the form of a Java interface implementation, a MacOS/iOS delegate class implementation or a series of C#/.Net delegates) so that the SDK will know what methods to call when certain meeting related events occur.

Once your SDK is initialized and your callbacks/delegates are registered, you may begin the process of joining a meeting by first initializing a meeting (you will need to specify a server IP or DNS name along with a UUID for the meeting) and then joining the meeting. These two operations should be "chained" – meaning that when you know the initialization succeeded (usually in the form of an asynchronous callback/completion routine) you may proceed to issue the API call that joins the meeting.

Once you've joined the meeting, you will begin seeing your callbacks/delegates invoked when various meeting events occur. We'll explore these (and how you should respond) in the table below. As long as you are "in the meeting" you can receive any number of callbacks (such as when new users join the meeting, when video is available, when users mute their audio, etc.). This"stage" is where the majority of your programming work will be directed.

Finally, at any point during the meeting you may choose to exit the meeting with the appropriate API call. Once you exit the meeting you are free to initialize and join another meeting (or ask to join the meeting you just left again)

Responding to Callbacks/Delegates

As mentioned above, once you have joined a meeting successfully, you will begin to receive meeting events through the invocation of your callbacks/delegates. The table below provides general guidance on how to respond in each case. The majority of these callbacks/delegates will be passed a Participant model object as an argument. Please consult your platform's reference app and/or any platform specific documentation for more details as needed.

Callback/Delegate Name	Description/Action to Take
participantAdded	Called when the SDK receives either an audio or video event for a participant not seen yet. The Participant object received may only have audio or video information. When you receive this event, you should assume you have a new participant in the meeting. The SDK maintains a list of Participant model objects, so you do not have to. You are able to query the list of current participants in the meeting at any given time.
participantVideoAdded	Called when a new video stream is detected in the meeting for a known Participant. A participant can have multiple video streams in the meeting (if they've activated multiple cameras and/or screen shares from their device). You will receive a separate participantVideoAdded call for each video stream associated with a participant. When this method is called you will usually ask the SDK to enable the video stream immediately (which will cause the SDK to generate a user interface object that contains the video)
participantVideoUpdated	Called when metadata associated with a given video stream has changed. Metadata includes (but is not limited to) height, width, username, device name and stream resolution. Consult your platform's specific reference app for more information on the type of action you may need to take when this method is called.
participantVideoViewCreated	Called when a video stream has been enabled and is ready to be displayed. One of the arguments to this method will be a user interface object that can be integrated into your user interface.
participantVideoRemoved	Called whenever a video stream has been removed from a meeting. This could be because a participant has exited the meeting OR if a participant has stopped sending video into the meeting from a given camera or screen share.
participantRemoved	Called when the SDK detects that a given participant has exited the meeting. If you have user interface element that lists all the participant, this is the time to remove this participant from that list.
participantDidMute	Called when a given participant stops sending audio up into the meeting. If you are showing a control that lets the user set the output level of a given participant in the meeting, you may want to gray it out or show some other icon/indicator that this participant's audio is muted.
participantDidUnmute	Called when a given participant resumes sending audio up into the meeting. If you are showing a control that lets the user set the output level of a given participant in the meeting, you will want to make sure it is active (if you had deactivated/disabled it when the participantDidMute method was called)
inputMeterChanged	Called when the SDK detect that the input level coming from the user running your program changes. This can be used to implement a "sound input level indicator" in your user interface.
outputMeterChanged	Called whenever the overall audio level coming from the meeting changes. Used if you have a "sound level indicator" in your user interface – in which case you'd take the level argument passed to this method and update your user sound level indicator. If you do not implement such a feature, you can ignore this call.
amplitude	Called whenever the SDK detects that the output level of an individual participant changes. This can be used to implement a "sound level indicator" for each individual participant in the meeting.

The table above does not reflect all the callbacks/delegates that are part of the SDK, but it does cover the common calls that you will likely want to implement.