Run Participants and Collaboration in Flutter

Build participant controls and shared activities with mediasfu_sdk 2.3.0: waiting and requests, moderation and co-hosts, messages, polls, breakouts, whiteboard, and recording.

Complete the Flutter room lifecycle first. Keep room authority and account credentials on your backend.

Start with the supplied Flutter room

Use MediasfuGeneric for the first release. It connects the participant, waiting, request, co-host, message, poll, breakout, whiteboard, and recording workspaces to one current room state.

For a custom Flutter shell, the root package exports these widgets:

import 'package:mediasfu_sdk/mediasfu_sdk.dart';

// Add the workspace needed by your current room UI.
const workspaceTypes = <Type>[
  ParticipantsModal,
  WaitingRoomModal,
  RequestsModal,
  CoHostModal,
  MessagesModal,
  PollModal,
  BreakoutRoomsModal,
  ConfigureWhiteboardModal,
  RecordingModal,
];

These widgets require their own current-room option objects. Prefer the supplied room until your custom renderer already owns those complete options. The root import does not currently offer a complete low-level contract for every action, so do not guess missing fields or depend on undocumented imports.

Participant authority

Remove and ban are different actions

ParticipantsModal can remove a person from the current room. That action does not set the room's ban flag. When an authorized moderation flow really means Ban, Flutter 2.3.0 also provides confirmExit with ban: true. MediaSFU then rejects a later join that uses the same banned room identity.

Make usernames stable and unique for authenticated accounts. If people can choose a different name on every join, a username-based ban can be evaded. Use Remove from room for a one-time disconnect and Ban from room only for the explicit ban action.

The ban helper is an explicit package-module import rather than a root-barrel export:

import 'package:mediasfu_sdk/methods/exit_methods/confirm_exit.dart';
import 'package:socket_io_client/socket_io_client.dart' as io;

Future<void> banFromRoom({
  required io.Socket roomSocket,
  io.Socket? localRoomSocket,
  required String username,
  required String roomName,
}) =>
    confirmExit(ConfirmExitOptions(
      socket: roomSocket,
      localSocket: localRoomSocket,
      member: username,
      roomName: roomName,
      ban: true,
    ));

Pass the sockets owned by the active MediaSFU room. Enable this action only for a role your application allows to ban participants, and confirm the result from room state before changing the UI.

• WaitingRoomModal admits or rejects waiting people.
• RequestsModal accepts or rejects the current media or room request.
• ParticipantsModal supplies mute and remove actions.
• CoHostModal assigns a co-host and responsibilities.

Only show authority controls for the current room role. Confirm the result from current room state, not from a dismissed dialog or locally removed card.

Action	Observable success	Recovery
Admit or reject	The waiting entry disappears and the person joins or receives rejection.	Keep it pending until the room changes.
Approve or deny request	The request closes and the affected participant receives the result.	Restore the current request after connection or authority failure.
Mute or remove	The affected participant and remaining clients receive the state.	Never hide a participant locally to simulate success.
Assign co-host	The target's responsibilities and controls change.	Keep the previous role if the room does not confirm it.

Keep panelist and permission actions inside the supplied room. The root import does not currently offer a complete standalone contract for these actions. CoHostModal is a co-host workspace, not a general-purpose role editor.

Messages and polls

Use MessagesModal for room and direct messages. Keep the recipient visible, preserve an unsent draft according to your privacy policy, and wait for current message state before showing success.

Use PollModal for create, vote, results, and end. Let the supplied poll workspace construct each action. Disable repeated taps while an action is pending, and refresh the current poll after reconnection.

Breakouts and whiteboard

Use BreakoutRoomsModal to review assignments, handle unassigned people, start or update the session, confirm every destination, and stop it before clearing drafts. Navigation is part of the room's breakout state: show the destination only after it is confirmed, and return people to the main room only after the stop result is reflected. Reload current breakout state after reconnect.

Use ConfigureWhiteboardModal and Whiteboard for the shared board. Confirm a second participant receives changes. Stop the room whiteboard before clearing app-owned drawing tools or temporary exports.

For screen annotation, use the supplied whiteboard or screenboard workspace only when your current room options expose it. The root package does not publish a complete standalone annotation command contract, so do not invent one from a local canvas.

Recording and product policy

Use RecordingModal, startRecording, and stopRecording for the package recording lifecycle. Show recording as active or stopped only after current room state confirms it.

The Flutter package does not supply product consent capture, storage-destination selection, retention, access, export, or deletion policy. Your application must show consent before start and your backend must enforce storage and lifecycle policy. Do not treat the recording configuration confirmation as participant consent.

Mobile recovery and cleanup

Test background and foreground transitions, audio-route changes, rotation, permission changes, and network handoff. After reconnect, reload current room state and never replay an interrupted action automatically.

On leave, removal, or meeting end, close workspaces and clear app-owned selections, pending actions, drafts, timers, temporary exports, listeners, and room authority. Keep participant leave, removal, and host-ended meeting states distinct.

Release checklist

• Test host, co-host, and participant devices separately.
• Admit, reject, approve, deny, mute, remove, and assign co-host.
• Send room and direct messages to the intended recipients.
• Create, vote, and end a poll without duplicate taps.
• Start and stop breakouts; confirm every destination.
• Start, use, and stop a whiteboard with two devices.
• Start and stop recording with consent and retention behavior visible.
• Background and restore during pending actions without replay.
• Verify workspaces, drafts, media, listeners, and authority clear on exit.

Run flutter analyze and flutter test with your approved 2.3.0 package source, then complete this checklist on each release platform.