We plan to use video_player as a production demonstration of a plugin developed with a hybrid of traditional Flutter plugin development and FFI on both Android and iOS/macOS. The general plan is:

• Reduce, but not eliminate, the amount of native code, by migrating more logic to Dart (in keeping with the overall trend of the flutter/plugin repository)
  • The plugin system will continue to be used, especially for things like the texture system that we don't currently have a non-plugin replacement for.
• Use ffigen/jnigen to create bindings to the plugin code, and replace most method channel calls with FFI. In particular, the goal would be for all of the calls to individual player instances to be made via FFI.
• The switch to FFI for an implementation won't land until thread merging in non-option on the target platform, as handling the thread hopping via FFI would add a lot of complexity. As a result, incremental refactoring will happen while still using method channels for everything, and then switching those out for FFI will be the last step.

The primary goal here is to ensure that we are consumers of this development model, as this hybrid approach would be likely incremental adoption model for the many existing plugins out there (including more of our own plugins in the future). Secondarily, this change will make it easier to avoid some of the state coordination problems this plugin suffers from, by making it easy to live-query native state instead of always trying to synchronize it. (Playback position, buffering status, play/pause state, etc.)