fix(android): promises leak caused by player not in the HashMap

[dprevost-LMI]

After calling stopAllPlayers, if we call some Android native function and the player is not in the HashMap, multiple functions will forget to reject the promise and end up with promise leaks. This is affecting startPlayer, pausePlayer, seekToPlayer, setVolume, getDuration

Below is an example where the console log after await AudioWaveform.startPlayer never shows since the call leaked the promise
STR:

• Start a player
• Pause de player
• Call useAudioPlayer.stopAllPlayers()
• Start the the player again
• The useAudioPlayer.startPlayer() never returns

Once the promise is rejected correctly, the error is propagated to the JS correctly, proof:

[dprevost-LMI]

Do I need to enter a ticket for this PR, or can we merge it as it is?

[nilesh-simform]

Hi @dprevost-LMI

We need to manage the seekTo function with a try-catch block because we do not initialize the player until the user starts playing. Therefore, when the user attempts to seek before the player is initialized, it will reject the promise.

To handle this, Please add the necessary changes here as shown below.

const seekToPlayerAction = async () => {
   if (!isNil(seekPosition)) {
     if (mode === 'static') {
       const seekAmount =
         (seekPosition?.pageX - (viewLayout?.x ?? 0)) /
         (viewLayout?.width ?? 1);
       const clampedSeekAmount = clamp(seekAmount, 0, 1);

       if (!panMoving) {
         try {
           await seekToPlayer({
             playerKey: `PlayerFor${path}`,
             progress: clampedSeekAmount * songDuration,
           });
         } catch (e) {}

         if (playerState === PlayerState.playing) {
           startPlayerAction();
         }
       }

       setCurrentProgress(clampedSeekAmount * songDuration);
     }
   }
 };

 useEffect(() => {
   seekToPlayerAction();
   // eslint-disable-next-line react-hooks/exhaustive-deps
 }, [seekPosition, panMoving, mode, songDuration]);

[dprevost-LMI]

@nilesh-simform I used what you proposed coupled with await stopPlayerAction() in the catch. It could be a more elegant fix, but it at least auto-corrects the player so that it works on the next play-action.
I repeat the fix when startPlayerAction() also throws an error. It unblocks the user on the second play attempt.

I'm sure there is a better fix for that, but at least this will unblock the user, and later on, it can be fixed better.

[kuldip-simform]

Closing this in favour of #138