fix: audio recording variety bugs

[isekovanic]

🎯 Goal

This PR addresses the issues mentioned in this Github issue. In addition to this, it also takes care of a variety of additional bugs and odd behaviours I found with async audio recording in particular.

🛠 Implementation details

Provided below is a list of the things it fixes.

General (all platforms):

• When letting go of the recording button while below both the threshold for locking and canceling, the recording is sent to the chat as an available attachment
  • I wasn't too sure if this is the behaviour we want, but it seems a lot more intuitive than having the recording stuck in a weird state so it made sense
  • The difference between locking and doing it like this is that this is the "quick way" to send an audio recording whereas the lock is more of an "advanced view"
• Audio recording would not stop if we navigate away from the screen where it got triggered (where <MessageList /> is present for example)
• Simply clicking on the recording button instead of doing a long press would sometimes cause issues and would not display the Hold to start Recording message
  • Took the chance here to move to the new Gesture API since it seems a lot more stable and has quite a few more options

Vanilla React Native:

• Whenever opening the app for the first time and being asked for permissions, clicking "Accept" would cause the app to be stuck in an irrecoverable state of recording until we completely unmount the AudioRecorder twice
  • The behaviour of starting recording automatically after we've accepted on the permissions dialog is still there (it's actually not trivial to skip this, since a lot of intertwined state is causing it) but now we can safely take over the controls again by doing a long press on the recording button and either cancel the recording, open the microphone locked view or simply do a quick send of it
• If permissions were specifically denied, pressing the recording button twice in a row would cause the audio player to start the recording process in the background but not actually record, setting the AudioRecorder in an unrecoverable state (either unmounting or killing the app entirely would be the only thing that fixes this)
  • This is a bug with the underlying library we're using that's well documented here; feel free to read my comment for more details about our specific usecase

Expo:

• There was an issue with the expo-av library that occurs immediately after accepting permissions if we run Recording.createAsync() too quickly before the JS thread taking control again
  • Recording would fail and we would immediately get the message that we haven't provided permissions, despite the fact that we just did (this is a side-effect of the recording erroring out on the expo-av side)
  • The issue is well documented here
• A slight optimization whenever permission has been declined where we now exit early instead of proceeding with the process again

🎨 UI Changes

iOS

Before	After

Android

Before	After

🧪 Testing

☑️ Checklist

• [x] I have signed the Stream CLA (required)
• [x] PR targets the develop branch
• [ ] Documentation is updated
• [x] New code is tested in main example apps, including all possible scenarios
  • [x] SampleApp iOS and Android
  • [x] Expo iOS and Android

[Stream-SDK-Bot]

SDK Size

title	develop	branch	diff	status
js_bundle_size	438.6728515625 KB	439 KB	0 B	🟢

[khushal87]

I see that we show the AudioRecordingWaveform component even when the mic is not locked. I think this is not supposed to be done.

[isekovanic]

I see that we show the AudioRecordingWaveform component even when the mic is not locked. I think this is not supposed to be done.

Oh, great catch ! This one kind of slipped my mind. Thanks, will fix it in a sec !

[stream-ci-bot]

:tada: This PR is included in version 5.36.1 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: