Closed zxl777 closed 2 years ago
There are some other issues more generally with trying to get hot restart/reload to work in the presence of multiple isolates, and this is being addressed on the one-isolate
branch which is planned for the 0.18.0 release.
Note that all new development is happening now on the one-isolate
branch. If you would like to test that branch, note there is a migration guide since the API has changed:
https://github.com/ryanheise/audio_service/wiki/Migration-Guide#0180-preview
OK. I have to test the 0.18.0
I am affected by the library dependency and can only use the latest 0.17.0-nullsafety.0, but not the earlier version.
Now 0.18.0 is the only solution.
The work of 0.18.0 migration is too complicated.
I had to rewrite all the playback code.
I think audio_service should be kept simple, just support just_audio is enough. If you want more audio libraries to support audio_service, you may not achieve this goal and make the code increasingly complex.
The goal of audio_service is to offer the flexibility to solve a variety of use cases. Some people use audio_service in fitness tracker apps which need to be able to play audio in the background via text-to-speech communication rather than, say, playing music. And there's a whole lot more creative ways people are using this plugin.The goal is to be able to support all sorts of background audio apps.
If you want a simple plug-n-play solution for just_audio, I am working on one, but audio_service isn't it. This project is for power users who actually have a need for that power.
If you are interested in what's around the corner for people who want a ready-made solution, once this version of audio_service is released, please take a look at:
https://github.com/ryanheise/just_audio/pull/311 https://github.com/ryanheise/just_audio/tree/background/just_audio_background
The idea is that you add just_audio_background
to your pubspec dependencies alongside just_audio
and it will automatically add background support to just_audio without your needing to write a background task or audio handler.
This type of plugin design makes it possible to support both advanced use cases, through direct use of audio_service itself, and some common simple use cases, through just_audio_background.
just_audio_background : This is a good idea, but it doesn't seem to be finished yet and it's not out of the box.
Hot reloading does not work. So there is no way to use it at this stage.
And I can't build this example on ios, and the error message is reported:
[!] CocoaPods could not find compatible versions for pod "sqflite":
In Podfile:
sqflite (from `.symlinks/plugins/sqflite/ios`)
Specs satisfying the `sqflite (from `.symlinks/plugins/sqflite/ios`)` dependency were found, but they required a higher minimum deployment target.
I suggest you write a development roadmap so that it can be clear at a glance.
I still use 0.18.0 and hope that there will be no major changes in the future.
Finally, thank you for developing such a powerful audio library.
just_audio_background is still based on the old version of audio_service which runs in multiple isolates. As soon as the new version of audio_service is ready, I will be able to finish off the work with just_audio_background. Note that the hot restarting problem will be easier to address in the new version of audio_service which runs in one isolate, but each plugin you use must support hot reloading. just_audio will also need some code added in order to correctly dispose of the player's resources on a hot restart. Hot reload of course should be fine as long as the app that instantiates the player does so in initState
or some such (global instance / singleton / etc. / audio handler) that is preserved across hot reloads.
Thanks for your suggestions and appreciation. Things are difficult at the moment due to medical reasons but I agree with you that it would be good to have a roadmap. There is such a thing as projects on GitHub, but because the work I do on these plugins is not on any single repository, it is not practical to track all of the items together on one board. For example, the fact that I need to release audio_service before just_audio_background. Perhaps it could be a wiki page.
Hope everything will rejuvenate as soon as possible.
For me, an example that can run successfully is better than a document. For example, what I want to refer to is the code in https://github.com/ryanheise/audio_service/tree/one-isolate/example/lib.
For me, example is the solution. The more concise the example, the more appropriate the corresponding comments, the easier it is to use.
That's a great suggestion. I was thinking of maybe including multiple examples in the project rather than including everything in one example, each example being in a separate subdirectory. With that sort of structure, it would allow me to create an ultra-simple example as the main example.
Yes, the 1000-line example is difficult to understand and port the code.
Another suggestion, I think your built-in rxdart is too heavy. I suggest you use https://pub.dev/packages/event_bus, this is very lightweight.
I suggest you use https://pub.dev/packages/event_bus, this is very lightweight.
Just to give my thoughts briefly, I'd like audio_service to be unopinionated about app architectural choices. Streams are native Dart construct for representing values that change over time, and all of these other higher-level architectures basically use streams under the hood. rxdart is largely a lightweight set of extension methods over the top of native streams (because native Dart streams already provide a lot of what's in Rx). rxdart has also been endorsed by Flutter as a Flutter Favorite, so it's a safe dependency to add, but more than that, it's less of a radical change over the raw low level Dart streams.
The focus is really on solving the problems associated with background audio, and as far as event_bus and other alternatives (and there are many!), it is best to let the application itself write an adapter to map those streams onto whatever the chosen architectural device is. Since I have been asked similar questions before (e.g. can I make it work with get_x), it might be worth adding this to the FAQ, just to make it clear that audio_service does not intend to go one way or the other, it'll stick to streams, but it is possible for an app to map those streams onto some other architectural pattern.
Looking forward to the 0.18.0 release and a condensed example.
I first use just_audio to accomplish my main goal.
I'll close this now that a prerelease of both audio service 0.18.0 and just audio background are available.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with audio_service.
Which API doesn't behave as documented, and how does it misbehave? 0.17.0 crash when Hot Restart
Minimal reproduction project Provide a link here using one of two options: Version 0.17.0-nullsafety.0 Example
To Reproduce (i.e. user steps, not code) Steps to reproduce the behavior: 1.Run Version 0.17.0-nullsafety.0 Example in iPhoneX 2.tap Play button 3.Tap Hot Restart in VSCODE. 4.app crash and disconnected.
Error messages
Expected behavior No crash
Screenshots N/A
Runtime Environment (please complete the following information if relevant):
Flutter SDK version
Additional context N/A