Currently the callback is dynamic which can easily lead to errors at runtime instead of at compile time. It also requires the developer using this library to refer to the readme and copy strings into their codebase, instead of letting the type system handle it.
As an example, you could have a AudioCallback. AudioCallback could have an enum of the event type as one field, and T as the event data.
A different way of doing it could be to have individual callback functions, instead of one where the developer needs to check the type. Eg onRecordingStarted(RecordingStarted event).
This also goes for other parts of the API. Instead of startPlay taking a dynamic map, why not leverage the type system and take:
class StartPlayingArgs {
String fileId;
double position;
}Just when writing that class I already was confused, since in the readme for startPlay it mentions the params should be Map<String, String>, but in the table below it mentions position should be a double. Which is it? Let the type system handle it instead of the readme.
This doesn't even go into the fact that you lose autocomplete if you use dynamic, which also reduces the speed a dev can write code with the library.
Currently the callback is dynamic which can easily lead to errors at runtime instead of at compile time. It also requires the developer using this library to refer to the readme and copy strings into their codebase, instead of letting the type system handle it.
As an example, you could have a AudioCallback. AudioCallback could have an enum of the event type as one field, and T as the event data.
A different way of doing it could be to have individual callback functions, instead of one where the developer needs to check the type. Eg
onRecordingStarted(RecordingStarted event).This also goes for other parts of the API. Instead of
startPlaytaking a dynamic map, why not leverage the type system and take:Just when writing that class I already was confused, since in the readme for
startPlayit mentions the params should beMap<String, String>, but in the table below it mentions position should be adouble. Which is it? Let the type system handle it instead of the readme.This doesn't even go into the fact that you lose autocomplete if you use dynamic, which also reduces the speed a dev can write code with the library.