Change architecture for composable, customizable usage

[AmadeusK525]

➕ Enhancement Request

Problem related to enhancement request

This repo is a public library, which is intended to be used in production for real world projects. This means that the architecture should be designed in a way that is most useful to whoever imports the library. What is the number one priority in this scenario? CUSTOMIZABLE UI. The UI is currently rigid, embedded and not customizable at all.

Sought-for solution

We need to separate the rendering of the UI itself and the actual video layer. The UI layer should be injected to our MediaPlayerView:

MediaPlayerView(url: myURL, ui: MyCustomUIView())

There are two things to consider:

• We should provide a default UI (which is what we've been working on)
  • In a lot of cases, we just want a quick media view with simple preset controls while we work on the UI,
    and the default one we provide should suffice
• The UI should be bi-directional. The custom implementation should be able to control the MediaView when needed
  and the MediaView should be able to control the UI as well.

The way to achieve this is via protocols. There isn't a hard rule to this, you can define protocol requirements and satisfy them via Binding state variables or you can think of a way using getters and setters. The state binding is definitely more in line with reactive SwiftUI programming, but if it starts becoming a hurdle to implement bidirectionally, you can consider getters and setters for sure. Be creative and think of the cleanest solution, always keeping in mind that the following MUST be priorities over everything else:

• The PUBLIC interface should be easy to use. If you're stuck between a solution that is cleaner internally but requires more work on the dev's side and another one that requires more work internally but is cleaner on the dev's side, GO FOR THE LATTER. The public interface is the most important one
• The bidirectional controls should work seamlessly

Considered alternatives

We could try and make the default UI super customizable via parameters instead of delegating the rendering of the overlay to the dev's side, but considering past experiences with video work, this will almost always result in the default UI we provide being turned off entirely in favor of rendering a completely custom one on top of the video stream. Designs can differ greatly from project to project, and it's a way too optimistic thinking that we can cover this via parameter customization