feat: decouple useAudioRecorder hook of waveform component

[DanielFRico]

Closes: #167
Highlight:

• First of all the hook useAudioRecorder is a hook that does not have any life cycle state, so its exported functions are "isolate" of its implementations or consumers life cycle in this case Waveform component. That fact made decouple process was easier than expected. Now, in other side, to make a good decouple was necessary to move onCurrentRecordingWaveformData listener from useAudioPlayer to useAudioRecorder and to move recorderState from Waveform component to useAudioRecorder and return this variable in hook. Those changes do not affect any already existing implementations and I made test using example app to verify everything continues working and a different test project to test use of useAudioRecorder without Waveform component and worked also. Let me know if you have any doubts or suggestions!

[kuldip-simform]

@DanielFRico Thanks for putting together this PR! I really like the approach you’ve taken here—it makes a lot of sense.

We’re currently discussing internally whether it would be a good idea to apply the same approach to player methods as well. Just want to make sure we’re covering all cases before making a decision to go with this approach.

We’ll test this out and let you know if any tweaks are needed. Appreciate your effort on this!

[DanielFRico]

@DanielFRico Thanks for putting together this PR! I really like the approach you’ve taken here—it makes a lot of sense.

We’re currently discussing internally whether it would be a good idea to apply the same approach to player methods as well. Just want to make sure we’re covering all cases before making a decision to go with this approach.

We’ll test this out and let you know if any tweaks are needed. Appreciate your effort on this!

Nice. @kuldip-simform I remain attentive to your comments!

[kuldip-simform]

@DanielFRico
We truly appreciate the effort you’ve put into this PR—it aligns well with our vision for improving the library.

After further discussion, we believe this approach can significantly enhance our library and expand its usability across different scenarios, ultimately helping us reach a broader user base. To ensure robustness, we need to guarantee that these methods work independently, in any order, and that they properly handle errors if something is executed out of sequence.

For the sake of feature parity, we also want to apply the hook-based approach to player functions. However, this requires careful planning and extensive testing to ensure we don’t introduce regressions. Since these functions are critical, there’s potential for crashes or unpredictable behaviors if they are called out of order. We want to take the necessary time to refine the implementation and deliver the best possible experience to our users.

With that in mind, we’ll keep this PR open for now. We plan to introduce this new feature as part of a dedicated feature branch, where we will consolidate all related changes before releasing a major version update. This approach will allow us to maintain stability while rolling out these improvements in a controlled manner.

Once again, we appreciate your contribution and the thoughtfulness behind your implementation. If you’re interested, we’d love to have you involved in refining and testing this further. Your insights and contributions are always welcome, and we’re grateful for your support in making this library even better!

Thanks again, and we’ll keep you updated as we make progress.