DualGrades

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

  • Hallo,

    wir haben seit ein paar Wochen Theoriephase an der Uni. Weil dies bisweilen sehr langweilig ist dachte ich ich lerne mal etwas Swift. Daraus ist eine kleine App entstanden. Sie ist noch nicht ganz ausgereift deswegen würde ich mich über Feedback freuen.

    Was macht die App?
    Mit Dual Grades kann man einfach seine Noten, die man in der Uni bekommt eintragen und bekommt dann gleich noch eine Statistik Funktion. Also erstmal ganz primitiv.

    Warum kam ich auf die Idee?
    Es gab bisher im App-Store nichts, was mir dies zufriedenstellend machen konnte. Es gab zwar ein paar Stundenplan Apps aber 99% davon konnten schon mal nicht einen wöchentlich wechselnden Stundenplan eintragen. Weiterhin habe ich nirgends gefunden, dass man eine iCal importieren kann. Und das alles manuell einzugeben war mir aufwendig, vor allem da sich das manchmal mehrfach in der Woche ändert. Also habe ich den Stundenplan einfach in die Kalender-App also Abo importiert und mir eine einfache App für die Notenberechnung geschrieben. Dafür bot es sich an mal Swift anzusehen.

    Realisierung:
    Swift war für mich ganz neu. Ich hatte damals mal Swift 1 angeschaut aber dann es nicht weiter verfolgt, weil ich davon nicht viel gehalten hatte. Jetzt mit Swift 3 schien es mir mal angebracht dem ganzen mal eine Chance zu geben. Man muss sagen am Anfang waren einige Sachen sehr ungewohnt besonders:
    • die Optionals
    • die Deklaration von Arrays
    • let und var
    • die Nutzung von CoreData


    Aber nach einer Weile hatte man sich da dran gewöhnt und wenn ich ehrlich bin, will ich es nicht mehr missen. Besonders genial fand ich das Konzept von Optionals. Das kann man in Objective C nicht so einfach und schnell lösen:
    Bei der Eingabe eines Semester sollte es eine Zahl sein. Also versuche ich den String in eine Zahl umzuwandeln. Wenn das fehlschlägt kann man ja ganz einfach über ?? sagen welcher Wert anstelle genutzt werden soll. Das fand ich genial und es hat in einigen Stellen im Code dann Anwendung gefunden.

    CoreData zu Nutzen war auch am Anfang etwas anders für mich. Besonders wie ich den Managed Object Context ran bekomme war für mich etwas komisch aber man gewöhnt sich dran.

    Fazit:
    Wenn man sich an Swift einmal gewöhnt hat will man es echt nicht mehr missen. Wenn man das vergleicht hat man früher in Objective C halbe Romane geschrieben, was man mit wenigen Zeilen in Swift machen kann. Selbst wenn es die selbe Zeilenanzahl ist, dann ist sie in Swift in den meisten Fällen wesentlich kürzer und einfacher zu lesen. Das war auch der Grund, warum ich es mal ausprobiert hatte. Ein Kollege von mir kann nur Swift und konnte nie verstehen, warum ich immer in Objective C halbe Bücher schreibe mit zig Klammern obwohl es in Swift ganz einfach und schnell geht. Ich kann es jeden Empfehlen mal zu probieren!

    Hier der App-Store Link: DualGrades

    Viele Grüße
    Nils

    PS: Auch über Feedback wie man die App für andere Unis noch anpassen kann würde ich mich sehr freuen. Ich glaube bei uns Rechnen wir etwas anders.
  • Mac & i Test Abo
  • AppleDeveloper schrieb:

    ... wesentlich kürzer und einfacher zu lesen.
    Die Kernfrage ist, ob es für jemand fremden auch einfacher zu lesen ist oder nur für den Autor.
    APL beispielsweise ist extrem kurz und für einen Eingeweihten gut lesbar (der auch noch weiß, was der Code eigentlich tun soll), aber für niemand sonst.

    Da ich mich bisher nicht besonders mit Swift beschäftigt habe, bleiben mir die Codebeispiele, die ich hier im Forum finde, meist unverständlich. Vor allem dass in jeder zweiten Zeile "let" steht (da denke ich mir: warum muß man das so oft hinschreiben wenn es der Regelfall ist?). Während ich mit fremdem Obj-C-Code nie Probleme habe. Der ist zwar öfters "ein Roman", aber fast in Umgangssprache [subjekt prädikat:objekt]. An die Klammern gewöhnt man sich m.E. genauso, wie Du schreibst dass man sich an let und var gewöhnt.

    D.h. man muß m.E. die Lesbarkeit für sich selbst und die Lesbarkeit für Dritte klar trennen.

    Aber das könnte ja alles daran liegen dass ich die Sprache nicht kenne. Aber es könnte auch ein Grundsatzproblem sein. Ist Swift-Code Deiner Ansicht nach für einen Dritten, der den Algorithmus nicht kennt (aber die Sprache), leichter zu verstehen als Obj-C-Code (wo der Dritte die Sprache ebenfalls gut kennt)?
  • hns schrieb:

    Ist Swift-Code Deiner Ansicht nach für einen Dritten, der den Algorithmus nicht kennt (aber die Sprache), leichter zu verstehen als Obj-C-Code (wo der Dritte die Sprache ebenfalls gut kennt)?
    Ich finde nicht unbedingt. Alleine schon die Tatsache, dass man aufgrund von type-inference den Typ bei einer Variablendeklaration weglassen kann, macht's oft unübersichtlich. Vor allem, wenn Du den Typ des Rückgabewertes einer Methode gerade nicht im Kopf hast (bei mir also immer :D ).

    Eine Konstrukte sind auch, so finde ich, syntaktisch zu aufgeladen (z.B. enums). Aber, bei aller Kritik: Wenn Swift mal stabil ist und man nicht mehr alle 3 Monate ein Refactoring durchführen muss, kann man (ich) sicherlich schnell und gut damit arbeiten. Mir persönlich wäre aber ein Objective-C 3.0 lieber gewesen. Aber das Leben ist halt kein Ponyhof
  • hns schrieb:

    Aber das könnte ja alles daran liegen dass ich die Sprache nicht kenne. Aber es könnte auch ein Grundsatzproblem sein. Ist Swift-Code Deiner Ansicht nach für einen Dritten, der den Algorithmus nicht kennt (aber die Sprache), leichter zu verstehen als Obj-C-Code (wo der Dritte die Sprache ebenfalls gut kennt)?
    Danke für deine Antwort! Als meiner Meinung nach ist Swift-Code einfacher zu verstehen. Also ich konnte mich z.B. schneller in den Code meines Kollegen reinlesen als in einen vergleichbaren Objective C Code. Aber es kann auch sein, dass es mir so vor kommt da das nur an einen kleinen Macbook Air Bildschirm war und da kurze Zeilen und ohne Klammern da einfach schneller zu erfassen sind. Vorher fand ich die hier im Forum geposteten Zeilen auch immer komplizierter aber wenn man sich erstmal damit beschäftigt ist es einfach.

    EDIT: Wie @gandhi sagt könnte es bei enums oder ähnlichen schon schwieriger werden. Aber bei Sachen die man täglich braucht geht es eigentlich.
  • Als Einsteiger in iOS muss ich sagen, dass ich den ObjectiveC Code als Katastrophe empfinde, der swift Code ist zwar ein riesen vehau, aber um einiges besser zu lesen und zu verstehen wie ObjectiveC. Daher schaue ich über ObjectiveC grosszügig hinweg und hoffe, dass swift noch vernünftige Strukturen bekommt und aufgeräumt wird, damit man mal damit arbeiten kann :)

    Aber ich gebs zu, auch andere Sprachen haben ihre Fauxpässe und eine die wie aus einen Guss ist und einfach nur begeistert habe ich bislang noch nicht kennenlernen dürfen.

    Schöne Grüße
    Wolf