Components
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 Recorder
interface.
#
RecorderControllerA 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
SavedStateHandle
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 bind
methods
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.
#
RecorderFragmentThe 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
the RecorderOptions
class:
#
RecorderViewThe 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 bind()
to use it. For example: