ryanheise / audio_service

Flutter plugin to play audio in the background while the screen is off.
785 stars 461 forks source link

0.17.0 crash when Hot Restart #616

Closed zxl777 closed 2 years ago

zxl777 commented 3 years ago

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

Restarted application in 1,295ms.
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSDictionaryM setObject:forKeyedSubscript:]: key cannot be nil'
*** First throw call stack:
(0x1a6af99d8 0x1bae7fb54 0x1a6b63d98 0x1a6b6f414 0x1a69e9d9c 0x10466c730 0x105228c9c 0x1049c8258 0x104cc763c 0x104c66a3c 0x104c690f4 0x1a6a7a3e0 0x1a6a79fe4 0x1a6a794c4 0x1a6a73850 0x1a6a72ba0 0x1bd7db598 0x1a93642f4 0x1a9369874 0x10459fb68 0x1a6751568)
2

Lost connection to device.
Exited (sigterm)

Expected behavior No crash

Screenshots N/A

Runtime Environment (please complete the following information if relevant):

Flutter SDK version

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.0.2, on Mac OS X 10.15.7 19H524 darwin-x64,
    locale zh-Hans-CN)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.1)
[✓] VS Code (version 1.54.3)
[✓] Connected device (1 available)

Additional context N/A

ryanheise commented 3 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

zxl777 commented 3 years ago

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.

zxl777 commented 3 years ago

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.

ryanheise commented 3 years ago

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.

zxl777 commented 3 years ago
  1. 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.
  1. I suggest you write a development roadmap so that it can be clear at a glance.

  2. 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.

ryanheise commented 3 years ago

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.

zxl777 commented 3 years ago

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.

ryanheise commented 3 years ago

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.

zxl777 commented 3 years ago

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.

ryanheise commented 3 years ago

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.

zxl777 commented 3 years ago

Looking forward to the 0.18.0 release and a condensed example.

I first use just_audio to accomplish my main goal.

ryanheise commented 2 years ago

I'll close this now that a prerelease of both audio service 0.18.0 and just audio background are available.

github-actions[bot] commented 2 years ago

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.