Swift-Rookie: Unwrapping Optionals

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

  • Swift-Rookie: Unwrapping Optionals

    Hallo zusammen,

    Ich bitte um Nachsicht: Momentan versuche ich die Besonderheiten und deren Termini von Swift zu verstehen und scheitere schon an den Basics: Das Prinzip der Optionals habe ich (hoffentlich) verstanden, aber in Zusammenhang mit einem @IBOutlet verstehe ich nicht das Unwrapping. Könnte mir eine*r von Euch Swifties checken, ob das folgende Verständnis stimmt wann man welche der nachfolgenden Varianten benutze würde? Hier einmal mein Verständnis:

    Hier würde der Code bei der Zuweisung crashen, wenn das UILabel null wäre:

    Quellcode

    1. @IBOutlet weak var label: UILabel?
    2. label!.text = passedText
    Identisch hier mit dem Unterschied, das man das Unwrapping nicht jedesmal beim Referenzieren des Labels mitschreiben müsste

    Quellcode

    1. @IBOutlet weak var label: UILabel!
    2. label.text = passedText
    Und hier der sichere Weg mit Optional Binding

    Quellcode

    1. @IBOutlet weak var label: UILabel?
    2. if let tempLabel: UILabel = label
    3. {
    4. tempLabel.text = passedText
    5. }
    Stimmt mein Verständnis (und die Begrifflichkeit)? Was wäre nun der "richtige" Weg? Ich würde eigentlich zum dritten tendieren, aber da ein nicht verbundenes @IBOutlet ja mein Fehler zum Entwicklungszeitpunkt wäre, brauche ich ja eigentlich keine Prüfung zur Laufzeit beim Benutzer ... das spräche für (1.) oder (2.).

    Danke für Eure Hilfe, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Der dritte Weg ist der sichere Weg, der im Allgemeinen richtig ist. Aber es gibt natürlich Ausnahmen.

    Outlets sind eine Ausnahme, nicht in technischer sonder in logischer Hinsicht. Die Funktionen deiner Komponente sind in der Regel nur mit geladenem View sinnvoll, und dann sollten alle Outlets gesetzt sein. Wenn eines nicht gesetzt ist, ist das in der Regel ein grober Fehler, weil alle Outlets beim Laden des Views gesetzt werden.

    Ein nicht gesetztes Outlet rechtfertigt in der Regel sogar einen Programmabsturz, weil da etwas Grundsätzliches schief gelaufen ist.

    Es gibt natürlich für diese Ausnahme auch wieder Ausnahmen, z.B. Controller, die mehrere Views laden.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    Mit SwiftUI mache ich erst mit Big Sur weiter. Momentan ist das noch etwas unvollständig.
    Ich hab nur einen ersten Blick drauf geworfen aber ist es echt so viel besser nun? Kann man jetzt einen Collection View machen, der Drag and Drop unterstützt? TabBarController?

    Das schien mir (leider) alles noch ein wenig unvollständig, auch wenn wir das Storyboard mit seiner Performance mittlerweile sehr nervt.
  • Also wenn Du mit SwiftUI schaffst, brauchst kein Storyboard mehr. Wenn Du dennoch UIKit willst, kannst es dir auch so einbinden. Ich würde kein neues Projekt auf der veralteten Technik aufsetzen. Wenn hier und da Lücken sind, dann halt ergänzen.

    Tabbar Controller gibts seit SwiftUI 1, das war also noch nie ein Problem, und der funktioniert gut. Seit SwiftUI 2 werden auch Collectionviews unterstützt, ob mit Drag/Drop kann ich nicht sagen, da ich diese noch nicht im Einsatz habe.

    SwiftUI läuft prinzipiell auf allen Plattformen, mit SwiftUI 2, wurden halt Kompatiblitätschichten eingezogen. Kannast also schon jetzt anfangen für big Sur zu entwickeln. Da musst nicht warten.

    @To: es gibt auch noch weitere Möglichkeiten. Du willst ja was initialisieren, weshalb nicht so?

    Quellcode

    1. @IBOutlet weak var label: UILabel?
    2. label = passedText ?? “”
  • Wolf schrieb:

    @To: es gibt auch noch weitere Möglichkeiten. Du willst ja was initialisieren, weshalb nicht so?
    Nein, ich hatte oben den Code nur auf die für meine Frage relevanten Statements verkürzt: Konkret mache ich die Zuweisung des Label-Textes in viewDidLoad (als Folge einer Segue), während das Property des @IBOutlet schon früher initialisiert wird.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • das macht nix, mit dem ?? operator sagst du nur, wenn das erste argument nil ist, setz das zweite ein. da musst nicht via if let gehen...

    ansonsten ist meist guard let vorzuziehen, da das let noch in der gesamten funktion zur verfügung steht

    oder geht es dir um das Label Argument? dann sollte zumindest das folgende Statement im Code enthalten sein:

    Quellcode

    1. guard label != nil else { return }


    Insbesonder ist vor dem Einsatz des Crash Operators (!) abzuraten. den darfst nur in abgesicherten Konstellation zum Einsatz bringen

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

  • AppleDeveloper schrieb:

    macmoonshine schrieb:

    Mit SwiftUI mache ich erst mit Big Sur weiter. Momentan ist das noch etwas unvollständig.
    Ich hab nur einen ersten Blick drauf geworfen aber ist es echt so viel besser nun? Kann man jetzt einen Collection View machen, der Drag and Drop unterstützt? TabBarController?
    Das schien mir (leider) alles noch ein wenig unvollständig, auch wenn wir das Storyboard mit seiner Performance mittlerweile sehr nervt.
    es fehlen einfach zur Zeit noch zu viele Standardelemente. Einige sollen zumindest in macOS 11 kommen. Bei einigen Elemente, z.B. hidden-Modifier, hat Apple anscheinend auch nicht so ganz nachgedacht.

    Alles in allem ist SwiftUI als Beschreibungssprache aber schon ganz nett.
    „Meine Komplikation hatte eine Komplikation.“