When you build a solid broadcasting app there are a few behaviors to consider.
If you lock the screen during a broadcast, the capture session - and hence the broadcast - ends, in most situations.
This means disabling auto-lock is desired in most broadcasting apps.
Most multi-user apps with broadcast consumption, need some form of backend that decides what content to show to which users when.
To detect new broadcasts, your backend can poll the broadcast API
in a tight loop. The
live=true parameter can be quite handy in this situation.
An alternative / complementary workflow: the iOS and Android SDKs provide a callback which fires once the broadcast is fully established, and includes an id which your backend can use to fetch metadata.
For apps where a list of live broadcasts are shown to other users, it is often also important to keep track of when a broadcast transitions from being live to being archived.
In the normal case, the user presses a button in your app to end the broadcast, and the broadcasting library provides a callback which you can forward to your backend to pick up the new state quickly.
But there are other ways a broadcast might end:
Put simply, the broadcasting phone can't reliably notify your backend in these scenarios.
Polling the broadcast API in a tight loop using the
live=true parameter is a robust way to ensure your backend's state covers these situations.