Consider using the "Federated plugins" approach

[renancaraujo]

Consider using Federated plugins on audio players.

Full Description
Federated plugins is an approach of maintaining plugins for multiple platforms with a single dart-facing API. This can speed up support for new platforms as requested on #489 and #798.

An advantage of that is that we can see that the approaches to play sound in different platforms can vary a lot from platform to platform, and they may have different levels of stability. This would allow the platform plugins to be updated independently.

An example of a package already doing this is shared_preferences in which we have shared_preferences_linux, shared_preferences_macos, shared_preferences_web and shared_preferences_windows.

There is a guide for migrating here.

Platforms

• All of them.

[luanpotter]

This is really interesting @renancaraujo

Initially I saw some packages doing something like this and other not. I thought adding the web code inside the same plugin would be better because then projects only need to import one package and run anywhere. Eg you could run your existing android game on web w/o adding any dependencies. Also the android/ios code lived all in one folder, under the same package. I personally still prefer this structure as I think it's much simpler and cleaner and I fail to see some of the benefits of the article. However, my preference is to follow whatever standard is defined and it seems federated packages is the way to go now. Would you like to help out with this? Seems it would be simple but a lot of work to move everything around and wire correctly.

[renancaraujo]

Yes I could.
Also, I forgot to mention that another plus is that it would be possible for the community to maintain platform-specific audio plugins.

[luanpotter]

Yeah I read that in the article, honestly, I don't think that really matters -- if anyone impl AP for any platform and sent a PR I would be happy to merge it. We can even add someone as another contributor if they are helping a lot with AP. If it lives on the same mono-repo or not is not relevant IMO for a contributing standpoint. We should strive for the contribution friction to be as low as possible, both for changes on the core AP or adding new platforms.

But for the other reasons, I agree we should migrate, if you wanna help! :)

[luanpotter]

How does this look like? #837

[renancaraujo]

Not much