Suchergebnisse

Wie du ein Bild über den PhotosPicker auswählen und laden kannst, hat Apple hier beschrieben: developer.apple.com/documentat…icker_to_your_swiftui_app Das kannst du dann wie schon angesprochen im App-Ordner speichern und anzeigen.

Ohne mir jetzt deinen ganzen Code genau angesehen zu haben wäre mein Ansatz, einfach statt den Player (wegen Struct als Kopie) an die Views durchzureichen, besser nur die Player-ID weiterzugeben und über die ID dann im EnvironmentObject playersList immer den Player direkt zu nutzen.

Da beim Aufruf von PlayerDetailView selectedPlayer ja gesetzt sein muss, kannst du das Optional auch problemlos unwrappen. Bei Bindings sollte das so funktionieren: Quellcode (1 Zeile)

Warum ist denn player bei dir überhaupt optional? @Binding var player: Player? Macht doch gar keinen Sinn, da du die PlayerDetailView doch nie ohne Player aufrufst. Wenn’s nicht optional ist, dann verschwindet auch der Fehler.

Sofern es nicht zwingend Cocoa sein soll und auch SwiftUI für dich in Frage kommt, dann gibt es die einfach zu verwendeten List dafür: developer.apple.com/documentation/swiftui/list Vorteil ist auch, dass du viel einfacher macOS und iOS bedienen kannst.

Zitat von Qvex23: „Wie soll ich an Hand eines bools herausfinden welche ID in der Datenbank zu ändern ist. Und das .onChange wird trotzdem mit dem Fehler angemeckert. “ In deinem Code hattest du meine Vorschläge beim ForEach ja auch nicht eingearbeitet. Und deine ID steht doch in jedem Room-Objekt drin. Wo ist da das Problem? Mein letzter Hilfe-Versuch: Quellcode (24 Zeilen)

Zitat von Qvex23: „Es kann doch nicht sein, das im System nicht vorgesehen ist das man Änderungen am TextField nicht herausfinden kann. “ Ich habe dir gerade geschrieben, wie das geht.

In deinem Code ist das Room-Struct anders definiert: Quellcode (5 Zeilen)@State hat hier nichts zu suchen. Wenn deine verwendete Lib SwiftUI nicht direkt unterstützt, musst du es halt selber implementieren. Eine Idee wäre, die Room-Struct um den Bool isChanged zu erweitern und beim TextField dann jedes Feld mit onChange zu überwachen. So in der Art (nicht getestet): Quellcode (7 Zeilen)Dann musst du eine Speichern-Funktion implementieren, die bei Bedarf nur die geänderten Datensätze speichert. B…

Ich weiß nicht warum das bei dir nicht gehen soll. Hier klappt das problemlos. Was kommt denn für ein Fehler? Wenn du das sowieso in eine Datenbank schreiben willst, dann nutze doch gleich die angebotenen Funktionen wie @FetchRequest von Core Data. Damit sparst du dir den ganzen Kram und alles ist Imme synchron. hackingwithswift.com/books/ios…ine-core-data-and-swiftui

Ok, dein onChange stand nicht im Quellcode und das hatte ich ganz übersehen. Im onChange sprichst du nicht das Binding an, sondern den „echten“ Wert, deshalb ohne $ vor der Variable: Quellcode (3 Zeilen)Allerdings zeigt dir das nicht, welcher Wert sich geändert hat. newValue ist hier dein Array rooms und onChange teilt dir nur mit, dass sich irgendwas im Array geändert hat.

ForEach mit Bindings ist immer etwas tricky. Versuche es mal so: Quellcode (7 Zeilen)

Nein, leider nicht. Der Fehler tritt weiterhin auch in Xcode 14.1 RC und iOS 16.1 RC auf und von Apple gab es bisher noch keine Reaktion. Wie ich im Internet rausfinden konnte, liegt es wohl daran, dass List bisher UITableView genutzt hat und nun auf UICollectionView basiert. Das funktioniert dann mit ScrollViewReader offenbar nicht mehr. Warum Apple das aber nicht fixed und komplett ignoriert, ist mir ein Rätsel. Die verfügbaren Workarounds sind leider auch alle unbefriedigend.

Der Fehler steht doch da: Zitat: „Expected to decode Array<Any> but found a dictionary instead. “ Es wird ein Array im JSON erwartet aber ein Dictionary ist drin. Vermutlich sieht dein JSON so aus: Quellcode (1 Zeile)… muss aber so aussehen: Quellcode (3 Zeilen)

Ich habe dir mal ein Beispiel in SwiftUI gemacht, welches ich so einfach wie möglich gehalten habe. Es besteht aus der WebView-Komponente, die gleich ein UserScript in die Seite injiziert. Das UserScript greift sich alle Links und sendet beim Klicken auf einen Link den Text und die URL über den ScriptMessageHandler zurück zur App, wo es dann verarbeitet und angezeigt wird. Hier die WebView.swift Quellcode (75 Zeilen) Und hier die ContentView.swift: Quellcode (27 Zeilen) Das UserScript ist zwar s…

Wie Mattes schon sagt, geht das wohl nur mit Javascript Injektion über WKUserScript. Dort kannst du dann das onclick-Event aller Links abfangen und den textContent vom Link über einen WKScriptMessageHandler zur App zurücksenden. Ist eigentlich nicht so kompliziert.

Die Performance ist hier nicht mal mein Problem. Ich will aber ungern noch Swipe-Gesten nachbauen müssen. Na mal schauen, ob Apple das Feedback liest und den Fehler behebt.

Zitat von 322: „Ohne es mir jetzt genau angeschaut zuhaben, würde ich in Richtung ‚willChange‘ vs ‚didChange‘ forschen. “ An willChange und didChange komme ich so leider nicht ran bzw. sehe ich nicht, wie ich das sinnvoll nutzen kann, da ich ja trotzdem innerhalb vom ScrollViewReader zu der Zeile springen muss und das nur mit onChange geht. Zitat von 322: „Der Button löst einen redraw der View aus, genauso wie das Neuzeichnen der Liste das auch tut, in der selben View. Fakt jedoch ist, dass die …

… 29 30 30 Hmmm, das ist ja noch schräger. Beim Hinzufügen wird der letzte Eintrag doppelt aufgerufen, jedoch trotzdem nur einmal angezeigt. Hast du zufällig auch eine Idee, was das soll und ob man das ohne Bugfix von Apple umgehen kann?

So in dem Fall nicht, weil man dann den ScrollViewProxy nicht hat. Ich habe das in einem anderen Test aber schon versucht und das macht keinen Unterschied. Das Problem liegt nicht am onChange-Handler, sondern irgendwo tiefer. Allerdings brauche ich es für mein aktuelles Projekt (in Calculy den Rechenverlauf) so oder so im onChange. Dort habe ich ein ObservableObject und muss da auf Änderungen reagieren.

Der ScrollViewReader ist ja dazu da den ScrollViewProxy zur Verfügung zu stellen. Das kann eigentlich nur so funktionieren, zumindest wird es so in der Doku beschrieben und ich wüsste auch keinen anderen Weg. Und scrollTo(0) ist kein Problem, das funktioniert. Es tritt nur auf, wenn man zum Ende einer dynamischen Liste springen will. Dabei ist aber auch data und count nicht das eigentliche Problem. Hier habe ich zum Beispiel am Ende immer ein Bottom-Element: Quellcode (38 Zeilen)Gleicher Fehler,…