Miniplayer: antippen vergrößert wieder

Die Kachel ließ sich nicht mehr öffnen, und das war kein Zufall: das
Antippen zeigte erst die Bedienelemente, und die zweite Berührung sollte
vergrößern — traf dabei aber den Abspielknopf, der genau in der Mitte lag.
Jede weitere Berührung landete wieder dort. Vergrößern war damit überhaupt
nicht möglich.

Jetzt gehört die Mitte dem Vergrößern, und zwar beim ersten Antippen. Die
zwei Knöpfe — Pause und Schließen — sitzen dauerhaft sichtbar in den oberen
Ecken, auf einer dunklen Scheibe, damit sie auf hellen Filmbildern nicht
verschwinden. Unten bleibt der Fortschrittsbalken.

Dass die Kachel „einfach weg" war, konnte ich nicht nachstellen; der eine
Fall, den ich reproduziert habe, war mein eigener Attrappenserver mit einer
Fortsetzungsstelle jenseits des Dateiendes. Zwei Dinge machen es trotzdem
unwahrscheinlicher: die Knöpfe sind auch dann zu sehen, wenn das Bild
schwarz bliebe — vorher war eine schwarze Kachel in einer fast schwarzen
Oberfläche praktisch unsichtbar —, und die Bildfläche hängt jetzt in einer
eigenen Hülle je Ansicht. Beim Wechsel zwischen Kachel und Vollbild gibt es
beide kurz gleichzeitig, und eine `UIView` hat nur einen Vorgesetzten: wer
sie zuletzt bekommt, gewinnt. Gab SwiftUI sie unmittelbar heraus, konnte das
Abräumen der einen der anderen die Bildfläche wegnehmen.

Dazu etwas, das mir beim Ausprobieren selbst passiert ist: der Aufmacher
wanderte weiter, während ich nach „Abspielen" griff, und ich startete den
falschen Film. Er hört jetzt bei der ersten Berührung auf zu wandern. Wer
die Hand darauf hat, fährt selbst.

Nachgesehen auf iPhone und iPad: verkleinern, antippen, wieder im Vollbild.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Flixy/Views/Player/VideoSurface.swift

@@ -47,9 +47,36 @@ final class PlayerLayerView: UIView {
 ///
 /// Umhängen statt neu bauen: dieselbe `UIView` wandert zwischen Kachel und
 /// Vollbild hin und her, und die Wiedergabe merkt davon nichts.
+///
+/// Sie wird dabei **nicht** unmittelbar zurückgegeben, sondern in eine eigene
+/// Hülle gehängt. Der Unterschied zählt genau in dem Moment, in dem es beide
+/// Ansichten kurz gleichzeitig gibt — beim Wechsel zwischen Kachel und
+/// Vollbild: eine `UIView` hat nur einen Vorgesetzten, und wer sie zuletzt
+/// bekommt, gewinnt. Gab SwiftUI sie unmittelbar heraus, nahm das Abräumen der
+/// einen Ansicht der anderen die Bildfläche weg, und übrig blieb eine schwarze
+/// Kachel — in einer fast schwarzen Oberfläche also scheinbar gar keine.
+///
+/// Mit eigener Hülle gehört jeder Ansicht ihre eigene, und `updateUIView` holt
+/// die Fläche zurück, falls sie zwischenzeitlich woanders eingehängt wurde.
 private struct UIViewContainer: UIViewRepresentable {
     let view: UIView
 
-    func makeUIView(context: Context) -> UIView { view }
-    func updateUIView(_ uiView: UIView, context: Context) {}
+    func makeUIView(context: Context) -> UIView {
+        let host = UIView()
+        host.backgroundColor = .black
+        adopt(into: host)
+        return host
+    }
+
+    func updateUIView(_ host: UIView, context: Context) {
+        guard view.superview !== host else { return }
+        adopt(into: host)
+    }
+
+    private func adopt(into host: UIView) {
+        view.translatesAutoresizingMaskIntoConstraints = true
+        view.frame = host.bounds
+        view.autoresizingMask = [.flexibleWidth, .flexibleHeight]
+        host.addSubview(view)
+    }
 }