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
It should be noted that we already have the Downloader class that can download a file with progress information.
A number of users have requested the ability to cache URL audio data so that subsequent playbacks are not delayed.
Currently the Track class has been designed to avoid the user having to manage any resources Sounds needs to internally allocate for a Track (e.g. cached for url data).
If a Track where to auotmatically cache the URL data then we would have to exposes a 'release' method on the Track class to allow users to indicate when we should clear the cache.
Whilst an out of the box caching experience sounds nice it does raise questions about exactly how it should be implemented and what the UI should look like when pre-caching audio.
QuickPlay is a good example as it doesn't have a UI so the user will simply not see/hear anything as the audio gets cached.
The ShadePlayer is also an issue because again we have no way to indicate via the UI that we are caching the data (this might not be true potentially the shades do have a method of playing directly from a URL).
Our own widget SoundPlayerUI already supports loading the URL data and reflecting the download progress in the UI (vai a percentage spinning progress indicator).
It feels like it might be better if we gave the user an explicit caching mechanism and they then build the UI to suite their purposes.
Internally we use Track._prepareStream to download URL data.
We could just expose this externally and then also expose Track._release. I'm not a big fan of this as the release method will suggest to users that they need to call release all of the time which isn't the case.
When you call cacheTrack it returns a stream which could be passed to a StreamBuilder to allow a user to build a widget that reflects the caching progress.
It should be noted that we already have the Downloader class that can download a file with progress information.
Thoughts?
The text was updated successfully, but these errors were encountered:
It should be noted that we already have the
Downloader
class that can download a file with progress information.A number of users have requested the ability to cache URL audio data so that subsequent playbacks are not delayed.
Currently the Track class has been designed to avoid the user having to manage any resources Sounds needs to internally allocate for a Track (e.g. cached for url data).
If a Track where to auotmatically cache the URL data then we would have to exposes a 'release' method on the Track class to allow users to indicate when we should clear the cache.
Whilst an out of the box caching experience sounds nice it does raise questions about exactly how it should be implemented and what the UI should look like when pre-caching audio.
QuickPlay is a good example as it doesn't have a UI so the user will simply not see/hear anything as the audio gets cached.
The ShadePlayer is also an issue because again we have no way to indicate via the UI that we are caching the data (this might not be true potentially the shades do have a method of playing directly from a URL).
Our own widget SoundPlayerUI already supports loading the URL data and reflecting the download progress in the UI (vai a percentage spinning progress indicator).
It feels like it might be better if we gave the user an explicit caching mechanism and they then build the UI to suite their purposes.
Internally we use Track._prepareStream to download URL data.
We could just expose this externally and then also expose Track._release. I'm not a big fan of this as the release method will suggest to users that they need to call release all of the time which isn't the case.
So what about a caching class
When you call cacheTrack it returns a stream which could be passed to a StreamBuilder to allow a user to build a widget that reflects the caching progress.
It should be noted that we already have the
Downloader
class that can download a file with progress information.Thoughts?
The text was updated successfully, but these errors were encountered: