Soryboards in Swift

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Soryboards in Swift

    Hallo an alle,

    Ich bin jetzt mit Swift durchgestartet.
    Ich habe mich durch diese Seite gelesen, alle infos abstrahiert und in meine eigene "Dokumentation" geschrieben.

    Für meine weiteren Schritte bin ich auf der suche nach infos über Storyboards dazu folgende Fragen:
    - Gibt es eine Gute Dokumentation in der Soryboards gut erklärt werden?
    - Das GUI kann ja auch direkt im Code erstellt werden, gibt es dafür eine Übersichtliche und gute Dokumentation?
    - Mit was findest du es sinnvoller zu arbeiten, Befehle im Code oder Storyboard?

    Nun schon einmal vielen Dank für eure Hilfe.

    Liebe Grüße
    Paule
  • Paul___Paul schrieb:

    - Gibt es eine Gute Dokumentation in der Soryboards gut erklärt werden?

    - Das GUI kann ja auch direkt im Code erstellt werden, gibt es dafür eine Übersichtliche und gute Dokumentation?
    - Mit was findest du es sinnvoller zu arbeiten, Befehle im Code oder Storyboard?
    Zu Deiner Frage nach Dokumentationen findest Du tonnenweise Informationen im Netz. Was hier „gut“ ist, liegt im Auge des Betrachters. Ich würde bzgl. Storyboards bei Apple‘s Hilfe zum Interface Builder einsteigen.

    Auch für das codebasierte Erstellen von Benutzeroberflächen wäre die Apple-Dokumentation meine erste Wahl. Letztlich ist die m. E. grösste Hürde hier das Layoutsystem (z. B. via Constraints) zu verstehen und umzusetzen … der Rest ist ja irgendwie nur ein Erzeugen und Ineinanderschachteln von UI-Elementen. Aber jeder Jeck ist anders und Google ist Dein Freund.

    Zur letzten Frage wirst Du vermutlich von x Leuten eben soviel unterschiedliche Meinungen hören. Ich persönlich tendiere zu Code, den ich einfacher zu warten finde: Konfigurationen sind an einer Stelle sichtbar (und man muss sie nicht im IB zusammensuchen), ich kann kommentieren, die Versionskontrolle über git ist lesbarer und - bei mir irrelevant - mehrere Personen können parallel Änderungen an einem UI-Element vornehmen. So haben meine Apps meist nur das Grundgerüst und vereinzelte Fenster in XIBs oder Storyboards, die Feinheiten liegen im Code (bei iOS noch mehr als bei macOS).

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • schau dir mal die Seite von Paul an, da gibts genug für Storyboard und SwiftUI (Link: hackingwithswift.com/ )

    hier noch eine Ergänzung, soeben ist Pauls neuer Online Kurs herausgekommen, upgedated auf Swift. 5.5 und SwiftUI 3. Für diejenigen die mal 100 Tage etwas Zeit investieren können: hackingwithswift.com/100/swiftui

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Wolf ()

  • mrMo schrieb:

    Hab aber direkt mit SwiftUI begonnen. Das ist wohl das Pferd auf das man setzen sollte wenn man mit Swift anfängt.
    Hallo @AppleDeveloper, @mrMo und @Wolf ... das ist als ernsthafte Frage gemeint:

    Ist das wirklich so? Ich habe mich bisher nicht im Detail mit dem Umfang von SwiftUI auseinandergesetzt, arbeite aber (mal wieder) an meiner "Haupt-App" unter macOS. Dort nutze ich (Sub-)Views, die per Core Graphics ihre Inhalte zeichnen, auf Mouse-Events reagieren, Kontext-Menüs anzeigen usw. Parallel dazu natürlich mehrspaltige TableViews mit Kontext-Menüs, Drag'n'Drop, ...

    Könnte man derartiges zur Zeit mit SwiftUI abdecken? Ich vermute ja, aber "nur" durch Einbetten entsprechender NSViews? Meinem Vorurteil nach ist SwiftUI bisher nur für vergleichsweise simple Oberflächen geeignet, aber hier lasse ich mich gerne eines besseren belehren ... vielleicht ist das endlich der Motivator, in Swift einzusteigen?

    Oder sind Eure Einschätzungen eher "zukunftsgerichtet"? Ich zumindest bin der Ansicht, dass Apple immer mehr eine Vereinheitlichung der unterschiedlichen Plattformen zulasten der Funktionalität anstrebt. Hoffentlich kann man langfristig auf macOS nicht nur "bunte iOS-Pappen" programmieren.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Bin mit der iOS/MacOS Welt leider noch nicht besonders vertraut, kommt ursprünglich von .Net und hatte bock was neues zu lernen.

    Mit SwiftUI hab ich mich auch nur kurz am Anfang beschäftigt. Momentan arbeite ich mich „nur“ in Swift ein indem ich Advent of Code Aufgaben löse (ohne GUI, nur Console) um Syntax und Co. zu lernen. Schöne Sprache bis jetzt.

    So wie es für mich aussieht ist SwiftUI das, wo Apple hin will. SwiftUI kann wohl nur noch nicht so viel wie Storyboards. Ich hatte mich kurz eingelesen und für mich beschlossen direkt mit dem „new hot shit“ anzufangen. Hätte damals bei .Net auch direkt WPF statt WinForms lernen sollen… war mir damals als Neuling in der Programmierung aber zu kompliziert. Diesen Fehler wollte ich jetzt nicht nochmal begehen indem ich was „altes“ lerne.
  • MyMattes schrieb:

    Oder sind Eure Einschätzungen eher "zukunftsgerichtet"? Ich zumindest bin der Ansicht, dass Apple immer mehr eine Vereinheitlichung der unterschiedlichen Plattformen zulasten der Funktionalität anstrebt.

    Apple hat ein Problem, dass es verschiedene inkompatible Frameworks Supporten muss. Daneben die Ausbildung der eigenen Leute, etc. Dann eine Programmiersprache OC, welche doch sehr in die Jahre gekommen ist. Da mussten sie was machen, auch vor dem Hintergrund, dass die macOS Entwicklung neu (schon einige Monate her) jetzt in die Abteilung der iOS Entwicklung eingegliedert wurde. So haben sie halt mal mit der Programmiersprache angefangen, welche doch jetzt einen recht reifen Zustand erreicht hat. Swift 5.5 finde ich aktuell alles andere als schlecht. Haben halt die alten Konzepte übernommen und noch einiges hinzugefügt, wie bspw. Möglichkeiten der Funktionalen Programmierung. Mit Schnittstellen von OC nach Swift und umgekehrt. So, dass man das eine machen kann ohne das andere zu lassen. Haben ja genügend Altlasten, welche sich nicht von heute auf Morgen umstellen lassen.

    Mit dem Konzept das eine zu tun ohne das andere zu lassen, sind sie dann auch in die UI Frameworks eingestiegen. Damit man langsam in die neue Technologie, das vereinheitliche Framework (SwiftUI) langsam umsteigen kann ohne ein Risiko einzugehen. Wenn Du die Entwicklung auf macOS, wie auch auf iOS, verfolgst, wirst du feststellen, dass die Jungs aus Cupertino dabei sind, eine App nach der anderen auf das neue Framework umzustellen. Hat für sie auch entsprechende Vorteile, eine Entwicklung welche auf allen Plattformen läuft mit einmaligen Entwicklungs- und Testaufwand. Daneben wurde mehr auf die Sicherheit der Sprache geachtet, damit Speicherüberläufe weniger vorkommen können. O.k. hat nicht nur Sonnenseiten, andere lieben die Freiheit ein Zeichen zu interpretieren wie man gerade Lustig ist, ob Int oder Char. Nur mit der zunehmenden Verbreitung von iOS/macOS finden halt auch die Hacker gefallen daran, und da müssen sie halt auf mehr Sicherheit achten.

    Das heisst, du kannst davon ausgehen, dass die Entwicklungskapazitäten wohl auf die neue Sprache inkl. UI Framework (SwiftUI) konzentriert wird.

    Einverstanden, das ganze ist noch nicht so durchgehend, aber sie arbeiten dran. Neu in SwiftUI gibt es jetzt #If Statements, wo man auf .xxx ebene differenzieren kann. Lag daran, dass eine View in SwiftUI für iOS und macOS unterschiedliche Parameter hatte. Jetzt (ab SwiftUI 3) kann man das viel eleganter formulieren. In SwiftUI 3 (seit Herbst 2021) gibt es auch die Möglichkeit Tabellen (wie du sie bisher aus AppKit kennst) mit unterschiedlichen Spalten, Sortierungen und Filter direkt aus SwiftUI heraus zu erstellen. Kontext Menus gibt es schon lange, genauso wie Drag and Drop.

    Aber es gibt natürlich noch einige Punkte, welche sie bisher noch nicht angegangen sind, wie bspw. ansprechen der Kamera. Bei welcher man aktuell noch auf die Einbindung von UI/App-Kit angewiesen ist. Du siehst, noch ist nicht alles fertig, sie arbeiten dran. Aber wie es so schön heisst, man kann das eine tun ohne das andere zu lassen. Sowohl auf OC/Swift als auch UI/Appkit zu SwiftUI. Alles kann man gegenseitig verwenden. Daher, kann man einfach ohne Risiko loslegen und den Schwenk kann langsam vornehmen.
  • MyMattes schrieb:

    Ist das wirklich so? Ich habe mich bisher nicht im Detail mit dem Umfang von SwiftUI auseinandergesetzt, arbeite aber (mal wieder) an meiner "Haupt-App" unter macOS. Dort nutze ich (Sub-)Views, die per Core Graphics ihre Inhalte zeichnen, auf Mouse-Events reagieren, Kontext-Menüs anzeigen usw. Parallel dazu natürlich mehrspaltige TableViews mit Kontext-Menüs, Drag'n'Drop, ...
    Hi @MyMattes,
    mal ein kleiner Erfahrungsbericht von mir: Genau vor derselben Frage wie du stand ich vor mittlerweile 2 Jahren. Ich bin nicht auf macOS unterwegs sondern ausschließlich iOS. Dies mit meiner eigenen Firma sowie im Hauptjob.

    Meine erste größere App mit Swift UI hab ich damals mit iOS 13 begonnen. Mit der App kann man sich auf einer Karte eine Filiale auswählen, sein Produkt konfigurieren und in den Warenkorb legen, über Adyen bezahlen und anschließend erhält man einen QR-Code zum einlösen. Weiterhin wird die Authentifizierung mit AWS Cognito abgewickelt. Also schon ein größeres Projekt.

    Damals mit iOS 13 war das alles noch ein wenig rudimentär. Dann kam iOS 14 und vieles wurde schon besser. Die Kompatibilität zwischen iOS13 und iOS14 mit SwiftUI war jedoch der Horror. Die UI war auf iOS 14 unverwendbar und in komischen Farben etc. Apple kümmert sich da gar nicht um Abwärtskompatibilität. Erstaunlicherweise konnte ich relativ viel ohne eigene Controls abwickeln. Nur sowas wie die Karte brauchte ein eigenes. Sachen, die mit UIKit mich mehrere Stunden gekostet haben, mach ich mit SwiftUI in Minuten. Besonders das Databinding will ich nie wieder missen.

    Jedoch kostete SwiftUI einen auch sehr viele Nerven. Externe Controls wie Cognito oder Adyen anzubinden war nicht so einfach (man hat ja kein Window-Objekt). Auch ging damals Beispielswiese das ausblenden von den LineSeperators zwischen den Tabellenzellen nur mit einigen Hacks und sehr viel Aufwand.

    Dann kam iOS15. Die Umstellung von 14 auf 15 war wieder mit Problemen behaftet, aber weniger. Das einzige große Problem war, dass die mit iOS15 die Back-Navigation umgebaut hatten. Nun erzeugte der selbe Code auf iOS14 unterschiedliches Verhalten als auf iOS15. Das hat mich auch einige schlaflose Nächte gekostet.

    Mit iOS15 ist SwiftUI aber zum ersten mal so richtig brauchbar. Ich nutze das jetzt in allen Projekten und bin begeistert. Die ersten Versionen waren wie Beta. Nun kamen aber so viele Funktionen/Controls hinzu und es wird einem so viel Arbeit abgenommen. Natürlich bringt es nicht nur SwiftUI einzusetzen sondern man muss auch die neue Architektur anwenden, sich bei einigen Controls umgewöhnen (CollectionViews werden über Listen abgebildet...) aber es lohnt sich. Das in Kombination mit KMM und Jetpack Compose ist einfach unschlagbar. (Ein Erfahrungsbericht kann ich darüber auch gerne mal schreiben) So produktiv wie jetzt war ich noch nie. Der ganze Overhead von "damals" fällt weg.

    Wie das jetzt natürlich mit macOS aussieht kann ich nicht sagen. Ich hab mal fix gegoogelt und scheint aber hier auch ein Tutorial zu geben mit Drag and Drop - auch in einer Tabelle. Erstaunlich simpel.

    Mir hat es damals geholfen einen kleinen Prototypen zu bauen, wo ich alle meine benötigten Controls verwendet habe. Erst dann hab ich angefangen.

    Das ist jetzt nur meine Meinung aber ich kann es jedem empfehlen. Ich würde sagen: Probier es mal!
  • MyMattes schrieb:

    Hoffentlich kann man langfristig auf macOS nicht nur "bunte iOS-Pappen" programmieren.
    Wo ich es gerade sehe, mit Swift und SwiftUI kannst du native auf den Mac entwickeln. Von daher, die „bunten iOS Pappen“ hast du nur, wenn du eine App, welche nicht auf den Mac läuft, auf den Mac schiebst…

    Noch kurz einen Punkt, bevor ich es vergesse. Im neuen Playground (für iOS) können nun auch Apps erstellt werden, auch eingestellt in den Appstore. Für das UI gibt es allerdings nur SwitUI (mit Einbindung des UIKits, da es Storyboard‘s dort nicht gibt). auch das zeigt die Richtung an, in welche es geht.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Wolf ()

  • Gerade wenn man sich nicht nur mit Hobby Projekten/Apps beschäftigt, sondern Apps für Kunden entwickelt, scheint mir die Verwendung von SwiftUI noch nicht wirklich sinnvoll zu sein.

    Speziell wenn ich lese, dass mit SwiftUI erstellte Apps unter der nächsten iOS/SwiftUI Version ggf. nicht mehr korrekt funktionieren. Da wird es halt schwierig dem Kunden zu erklären, dass man, mit ggf. mehreren Tagen Aufwand, die App erst mal aktualisieren muss, damit diese mit der neuen iOS/macOS Version wieder funktioniert.

    Für "kommerzielle" Apps werden ja auch meist mehrere zurückliegende iOS/macOS Versionen unterstützt, so dass man dann leider auch nicht die jeweils neuesten Features von SwiftUI verwenden kann. Ich würde daher behauten, dass man SwiftUI erst ab Version 5 oder sogar noch später für kommerzielle Apps verwenden kann. Dann jedoch auch wieder nur die Features einer entsprechenden Vorgänger Version, die unter der gewünschten iOS/macOS Version auch zur Verfügung stehen.

    Genau wie ersten Versionen von Swift, scheint sich SwiftUI immer noch in der Grund Konzept-/Entwicklungs-Phase zu befinden. Ob sich damit dann irgendwann die gleiche Flexibilität wie mit UIKit ergibt, wird sich noch herausstellen.
  • MCDan schrieb:

    Gerade wenn man sich nicht nur mit Hobby Projekten/Apps beschäftigt, sondern Apps für Kunden entwickelt, scheint mir die Verwendung von SwiftUI noch nicht wirklich sinnvoll zu sein.
    Würde ich nur bedingt unterschreiben. Ich würde es immer wieder für neue Projekte einsetzen. Wie gesagt mit iOS 15 ist es top nutzbar. iOS 14 bekommt man auch, ohne größere Probleme angebunden.

    Wenn man aber ältere Systeme unterstützen muss dann auf jeden Fall. Viele sinnvolle Funktionen gibt es auch erst ab iOS 15. Ich bin froh, dass unser Produkt so und so erst Ende 2022 live gehen soll. Bis dahin ist auch iOS 16 da und man kann dadurch iOS 15 voraussetzen.
  • MCDan schrieb:

    Speziell wenn ich lese, dass mit SwiftUI erstellte Apps unter der nächsten iOS/SwiftUI Version ggf. nicht mehr korrekt funktionieren.
    Das hatte ich 1 Mal beim Übergang von SwiftUI 1.0 auf 2.0, auf der Code Basis.

    Zu den Versionen, ich habe da keine Hemmungen, die neuste Version vorauszusetzen, wenn ich den Statisiken trauen kann, dass ein paar Wochen nach dem iOS Update, 90% der User bereits auf die neue iOS Version migriert sind.

    Möchtest Du aber noch alte iOS Versionen berücksichtigen, da gebe ich Dir recht, da wirst wohl noch warten müssen, bis diese ausgestorben sind. Bspw. 32Bit, iOS 12…

    Bezüglich Flexibilität: Wenn Du ein abstrahierendes Framework verwendet, um weniger Arbeit zu haben, bist du immer an die Möglichkeiten des Frameworks gebunden. Wenn Du frei sein möchtest, hast Du die meisten Möglichkeiten und Flexibilität wenn Du Low-Level Funktionen verwendest und Dir dein eigenes Framework aufbaust. Ich für meinen Teil, habe entschieden, dass das für mich zu viel Arbeit ist und verwende daher ein entsprechendes Framework.

    Damals als ich mich hier mit iOS zum ersten Mal auseinander setze, habe ich mit UIKit begonnen und mit Storyboards. Die haben mich fast zum Wahnsinn getrieben, da ich bestimme Funktionen einfach nicht zum laufen brachte. Mit SwiftUI 1.0, gab es zwar auch entsprechenden Wahnsinn, der Unterschied war jedoch, dass man nach ein paar Tagen einen lauffähigen Workaround hatte, der dann zur Zufriedenheit lief, was unter UIKit nicht der Fall war.

    Jetzt denken wir doch mal an den TO zurück, welcher seine ersten Schritte in iOS UI Entwicklung gehen möchte. Er wird wohl die erste Zeit ziemlich Lehrgeld bezahlen und auch einige Schweissausbrüche bekommen. Bis er dann so weit ist, dass er seine ersten Apps in den AppStore veröffentlichen kann oder möchte, wird wohl iOS 17 und SwiftUI 5 mindestens auf seiner Maschine sein. Daher denke ich, dass er hier nicht wirklich an alten Zöpfen festhalten muss, sondern gleich zukuftsgerichtet sich auf die Architektur, welche in 5 bis 7 Jahren dominierend sein wird, sich einarbeiten kann.
  • Wolf schrieb:

    Jetzt denken wir doch mal an den TO zurück, welcher seine ersten Schritte in iOS UI Entwicklung gehen möchte.
    Guter Punkt: Möchte er das?

    @Paul___Paul: Ich vermute zwar auch, dass es Dir um iOS-Entwicklung geht - irgendwie scheint kein Mensch mehr für macOS zu programmieren? Du hast die Plattform nirgendwo erwähnt und ich habe den Eindruck, bei der Entscheidung für oder gegen SwiftUI könnte dies relevant sein.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MyMattes schrieb:

    Wolf schrieb:

    Jetzt denken wir doch mal an den TO zurück, welcher seine ersten Schritte in iOS UI Entwicklung gehen möchte.
    Guter Punkt: Möchte er das?
    @Paul___Paul: Ich vermute zwar auch, dass es Dir um iOS-Entwicklung geht - irgendwie scheint kein Mensch mehr für macOS zu programmieren? Du hast die Plattform nirgendwo erwähnt und ich habe den Eindruck, bei der Entscheidung für oder gegen SwiftUI könnte dies relevant sein.
    Gut, war etwas unpräzise ausgedrückt. Das iOS ist zu streichen. Um was es hier geht, betrifft eigentlich alle Plattformen von Apple gleichermassen (hier mal ein Beispiels von macOS: developer.apple.com/documentation/swiftui/table).

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Wolf ()

  • MyMattes schrieb:

    bin aber noch in den Abwärtskompatibilitäten gefangen und scheue den Mehraufwand des Umstiegs.
    Nicht so schlimm. Gehen wir mal von einer Unterstützungszeit von 6 Jahren für das OS aus (wie von der EU vorgeschlagen). Dann sind es 4 bis 5 Jahre, wo das dann relevant wird. Denn mit SwiftUI 1.0 oder 2.0 würde ich bei einer App (mit Unterstützung der abwärtskompatibilität) nicht starten. Das heisst, zur Pflege der Altapplikationen würde ich in ca. 2 Jahren damit beginnen mich in neues einzuarbeiten und dies dann in ca. 4 Jahren dann über den Wartungsmodus verteilen, falls man keinen Schnitt machen möchte (was aktuell doch etliche Applikationen tun).
    Für Neuentwicklungen, oder wenn man keine Angst hat alte Zöpfe abzuscheiden, denke ich, dass es jetzt Zeit wäre sich in SwiftUI 3 einzuarbeiten, damit man diese dann ab 2023 (wenn iOS 16 oder iOS17 draussen ist) dann auf den Markt werfen kann.

    Wenn man Neuerungen für diesen Zeithorizont entwickelt, kann man diese auch jetzt schon einfliessen lassen, denn wie oben gesagt, alles funktioniert mit allem, ob jetzt OC oder Swift, oder UIKit mit SwiftUI. Hier muss man nicht etwas tun ohne das andere zu lassen.
    Wie MCDan anmerkte, es kommt halt drauf an, welche letzte Version man noch unterstützen muss (oder möchte). Insgesamt sind die iOS User aber sehr updatefreudig, aber ab und an, schiebt hier halt auch Apple einen Riegel vor (siehe 32Bit oder iOS 12, gleiches natürlich auch bei macOS), wenn man die User nicht zurücklassen möchte, dann muss man (ob man will oder nicht) eben rückwärts Kompatibel sein.
  • Wolf schrieb:

    MCDan schrieb:

    Genau wie ersten Versionen von Swift, scheint sich SwiftUI immer noch in der Grund Konzept-/Entwicklungs-Phase zu befinden.
    Das Grundkonzept von SwiftUI ist seit Version 1.0 gleichgeblieben. Da gab es bislang keine Anpassungen.
    Zum "Grundkonzept" eines UI Systems würde es für mich jedoch auch gehören, dass eine entsprechende Menge UI Elemente mit der ersten Version vorhanden sind, so dass sich damit ein Großteil von Apps verwirklichen lassen.

    Die Versionen 1 und 2 von SwiftUI sehen für mich noch nach beta Versionen eines UI Systems aus. Damit kann man dann mal in das Konzept dieses UI Systems hineinschnuppern und auch mal eine einfach gehaltene App realisieren.

    Ich werde SwiftUI jedoch weiter beobachten und bin gespannt, ab wann ich es für neue oder bestehende Projekte einsetzen kann.

    Gibt es gute Beispiele/Tutorials/Dokus zur Verwendung von NSFetchedResultsController in Kombination mit SwiftUI oder gibt es dafür ein neues/anderes Konzept unter SwiftUI?
  • Grundkonzepti ist die deklarative UI Entwicklung, das hat nichts mit der menge der zur Verfügung gestellten UI Controlls zu tun.

    Der NSFetchrequest, lebt in Gestalt eines Property Wrappers:

    Quellcode

    1. @FetchRequest(
    2. entity: User.entity(),
    3. sortDescriptors: [
    4. NSSortDescriptor(keyPath: \User.name, ascending: false),
    5. ],
    6. predicate: NSPredicate(format: "surname == %@", "Hudson")
    7. ) var users: FetchedResults<User>
    Wenn Du diesen jedoch in deinen Controller verwenden möchtest, musst Du auf deinen bisherigen Code, im Controller, zurück greifen..l

    hoer mal ein Beispiel, einer der ersten Einträge aus Google ;) andrewcbancroft.com/blog/ios-d…use-fetchrequest-swiftui/

    im übrigen gibt es den PropertyWrapper für den NSFetchedResultsController seit SwiftUI 1

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Wolf ()