We provide three base
Recorder implementations that you can choose from depending on your case.
Using them is a bit different but they all share the same functionality from the
RecorderController is the low level implementation that, unlike the others, is detached from
the UI. You will typically hold the controller instance in a ViewModel. Optionally,
for perfect state restoration during configuration changes, we also recommend that you use Android's
and pass it to the controller constructor.
As you can see, the
RecorderController must be released when you're done with it.
In order to show the UI and start using the recorder, you must also call one of the
as soon as you have a view container. For example, with a fragment:
By passing in the fragment instance, the controller will use the fragment lifecycle to avoid memory leaks, so that there's no need to unbind.
RecorderFragment is a fragment implemented exactly as described above. It is
the recommended implementation as it is very easy to use - no need to release or bind UI,
because the fragment owns the views.
You can customize the fragment after it is attached or when creating it, thanks to
RecorderView is a view that holds a controller, to be used for codebases that do not use
fragments at all. Just like the controller, you must pass a fragment / activity / lifecycle with
to use it.