This page covers only how to embed the whiteboard on Android. For how boards map to channels, when a whiteboard is destroyed, and how to sync the “who opened the whiteboard” state to others (SRTC doesn’t broadcast it automatically), see Whiteboard.
1. Where the whiteboard URL comes from
SRTC delivers the whiteboard URL when you successfully join a channel, through thewhiteBoard parameter of the RTCClientEvent.onJoinSucceed callback:
RTCClientEvent (or extend RTCClientSimpleEvent and override only the methods you need), and take the URL in the callback:
- The URL looks like
https://<api-domain>/white-board/?code=<session-credential>&device_type=2&.... Each person’s URL is different (codeis each user’s own session credential—one-time use, invalid after connecting), but they all point to the same board (the board ID is the channel name)—so don’t forward your URL to others.whiteBoardis normally not empty: the whiteboard is created automatically the first time someone enters, with no need to enable it in advance. If it’s empty, the line configuration is abnormal, and you shouldn’t open the page.
2. How to use it (load it in a WebView)
2.1 Required WebView configuration
2.2 Load the URL (append control parameters)
Append control parameters to the URL when loading:Parameters are joined with&, relying on the URL already having a query string (the address from thejoinChannelcallback already includes?code=...). Don’t add a second?, or all the parameters after it are swallowed.
These parameters only set the initial state. To change them during the call (showing/hiding the toolbar, taking away or giving back the pen), call the JS methods in 3.4; changing the URL without reloading has no effect.
2.3 Inject the JS Bridge
The whiteboard communicates with native code through a JS interface with the fixed nameAndroidInterface, which must be injected before loading:
2.4 Release
Release the WebView when the screen is destroyed:3. Interaction events and commands
There are four kinds of interaction: ① Native → whiteboard (URL parameters, initial values only), ② Whiteboard → native (JS Bridge), ③ Whiteboard calls into WebView system capabilities, and ④ Native → whiteboard (JS methods for dynamic control during the call).3.1 Native → whiteboard: URL control parameters
Passed through the URL query when loading (see 2.2) to control the whiteboard UI:3.2 Whiteboard → native: JS Bridge events
The interface object name is fixed asAndroidInterface; the whiteboard calls it as window.AndroidInterface.<method>(...).
Reference implementation for saving the image in
onExportImage:
3.3 Whiteboard calls into WebView system capabilities
Whiteboard features such as “Insert image” and “Upload image” trigger WebView system callbacks, which you need to handle inWebChromeClient:
Tip: the whiteboard has a size limit for images. We recommend compressing images before returning them (for example, to under 1 MB) to avoid upload failures with large images.
3.4 Native → whiteboard: dynamic control during the call
URL parameters take effect only when the page opens. To show/hide UI or take away/give back the pen during the call, useevaluateJavascript to call the methods the whiteboard attaches to window:
Hiding UI isn’t the same as disabling actions:setShowMenu/setShowToolUionly hide the interface; users can still draw with keyboard shortcuts and the context menu. To make “this person unable to draw”, you can only usesetReadonly.
The page-following rule for multi-page whiteboards is “whoever can draw turns the page, and everyone else follows”; read-only clients only follow and don’t broadcast. See SRTC · Whiteboard · Multi-page whiteboards. You don’t need to designate anyone as host.