Suchergebnisse

Stimmt, du hast Recht Amin.

Zitat: „Original von Amin Negm-Awad Ich weiß nicht, was deine ständigen Lügen über meine Aussagen sollen. Das ist ja nun nicht das erste Mal.“ Ich möchte dich auf den vorherigen Core Data Thread hinweisen, bei dem du gesagt hast: „und schließlich Apple … [Zitat aus Apple-Dokumentation“ … Aber die haben keine Ahnung.“ Einige Threads davor hast du auch etwas in der Art behauptet, dass du viele Empfehlungen aus der Apple Dokumentation nicht ernst nehmen kannst. Zitat: „Original von Amin Negm-Awad W…

Zitat: „Original von Lucas de Vil Richtig. Core Data ist keine Datenbank.“ Willst du mir damit unterstellen, dass ich nicht weiß, was Core Data ist? Dann darfst du mich auch gleich direkt beleidigen. Core Data verwendet auf dem iPhone nur SQLite (oder den hier uninteressanten In-Memory Store) und das ist sehr wohl eine Datenbank. Egal wie clever Core Data die Handhabung anstellt, die BLOBs landen in einer Datenbank und dort gelten nunmal die gleichen Regeln wie in jeder anderen Datenbank auch (z…

Ich hätte mir das Beispiel jetzt auch sparen können… developer.apple.com/Mac/librar…le_ref/doc/uid/TP40002484 @Apfelbeisser: Eine UUID zu generieren ist einfach: Quellcode (5 Zeilen) @Amin: Ich weiß nicht, was dieser Diskussionsaufwand und das stumpfe Beruhen deinerseits auf „BLOBs gehören in die DB“ jetzt soll? Apple (die laut dir keine Ahnung haben) und jeder vernünftige Mensch, der jemals mit Datenbanken – SQLite eingeschlossen – gearbeitet hat, wird dir empfehlen deine BLOBs nach Möglichkeit…

Quellcode (16 Zeilen)

Zitat: „Original von Amin Negm-Awad Nein, da man keinen SELECT * und auch keinen Fetch macht, werden nicht alle in einem Rutsch geladen. Gerade wenn das wiederum von einer anderen Entität verwiesen wird, wird nur teilweise geladen. (Drei Bilder zu einer Person.) Du kannst die Faults auch häufig explizit im Debugger sehen. “ Wenn du Quellcode (4 Zeilen) machst, dann wird logischerweise spätestens bei Zugriff in der angedeuten Schleife das gesamte Objekt in den Speicher geladen. Wird aus Performan…

Die Änderung in .gitattributes bringt nicht wirklich etwas. Die Dateien sind immer noch viel zu oft zerhauen. Daher weiß ich immer noch nicht, wieso irgendein VCS besser oder schlechter sein sollte als SVN beim mergen der Xcode-Projektdatei. Keiner von denen kriegt das gebacken und das liegt auch nicht an den VCSe’es, sondern an Xcode.

Ich zitiere jetzt noch einmal Apple (weil die sowieso keine Ahnung haben): Zitat: „ It is better, however, if you are able to store BLOBs as resources on the filesystem, and to maintain links (such as URLs or paths) to those resources. You can then load a BLOB as and when necessary. “

BLOBs in Datenbanken (und auch unserer lieben Persistenzschicht Core Data) abzuspeichern, ist ziemlich evil. Schon alleine bei 100 Bildern, die jeweils 100 KB belegen, sind wir bei 10 MB Daten im Speicher bei einem SELECT *. Nun ist Core Data keine Datenbank, aber: Nachdem ich einen fetch gemacht habe und das Ergebnis in einem NSArray ablege, müsste doch auch bei Core Data bereits alles im Speicher sein. Insbesondere die Properties werden standardmäßig in den internen Core Data Cache geladen. Co…

Hat jemand ein Allheilmittel für Konflikte in Xcode-Projektdateien (und wie man diese mit Git am besten löst)? Momentan sieht es so aus, dass wir versuchen Änderungen, die auch die Projektdatei betreffen, abzusprechen. Das ist natürlich absolut blöd, aber das mergen einer Xcode-Projektdatei ist nicht gerade besser. Wie handhabt ihr das, falls ihr im Team mit anderen arbeitet? Git bietet ja tolles Merging an, das bringt aber auch nicht wirklich viel, wenn Xcode einige Nodes wie verrückt in der Da…

Wenn nur die Pfade zu den einzelnen Dateien in Core Data gespeichert werden, spricht doch nichts dagegen?

Bei mir verkorst jedes VCS die Xcode-Projektdatei wenn mehrere gleichzeitig darin rumgepfuscht haben, komisch… Zum Vergleich: whygitisbetterthanx.com/

Zitat: „Original von kressevadder Zitat: „Was ist denn an einem SVN-Merge und einem Git-/Mercurial-Merge der Xcode-Projektdatei anders“ Mit Mercurial funktionierts, mit svn fliegt dir die Kiste um die Ohren. “ Könntest du das jetzt noch ein wenig präziser ausdrücken? Wieso fliegt dir bei SVN die Kiste um die Ohren und bei DVCS’es nicht, gerade im Zusammenhang mit einem Merge der Xcode-Projektdatei?

Ich sage das nächste Mal einfach: „Du machst dir im Core-Data Layout-Editor…“

Zitat: „Original von Apfelbeisser Vorsicht: CoreData ist keine Datenbank! Hat auch nicht mal eine "" verdient.“ Ich weiß, mir ist nur nichts besseres und kreativeres in einem Wort am Abend eingefallen… Burnout :sick: Und Core-Data mit einem vollständigen Satz zu beschreiben, ist auch nicht gerade elegant.

Du machst dir in der Core Data „Datenbank“ eine Entität für die Bilder, die sowohl die URL enthält, als auch den Dateinamen (der am besten eindeutig durch einen Hash-Wert repräsentiert sein sollte). Bei loadImageFromURLString: guckst du erst einmal, ob du das jeweilige Bild aus Core Data (und entsprechend vom Dateisystem) ziehen kannst. Ansonsten machst du wie gewohnt deinen Request. Bei connectionDidFinishLoading: speicherst du zusätzlich das Bild im Dateisystem und legst die Referenz in Core D…

Zitat: „Original von kressevadder Vor allem das mergen der Xcode Projektfiles ist mit svn das letzte. Und sobald mal jemand das Projektfile schief anschaut und commited, fliegt einem schon das Projekt um die Ohren. Mit Mercurial merge ich mittlerweile ohne Angstschweiß. Ohne SVN ist das Leben schöner!“ Was ist denn an einem SVN-Merge und einem Git-/Mercurial-Merge der Xcode-Projektdatei anders

Android und iPhone zusammen? Uni Bremen, hallo! An der Uni Bremen wird ein Kurs: „Designing User Experiences — Development of Mobile Applications for iPhone and Android“ angeboten. Fragt mich nicht, wie man das unter einen Hut bringen kann.

Lucas und Jens, ihr habt verloren. Amin hat gewonnen Und auf eine Wette bei der ich verliere, lasse ich mich nicht ein, Amin mcebs, bist du schon weitergekommen?

Ich würde Jens Ansatz auch bevorzugen, einfach nur aus dem Grund, weil Core Data entweder XML oder SQLite verwendet und beide sehr langsam werden können, wenn zu viele Binärdaten in der eigentlichen „Datenbank“ gespeichert sind. Einen eindeutigen Hash-Wert zu generieren und als Dateinamen zu verwenden ist nicht allzu schwer.