Suchergebnisse

Also wenn es Dir darum geht, für die Zukunft gerüstet zu sein, dann empfehle ich Dir diesen blog Eintrag von Uncle Bob Martin: blog.cleancoder.com/uncle-bob/2016/09/01/TheLurn.html Seine Weiterbildungsempfehlungen sind völlig unabhängig von Programmiersprachen oder Tools. Mit welcher Programmiersprache auch immer auf dem Laufenden zu sein, ergibt sich doch von selbst, wenn Du damit arbeiten musst. Zu Swift: ist nach wie vor ein moving target, imho.

Viele Sachen an Swift finde ich sehr nett (block-syntax, structs, generics, die standard library etc), aber die ständigen Code-breaks (insbesondere bei den dependencies in Ermangelung eines stabilen ABIs) halten mich noch davon ab. Und ich muss sagen, seit ich mich einmal an AppCode gewöhnt habe, ist es ein Graus, mit Xcode zu arbeiten. Man weiß nicht, was eigtl. möglich ist, wenn man nie eine IDE mit solch großartigem Refactoring benutzt hat. Wäre schön, wenn Apple sich da mal ein bisschen insp…

Also was mich ganz unabhängig von irgendwelchen immer wieder neuen Säuen, die gerade vom Swift-Team durchs Dorf getrieben werden, davon abhält, auf Swift umzusteigen, ist die unfertige (um nicht zu sagen kaputte) Toolchain. Richtig geil ist das Refactoring in Xcode (geht nach wie vor nur mit Objective-C, aber auch das ist unbrauchbar). Wenn Apple doch nur 1% der Swift Ressourcen in das Refactoring stecken würde... Objective-C mag in die Jahre gekommen sein, aber es ist simpel, es gibt AppCode un…

Da bin ich ganz bei Dir. Es gibt sogar ein sehr schönes WWDC Video von 2014 dazu, eine der seltenen Stellen, an denen Apple mal selbst was über Architektur erzählt: developer.apple.com/videos/play/wwdc2014/232/ Um das noch etwas zu präzisieren: der VC ist ein Controller, der aber näher an der Viewschicht steht, als z.B. die Cocoa-NSObject/ArrayController oder der traditionelle MVC-Controller.

so wie Apple es umsetzt, hat der VC klare Zuständigkeiten für das View (s.o.). Da das Ding trotzdem auch Controller im Namen hat, ist die Versuchung groß, da alles mögliche reinzuklatschen, Stichwort Massive View Controller.

