Suchergebnisse

Zitat von 322: „Du kannst Dinge sehen wir du auch immer möchtest, nur Fakten verändern wirst du mit einen privaten Ansichten nicht, zum Glück. “ Welche Fakten hast Du denn??

Sehe ich nicht so. Unter SwiftUI (I), gab es keinen Property Wrapper "@StateObject". Hat auch gut funktioniert. Es gab aber ein paar erratische Fehler, welche kaum nachzuvollziehen waren. Dies hat dann zur Entwicklung von @StateObject unter SwiftUI (II) geführt. Beide hatten den selben Anwendungsbereich. Beide gibt es noch. Es gab nur eine Empfehlung bei neuen Code @StateObject anstatt @ObservedObject zu verwenden. Beide werden in einer View auch nur einmalig erstellt. Daher die obige Aussage au…

Zitat von Osxer: „ - Fallstrippe habe ich aus dem folgenden Grund geschrieben. Wenn man, so wie du in deinem Eingangsposting, @ObservedObject var statistik = Statistik() schreibt, dann hat das zur Folge, dass deine Statistik-Instanz bei jedem Neu-Rendern der View auch neu instanziiert wird - sprich all deine Daten in statistik sind weg bzw. wieder beim Ursrpungszustand. Genau hierfür gibt es *trommelwirbel* @StateObject. Das ist im Prinzip genau das Gleiche wie @ObservedObject mit dem entscheide…

Weiss jetzt nicht was MKUserTrackingMode ist, Struct oder Klasse. Im Falle eines Structs musst Du es als Binding übergeben, im Falle einer Klasse ist deine Deklaration falsch.

Sorry, das Beispiel von dir, ist nonsense. So etwas bildet man doch direct als function in der View ab. Aber egal, der Zweck heiligt dir Mittel.

Würde ich so nicht sagen, ein struct wird beispielsweise bei jeden Update der View neu erstellt. Wenn Dir das egal ist, und du es auch nicht weiterreichen möchtest, kannst du gerne ein struct verwenden. Das heisst halt, im Init, darfst du keine aufwendigen Implementierungen haben, sonst geht es schnell zulasten der performance. EnvironmentObjects, würde ich nur einsetzen, wenn sie wirklich global gelten und jede View auf den gleichen State zugreifen soll/muss.

Zitat von BubbleFreak123: „Ich möchte Berechnungen in einem eigenen Struct durchführen lassen und nur das Ergebnis in meiner View ausgeben. “ Zitat von Babelfisch: „Woher entnimmst du, dass Berechnungen eine Struct sein soll??… “

und? Was willst damit sagen?

Ich würde definitiv keinen von beiden verwenden. Wenn Du was zuberechnen hast, bau dir einenController als Class, überlass dem die Berechnungen. Ein struct ist dafür ungeeignet

Zitat von MyMattes: „Für Deine Fragestellung unnötig und komplex und unnötig komplex. Das Hauptproblem ist aber (wie Du sagst) "das ich den Code nicht zu 100% verstanden habe" Damit sollte er für Dich keine Option sein - ich würde nie (nie!) Code verwenden, den ich nicht verstehe “ Ich habe hier ein anderes Problem, ich verstehe das Problem nicht…

Zitat von MyMattes: „Zitat von Wolf: „Wo ist denn das Problem? Die Emoji’s sind doch norme Unicode Zeichen. Die werden Escaped und gut ist‘s. “ Vielleicht ein (fremdes) Backend, das nur UTF-8 kann? Einfach mal geraten... “ ist aktuell noch nicht erlaubt, es sind nur ASCII Zeichen zulässig. Es gab aber schon mal Diskussionen darüber, damals gaben Sicherheitsbedenken den Ausschlag, ASCII beizubehalten.

Zitat von Thallius: „Zitat von Wolf: „Nach dem Escapen, gibt es keine ungültigen Zeichen mehr. Da kannst dann auch mit ASCII weiterschaffen, wie im letzten Jahrtausend, als es noch kein UTF gab. “ und trotzdem konnte man damals auch schon alles schreiben was man sagen wollte… SCNR “ nur nicht in allen Sprachen…

Tja… … nach dem Escapen, hat es nur noch normale Character. was das Backend dann hier rein interpretiert, ist eine andere Sache. Was Thallius meinte, kann ich nicht nachvollziehen, Ein String ist ein String, und der muss zum Zeichensatz passen. Sehe keinen grund weshalb eine URL nicht in UTF-16 oder UTF-32 kodiert sein sollte.

Nach dem Escapen, gibt es keine ungültigen Zeichen mehr. Da kannst dann auch mit ASCII weiterschaffen, wie im letzten Jahrtausend, als es noch kein UTF gab.

Zitat von hape42: „.Aber für das Ursprungsproblem "Emoji aus NSString entfernen" habe ich immer noch keine Idee “ Wo ist denn das Problem? Die Emoji’s sind doch norme Unicode Zeichen. Die werden Escaped und gut ist‘s.

bei SwiftUI, Z-Stack, den positionieren und gut ist‘s. Problem, wie wohl überall, kann bestimmte Bedienelemente verdecken, dadurch durch den User nicht mehr zu erreichen. Kannst auch mit UI-Kit nutzen, musst halt einbinden…

Waren sie schon mal produktiv?

Früher ear er schlechter, aktuell wird der Playground allerdings zu Entwicklungsplattform ausgebaut. Das heisst, jetzt kannst schon Apps auf den iPad in Playground erstellen und auch im Appstore deployen. Ist aber auf Swift und SwiftUI beschränkt. Finde Ihn daher in der neusten Version, auf dem iPad, ganz brauchbar. Hat aber nach wie vor Einschränkungen, aber um was auszuprobieren, ist er mittlerweile recht gut.

Schau dir mal die Bücher von RayWenderlich oder von Paul Huston an. raywenderlich.com/books/swiftui-by-tutorials hackingwithswift.com/quick-start/swiftui

Zitat von Thomas: „@Thallius: Ich habs zuvor mit TCP gemacht. Ist ja kaum ein Unterschied im Code. Das verlangte aber nach jedem send eine sofortige Antwort, was die Sache nur unschön und langsam macht. Zudem ist es lokal gar nicht nötig. Da geht nix verloren und alles behält seine Reihenfolge. Wenn es lokal mit UDP klappt und remote Probleme auftreten, dann kann ich immer noch auf TCP erweitern. “ Auch wenn ich von der Progammlogik nichts dazu sagen kann. Die Unterschiede zwischen UDP und TCP h…