Suchergebnisse

Aber die User-Klasse hat doch eine Referenz auf ein Bankobjekt. In Deinem Test setzt Du da die fürs Testtarget erstellte Banksubklasse, in der Du die erwarteten Methoden überschreibst und für den Test entspr getter implementierst, a la xyz-invoked

Ja, ähnliche Erfahrungen habe ich auch damit gemacht. Mal überlegt, ein Support-Ticket zu nutzen?

Na klar geht das. Einfach eine Klasse BankAccountSpy per DI verwenden. Diese ist eine BankAccount-Subklasse, mit der Du den erwarteten Aufruf prüfen kannst. Plain-old OO... Beste Grüße, Markus

Haste mal mit self sizing cells probiert?

Broken by design...Machs mit dem Delegate wie von macmoonshine empfohlen

Irgendwann letztens wurde hier der Link zur Doku gepostet, dass es nun erlaubt ist, einen splitview-VC z.B. in einen Tabbar-VC einzubinden. Ich mache das selber so und es klappt ohne Probleme.

Das ist eben der Mist an Storyboards. Du hast durch die Seques eine Kopplung der VCs untereinander, auch wenn die überhaupt nichts voneinander wissen sollten. Am schlimmsten finde ich dann die stringly-typed if/else Wüsten in prepareForSeque. Es ist zwar für einfache Fälle schön, sich nicht um die Instanzierung der VCs kümmern zu müssen, aber Du hast eben dann nur den prepareForSeque-Pfad und musst im aufrufenden VC u.U. eigtl unnötigen Mist vorhalten. Von Testability jetzt mal zu schweigen... <…

Axo. Hab noch nie Appextension geschrieben, aber gibt's da nicht so einen Kommunikationskanal zwischen Extension und App?

Und wenn Du versuchst, die Schreibzugriffe per XPC zu synchronisieren zwischen App und Extension?

Um Macmoonshines Antwort noch etwas zu konkretisieren: schreib Dir Tests, die das erwartete Verhalten betreffen, also Sortierung, erwartete Werte (dictionaries vs MOs vs Object-ID) usw. Das kannst Du z.B. mit einem inmemorystore fürs Testen machen. Genauso speichern, Migration usw. Dann hast Du die "gefährlichen" und für den User sichtbaren Fälle schonmal abgedeckt. Wenn dann tatsächlich Fehler beim User auftreten, nimm die Error Ausgabe mit ins crashlog rein.

Können wir bitte zum Thema zurück kommen?

Zitat von gritsch: „Zitat von t-no: „Zitat von gritsch: „nein eben nicht. bloß keine schnittstellen reinbringen für drittplugins denn das endet immer in einer katastrophe “ Solche Aussagen verwirren mich:Dann ist es also besser, wenn sich die Leute ihre Plugins via reverse engineering zusammenfrikkeln?Wie soll irgendjemand gezwungen werden, ein Plugin zu benutzen? Oder gibt es irgendeine mystische Kraft, die dafür sorgt, dass die bloße Existenz von Plugins Abstürze verursacht? Ist Photoshop (um …

Am Mac nutze ich den IB sehr viel, da aber nur xibs, keine Storyboards. Unter iOS das meiste im Code und ab und an xibs, Storyboards zwingen mir ein Konzept auf, welches nicht gut zu meinen Vorlieben passt. Autolayout nutze ich extensiv, aber ebenfalls im Code, im IB ist es mir zu lästig, ständig mit irgendwelchen Bugs oder nicht aktualisierten Frames zu kämpfen. Das was der IB da eigtl verspricht, hält er für mich nicht...

Das kannste ganz leicht selber bauen: Einfach ein custom-view mit nem Gradienten als Hintergrund: Quellcode (6 Zeilen)Kannste natürlich alles noch ausbauen, indem Du start- und end-Farbe des Gradienten als properties im view definierst usw. Dieses View schmeisst Du dann im IB dahin, wo Du es brauchst, die filter-row ist eine stinknormale NSMatrix. Kannst da aber auch beliebige buttons oder sonstige views reintun. Beste Grüße, Markus

Ich meine mit Struktur des Codes nicht die Einrückung etc., sondern die Codehygiene. Also ab dem 2. Teil von "make it work, make right, make it fast". Die API bleibt gleich und alles dahinter aufräumen ist Refactoring. Braucht man natürlich Tests, denn erst die ermöglichen überhaupt Refactoring.

Zwischen dem Refactoring von AppCode und Xcode liegen Welten. Kann da macmoonshine nur zustimmen, auch was das Refactoring betrifft: ändern der Struktur ohne Änderung der Funktionalität, dh alle Tests blieben grün nach jedem Refactoring.

Tröstet Euch, für obj-c gibts ja auch keine Refactoringtools in Xcode...(das was sie unter dem Menüpunkt Refactoring anbieten, ist jedenfalls unbrauchbar). Die sollen einfach AppCode lizensieren da sie es anscheinend selber nicht hinbekommen.

Also bei mir hat die Transition geklappt, sowohl Mac als auch iOS target in einem Workspace und alle jeweiligen Test-Targets funktionieren. Hast Du irgendwelche Änderungen an der Xcode-config, Pods? Mal ein clean gemacht oder den DerivedData-Ordner gelöscht?

Mal als childviewcontroller (embed seque?) probiert?

Wie wärs denn mit developer.apple.com/library/io…paratedByCharactersInSet: ?