UnigramDev/Unigram/record-session • a9d5872 • 9 files, +1363/-1157 Give a recording an owner The rec

UnigramDev/Unigram/record-session • a9d5872 • 9 files, +1363/-1157
Give a recording an owner

The record button held four things: the gesture, the state of the recording, the
capture engine, and the decision of what to do with the result. The engine was a
thread-static singleton every loaded button subscribed to, so a recording started
in one chat drove the state of every other chat and story composer on the thread,
and QuantumProcessed was a single field that whichever button loaded last took
over and the first to unload set back to null.

ChatRecordSession now owns the state and the engine, one per button, which is one
per chat. What is left in the button is the press-and-hold gesture and its own
visuals.

Seven booleans and an integer interface state become three named states. The
fourth one - locked, then stopped - was only reachable through StopRecording(false),
which nothing ever called, so it went out along with the tri-state stop that
neither sent nor discarded what it recorded. Cancel and Complete say which they
are.

Elapsed comes off a monotonic clock rather than DateTime.Now, freezes while
paused, and starts when the capture device is actually open rather than when the
button was pressed. The pause state is reset when a recording ends instead of
leaking into the next one, and the bar detaches from the button on unload.

Permissions go through MediaDevicePermissions, which is what calls already use,
so granting access no longer costs the first press: the old check asked
DeviceAccessInformation and then returned false regardless, leaving the prompt as
the only thing that press did.

MediaCapture.Failed ends the recording instead of only logging it, and a press
too short to record now says so.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram