Änderung von Swift 1.0 zu Swift 2.0

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

  • Änderung von Swift 1.0 zu Swift 2.0

    Hallo liebe Gemeinde,

    ich hab da ein kleines Problem und find einfach die Lösung nicht.
    Vlt hatte auch schon jemand diese Probleme und kann mir etwas unter die Arme greifen.

    Hier das Stück Code was mir Probleme bereitet:

    C-Quellcode

    1. func loadDataFromFile() {
    2. let dirs = NSSearchPathForDirectoriesInDomains(.DocumentDirectory , .UserDomainMask, true)[0] as NSString
    3. let path = dirs.stringByAppendingPathComponent("kunden.csv")
    4. if path {
    5. var tempString = String(contentsOfFile: "String", encoding: NSUTF8StringEncoding, error: "NSErrorPointer")
    6. daten.removeAll(keepCapacity: false)
    7. let lines = tempString.componentsSeparatedByString("\n")
    8. if lines {
    9. for datensatz in lines {
    10. if datensatz == "" {continue}
    11. let parts = datensatz.componentsSeparatedByString(",")
    12. daten += Kunden(bauvorhabennr: parts[0], bearbeiter: parts[1], kundennr: parts[2], kundenname: parts[3], vorname: parts[4], strasse: parts[5], plz: parts[6], stadt: parts[7], telnr: parts[8])
    13. }
    14. }
    15. print("Daten geladen")
    16. }
    17. else {
    18. print("Laden fehlgeschlagen")
    19. }
    20. }
    21. @IBAction func saveButtonPressed(sender: AnyObject) {
    22. var tempString = String()
    23. for kunden in daten {
    24. tempString += "\(kunden.bauvorhabennr),\(kunden.bearbeiter),\(kunden.kundennr),\(kunden.kundenname),\(kunden.vorname),\(kunden.strasse),\(kunden.plz),\(kunden.stadt),\(kunden.telnr),\n"
    25. }
    26. let dirs = NSSearchPathForDirectoriesInDomains(.DocumentDirectory , .UserDomainMask, true)[0] as NSString
    27. let path = dirs.stringByAppendingPathComponent("kunden.csv")
    28. if path {
    29. tempString.writeToFile(path, atomically: true, encoding: NSUTF8StringEncoding)
    30. print("Daten gesichert")
    31. }
    32. }
    Alles anzeigen
    In der Zeile 4 meckert Xcode: Type 'String' does not conform to protocol 'BooleanType'
    In der Zeile 8 meckert Xcode: Type '[String]' does not conform to protocol 'BooleanType'
    In der Zeile 12 meckert Xcode: Binary operator '+=' cannot be applied to operands of type '[Kunden]' and 'Kunden'
    In der Zeile 29 meckert Xcode: Call can throw, but it is not marked with 'try' and the error is not handled

    Ich habe das aus einem Tutorial von YouTube von 2014 und ich denke mal das es Änderungen gab zu Swift2.0 und ich diese einfach nicht finde im Internet, manche sachen konnte ich schon erledigen weil man in den Kommentaren schon auf änderunge hingewiesen hat aber hier halt nicht :(

    Wegen dem Dateiformat(Endung), das möchte ich später noch als JSON ändern, ich möchte hier nur Testen und lernen! Deshalb bitte ich um Hilfe!!!

    LG matze

  • Zunächst einmal, wir sind inzwischen bei Swift 2.2, was weitere Änderungen gebracht hat.

    Zu den Zeilen 4 und 8:
    Wie Xcode schon anmerkt, muss der Ausdruck hinter dem if etwas ergeben, was zum Protokoll BooleanType konform ist. Die Zeiten, wo irgendetwas ungleich 0 als wahr interpretiert wird, sind in Swift vorbei. Das Einfachste ist, die Bedingungen so zu formulieren, dass da true/false raus kommt.

    Zu Zeile 12:
    Der Operator += ist nur zur Addition zweier Arrays definiert, nicht um ein Array und ein Element zu addieren. Die Lösung hast du ja schon gefunden.

    Zu Zeile 29:
    Das kommt vom neuen Error Handling.

  • matze511 schrieb:

    C-Quellcode

    1. let lines = tempString.componentsSeparatedByString("\n")
    2. if lines {
    3. for datensatz in lines {
    4. if datensatz == "" {continue}
    5. let parts = datensatz.componentsSeparatedByString(",")
    6. daten += Kunden(bauvorhabennr: parts[0], bearbeiter: parts[1], kundennr: parts[2], kundenname: parts[3], vorname: parts[4], strasse: parts[5], plz: parts[6], stadt: parts[7], telnr: parts[8])
    7. }
    8. }
    Ein paar Anmerkungen dazu:

    1.) Statt mit componentsSeparatedByString("\n") nach einem Zeilenumbruchzeichen zu suchen, besser nach Zeilenumbrüchen suchen, z.B. let lines = str.components(separatedBy: .newlines) (Swift 3.0 Syntax).

    2.) if lines ist nicht nur syntaktisch falsch, wie schon geklärt, sondern überhaupt überflüssig. Wäre lines == nil oder lines.count < 1 dann würde in for datensatz in lines ja eh nichts passieren. ;)

    3.) Was passiert, wenn aus welchen Gründen auch immer parts.count < 9 ist? Richtig. Das Programm schmiert ab. Nicht schön. Wenn Du auf Datenkonsistenz prüfen willst, solltest Du das prüfen.

    4.) Kunden, also Plural, als Klassenname für eine einzelne Instanz eines Kunden ist eine etwas unglückliche Namenswahl.

    5.) Kunden(bauvorhabennr: parts[0], bearbeiter: parts[1], kundennr: parts[2], kundenname: parts[3], vorname: parts[4], strasse: parts[5], plz: parts[6], stadt: parts[7], telnr: parts[8]) als Initializer einer Klasse sieht sehr sperrig aus. 9 (NEUN!) Parameter sind schon sehr ungewöhnlich. Warum nicht das Array in einem Stück übergeben, oder wie wäre es mit einem Optional Initializer der Klasse Kunde, der einen csvEntryString als Parameter bekommt und dann das Parsen selber übernimmt? Z..B sinngemäß:


    C-Quellcode

    1. class Kunde {
    2. init?(csvEntry: String) {
    3. let parts = csvEntry.components(separatedBy: ",")
    4. guard parts.count == 9 else { return nil }
    5. }
    6. }
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:


    5.) Kunden(bauvorhabennr: parts[0], bearbeiter: parts[1], kundennr: parts[2], kundenname: parts[3], vorname: parts[4], strasse: parts[5], plz: parts[6], stadt: parts[7], telnr: parts[8]) als Initializer einer Klasse sieht sehr sperrig aus. 9 (NEUN!) Parameter sind schon sehr ungewöhnlich. Warum nicht das Array in einem Stück übergeben, oder wie wäre es mit einem Optional Initializer der Klasse Kunde, der einen csvEntryString als Parameter bekommt und dann das Parsen selber übernimmt?
    Wenn das Klassenobjekt des Kunden auch noch seine eigenen Parameter parsen muss läuft doch schon mal was gewaltig schief.
    Das Objekt repräsentiert schließlich einen Kunden, keinen Array-/CSV Parser.

    Die wichtige Frage ist doch, warum das nicht zu Anfang einigermaßen normalisiert wurde!
    Auftrag( bearbeiter, Kunde(vorname, nachname, adresse, kontaktdaten) )

    Kundennummer kann sich die Kundenverwaltung selbst vergeben, genauso wie die Bauvorhabennummer beim Anlegen der Daten für das Bauvorhaben automatisch generiert werden kann.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • uh jetzt wird es ganz kompliziert mit Kundenverwaltung und Bauvorhabennummer selbst vergeben, ich glaub soweit bin ich noch garnicht ?(
    Ihr schreib hier was von einer Klasse 'Kunde', ich hoffe ich hab nicht zu wenig Code gepostet, es gibt noch ein Modell "Kunde.swift"


    C-Quellcode

    1. import Foundation
    3. struct Kunde {
    5. var bauvorhabennr: String
    6. var bearbeiter: String
    7. var kundennr: String
    8. var kundenname: String
    9. var vorname: String
    10. var strasse: String
    11. var plz: String
    12. var stadt: String
    13. var telnr: String
    14. }
    Alles anzeigen
    oder hat das damit nichts zu tun?

    @Marco Feltmann der Einwand mit dem Auftrag ist super, da hab ich wohl den Wald vor Bäumen nicht gesehen. Geht ja schließlich nicht um den Kunden sondern um einen Auftrag. :thumbup:

  • Marco Feltmann schrieb:


    Wenn das Klassenobjekt des Kunden auch noch seine eigenen Parameter parsen muss läuft doch schon mal was gewaltig schief.Das Objekt repräsentiert schließlich einen Kunden, keinen Array-/CSV Parser.

    Das sehe ich jetzt nicht so verbissen. In gewisser Weise geht es doch um die Serialisierung und Deserialisierung eines Objektes. Wer, wenn nicht das Objekt selbst, sollte das machen?
    Ist dann auch noch ein bißchen Geschmacksfrage, wie man seinen Code designed... *schulterzuck*
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • Michael schrieb:

    torquato schrieb:

    1.) Statt mit componentsSeparatedByString("\n") nach einem Zeilenumbruchzeichen zu suchen, besser nach Zeilenumbrüchen suchen, z.B. let lines = str.components(separatedBy: .newlines) (Swift 3.0 Syntax).
    Swift 3 ist aber noch gar nicht fertig.

    Sag das nicht so laut. Sonst kommt hier noch einer auf die Idee, zu behaupten, daß Swift eh dazu designed sei, nie fertig zu werden... :D

    Den alternativen Code habe ich mir auf die Schnelle aus einem offenen Swift 3 Playground geholt. 'Swift 3' habe ich dazu geschrieben, um User matze nicht zusätzlich zu verwirren, wenn's bei ihm nicht kompiliert.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Das sehe ich jetzt nicht so verbissen. In gewisser Weise geht es doch um die Serialisierung und Deserialisierung eines Objektes. Wer, wenn nicht das Objekt selbst, sollte das machen?
    Die Klasse des Objekts sollte wissen was serialisiert wird. Das wie sollte sie aber nicht wissen; allein schon aus dem Grund, dass eine Serialisierungsart selten alleine kommt.
    „Meine Komplikation hatte eine Komplikation.“

  • torquato schrieb:

    Marco Feltmann schrieb:

    Wenn das Klassenobjekt des Kunden auch noch seine eigenen Parameter parsen muss läuft doch schon mal was gewaltig schief.Das Objekt repräsentiert schließlich einen Kunden, keinen Array-/CSV Parser.
    Das sehe ich jetzt nicht so verbissen. In gewisser Weise geht es doch um die Serialisierung und Deserialisierung eines Objektes. Wer, wenn nicht das Objekt selbst, sollte das machen?
    Ist dann auch noch ein bißchen Geschmacksfrage, wie man seinen Code designed... *schulterzuck*
    Modularisierung von Software ist ohnehin total überbewertet. Hauptsache, die Sprache ist so flexibel, dass man einen Scheißhaufenoperator definieren kann.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • torquato schrieb:

    Sag das nicht so laut. Sonst kommt hier noch einer auf die Idee, zu behaupten, daß Swift eh dazu designed sei, nie fertig zu werden...
    Fertig werden? Wann ist denn Software fertig?

    Es geht doch erst einmal darum, dass Swift benutzbar ist. Die kleinen Schritte stellen ja schon ausreichend Herausforderung dar.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • torquato schrieb:

    Amin Negm-Awad schrieb:

    Die kleinen Schritte stellen ja schon ausreichend Herausforderung dar.
    *lach*

    Was kann denn Swift dafür, daß sich einige Leute anscheinend von einem Paradigmenwechsel überfordert fühlen..? :D
    Was können die Leute dafür, dass die ursprünglichen Paradigmen offenkundig schlecht waren? (Epische Selbsthudeleien in der "Dokumentation" natürlich hinreichend häufig von Jubelpersern wiederholt.)

    Darf man bei der Entwicklung einer Programmiersprache denn gar nicht mehr erwarten, dass zuerst nachgedacht wird?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Darf man bei der Entwicklung einer Programmiersprache denn gar nicht mehr erwarten, dass zuerst nachgedacht wird?
    Ham se doch, als sie Ruby, Python, C#, C++, GO, RUST, Haskell und Java zusammengeworfen haben.
    Wäre halt nur ein marketingtechnischer Harakiri gewesen, von vorn herein zuzugeben, dass man jeweils das Schlechteste der jeweiligen Sprachen übernimmt.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    Amin Negm-Awad schrieb:

    Darf man bei der Entwicklung einer Programmiersprache denn gar nicht mehr erwarten, dass zuerst nachgedacht wird?
    Ham se doch, als sie Ruby, Python, C#, C++, GO, RUST, Haskell und Java zusammengeworfen haben.Wäre halt nur ein marketingtechnischer Harakiri gewesen, von vorn herein zuzugeben, dass man jeweils das Schlechteste der jeweiligen Sprachen übernimmt.
    Und wenn man sich ansieht, aus was Ruby so alles zusammengewmixt ist, kann einem ja nur richtig schlecht werden. X/
    „Meine Komplikation hatte eine Komplikation.“

  • Hallo liebe Profis,
    kann mir bitte jemand bei dem Error Handling in Swift 2 helfen, ich hab zwar das Buch "Swift 2" aber irgendwie versteh ich nur Bahnhof.

    Ich hab diesen Codesnipsel:

    C-Quellcode

    1. func loadDataFromDB() {
    2. let fetchRequest = NSFetchRequest(entityName: "Auftraggeber")
    3. daten = context.executeRequest(fetchRequest, error: nil) as [Auftraggeber]
    4. tableView.reloadData()
    5. }
    und in zeile 3 sagt mir Xcode immer "Extra argument 'error' in call".
    Kann mir das mal bitte einer verständlich erklären?

    LG matze

  • Ist das so in etwa die richtige Richtung

    C-Quellcode

    1. func loadDataFromDB() {
    2. let fetchRequest = NSFetchRequest(entityName: "Auftraggeber")
    3. do {
    4. // Execute Fetch Request
    5. let daten = try context.executeFetchRequest(fetchRequest) as! [Auftraggeber]
    6. tableView.reloadData()
    7. } catch {
    8. let fetchError = error as NSError
    9. print(error.localizedDescription)
    10. }
    11. }
    Alles anzeigen
    ?