Das könntest Du mit einem Script und fastlane machen. Bei mir funktionierten aber bei direkt vom Server hochgeladenen Archives die Xcode-crashlogs nicht mehr, daher habe ich es nicht weiter verfolgt und lade dass immer manuell über iTunes Connect hoch. Nervig und nicht nachvollziehbar, aber wieder das alte Lied...Apple & Software (in diesem Zusammenhang lustig, dass auch Xcode 8 dem Hörensagen nach immer noch kein Refactoring von Swift unterstützt. Andererseits ist das Xcode-Refactoring eh Müll.…

Meiner Meinung nach gehört der VC eindeutig zur Viewschicht, sagt ja der Name schon und Du hast ja selbst auch schon ein paar gute Argumente dafür gebracht: (viewDid... etc). Businesslogik würde ich in separate Objekte packen und diese dann im VC benutzen. Der VC sollte sich wirklich nur um die Verwaltung des Views kümmern. Hier noch ein Link zu einer pdf zu einem Cocoaheads-Vortrag: github.com/hydrixos/cocoaheads…b/master/2014/11/Talk.pdf

M.m.n. ist es ein großes Problem, dass die Kinder mit zu viel Stoff in der Schule zugeschmissen werden. Die Lehrerin meiner Tochter nannte das mal schön "Bulimilernen". Wenn ich mich an meine Schulzeit zurück erinnere, hatten wir an den Nachmittagen weitaus mehr Zeit als es heute der Fall zu sein scheint. Für Hobbys, Sport, draußen rumstromern oder einfach gammeln. Teilweise haben die Kindern zumindest ab den höheren Klassen einen längeren Tag als wir arbeitenden Erwachsenen. Schule sollte kriti…

Zitat von macmoonshine: „Zitat von gritsch: „naja, das einzige das sich bei mir ändert sind mails und sourcecode. mails hab ich auf beiden rechnern dank IMAP und den sourcecode hat man ja eh im versionsmanagment und kann es einchecken und auschecken wie man grad lust und laune hat. es hängt ja aber auch davon ab was man unterwegs überhaupt machen will mit dem rechner. sitzt man sich mit dem ding in den zug zum arbeiten oder braucht es nur mal um eine spezielle testversion zu builden oder was zu …

Ja, eine abstrakte Klasse und Mehrfachvererbung sind in der Tat die C++-Äquivalente zu Protokollen. Ich verstehe aber immer noch nicht, warum es mit meiner oben vorgeschlagenen Variante nicht gehen soll? Du möchtest ja schließlich Adressaufkleber von Personen drucken - es sollte also eine wie auch immer geartete Verbindung Person<->Adresse geben. Zu dem C++ Buch aus der Steinzeit: mit C++11 und C++14 hat sich vieles an der Sprache zum besseren geändert, wenn man bei C++ von so etwas wie Verbesse…

Also für mich hört sich das nach ganz konventionellem OO-Zeug an. Da Du ja Adressaufkleber von Personen drucken möchtest, sollte Person auf jeden Fall eine Methode besitzen, die eine Adresse zurückgibt. Welche das ist, entscheiden die konkreten Subklassen. Ergo: virtuelle Methode in Person: Zitat von Marco Feltmann: „class Person { protected: String name; PhoneNumber telefon; MailAddress email; public: /* Getter, Setter, Konstruktoren, Destruktoren... */ virtual ~Person(); // siehe Scott Meyers …

Wieso sollte das "CoreData-unlike" sein? Völlig Doku-Conform und auch der richtige Weg, um in relationships zu suchen.

Ja und ja!

Apple und Software...

Aus eigener leidvoller Erfahrung kann ich Dir folgendes empfehlen: benutze das simpelste Design als möglich. Aufräumen oder irgendwelche cleveren Optimierungen kannst Du später machen, wenn Du mehr über das Problem weißt und Profiling Performance-Engpässe zeigt. "Make it work, make it right, make it fast". In der Reihenfolge.

Klappt bei mir ebenfalls nicht automatisch in Xcode wenn ich die Archive vom Xcode-Buildserver benutze. Mit direkt von der Entwicklermaschine hochgeladenen Builds klappt es tadellos. Das mag für Einzelkämpfer noch gehen, führt aber die Export Archive-Funktion des CI Servers ad absudum...Apple und Software eben

Ja, hab den Thread auch nur kurz überflogen. Kommt halt auf die policies an: wenn nur quasi die properties extrahiert werden mag das noch gehen (würde ich dann aber in eine Kategorie packen), aber schon sowas wie dubletten rausfiltern kann dann schnell in SRP und ISP-Verletzung ausarten. Mit einer extra Exportklasse hältst Du die Sachen schön getrennt und exponierst den export-Code nicht an die normalen Klienten Deiner MOs.

Also ich würde das nicht in die MO-Subklassen packen, denn da gehört es nicht hin. Ein dictionary kriegst Du ja über dictionaryForKeys oder so ähnlich, bin gerade unterwegs. Schreibe Dir einen eigene Exporter, der sich dann um alle constraints (dubletten, Umwandlung von Werten) etc kümmert. So hast Du klare Zuständigkeiten und kleisterst Dir Deine MOs nicht zu.

Naja, eigentlich ein phantasievoller Ort fürs obfuscating SCNR...

Du kannst ja das gemeinsame Verhalten der Kategorie in eine separate Klasse packen und diese dann jeweils in der UITextField und UITextView Kategorie benutzen. Die Kategorien sind dann lediglich Wrapper.