You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:Just when writing that class I already was confused, since in the readme for
startPlay
it 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.
The text was updated successfully, but these errors were encountered: