1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen
  2. Unsere jährliche Weihnachts-Banner-Aktion hat begonnen! Wir freuen uns auf viele, viele kreative Vorschläge.
    Mehr dazu könnt Ihr hier nachlesen: Weihnachtsbanner 2016

    Information ausblenden

CoreData Problem

Dieses Thema im Forum "OS X-Developer" wurde erstellt von zorn, 16.07.07.

  1. zorn

    zorn Weigelts Zinszahler (Rotfranch)

    Dabei seit:
    18.02.06
    Beiträge:
    251
    Hallo,

    ich bin immer noch Cocoa und CoreData Anfänger und dabei eine kleine Applikation zu schreiben. Basis soll eine SQL-Lite CoreData DB sein, gefüllt mit einigen hundert Bildern (jpg/png). Die sollen dann mit ein bischen Logik und Cocoa hübsch und nützlich dargestellt werden.

    Hab' mich durh die Cocoa Basics, Objective-C Basics und CoreData Basics gewühlt und möchte endlich anfangen. Also eine CoreData Application begonnen, die Struktur angelegt und auf folgendes Problem gestossen:

    Wie fülle ich meine erstellte Struktur mit Daten? Gibts da ein Tool für? Habe erfahrung mit MySQL usw., wo ich eine DB erstellen würde und dann eben füllen, und per PHP/Perl darauf zugreifen. Das Schema ist hier also quasi erstellt. Wie füllen?

    Ich befürchte dass meine Frage saublöd ist, aber ich steh' bischen auf dem Schlauch...

    (Ein Link mit passender Information wäre schon hilfreich)

    Thx
     
  2. MatzeLoCal

    MatzeLoCal Rheinischer Bohnapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.421
    Ich verstehe jetzt nicht ganz was Du meinst.

    Also "füllen" kannst Du entweder in dem Du z.B. mit dem InterfaceBuilder eine Oberfläche entwirfst, die alle Felder für die Daten usw enthält.

    Oder Du automatisierst es und schreibst eine Anwendung die z.B. ein Verzeichnis ausliest und dann die Daten schreibt.

    EDIT: Schau dir mal dieses Tutorial an, das erklärt es ganz gut, wie das codeseitig abläuft.

    SQL usw brauchst Du bei CoreData nicht
     
  3. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
  4. zorn

    zorn Weigelts Zinszahler (Rotfranch)

    Dabei seit:
    18.02.06
    Beiträge:
    251
    Mh - hatte ich wohl was falsch verstanden...
    Werd' ich mir wohl doch noch etwas genauer anschauen müssen. Naja - für den Anfang werd' ich mein Problem dann wohl mit Dictionaries und Filesystemzugriffen lösen...

    Sorry for waisting your time, war wohl etwas zu schnell.
     
  5. MatzeLoCal

    MatzeLoCal Rheinischer Bohnapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.421
    Doch.. ein bisschen schon, den CoreData kann auch die SQLite bedienen!


    Hm, poste doch mal grob was Du machen willst.... ich lehne mich jetzt schonmal weit aus dem Fenster und sage "es geht"... ausser die schwebt was Client/Server-mäßiges vor... dann bist Du mit CoreData schon in einer No-Go-Area
     
  6. zorn

    zorn Weigelts Zinszahler (Rotfranch)

    Dabei seit:
    18.02.06
    Beiträge:
    251
    Naja - wie in meinem initialen Post beschrieben versuch' ich grade zu lernzwecken eine kleine Applikation zu schreiben, die mit einigen hundert Pics umgehen muss. Verschiedene Kategorien, jeweils ca. 20 Bilder. Fiktives Beispiel:
    Kategorie Säugetier: Hund, Katze, Maus...

    Dachte das kann ich elegant per CoreData und SQLlite (hatte ich in einem Tutorial gesehen) lösen (dort war allerdings genau dieser Teil - wie fülle ich die SQLlite-DB ausgespart und wie in der Hobbythek schon mal vorbereitet). Egal - ich lese mich jetzt in aller Ruhe in CoreData ein, für später, und löse mein Problem so:

    Ich lege pro Kategorie eine Klasse an in der ein Dictionary oder 2 Arrays mit den Daten definiert werden. Beispiel: Klasse Säugetier: Dictionary: path_to_hundebild - hund, path_to_katzenbild - katze...

    Ist das mit den Klassen pro Kategorie sinnvoll, oder sollte ich vieleicht besser alle in einer Klasse vereinigen. Werden ca. 50 Kategorien, und ich dachte das wird dann schnell unübersichtlich und schlecht zu pflegen. Hätt' ich pro Kategorie eine Klasse kann ich das später auch noch easy erweitern, pflegen, etc.
     
  7. MatzeLoCal

    MatzeLoCal Rheinischer Bohnapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.421
    Sorry, ich bin kurz vorm "am Kopfkissen lauschen" und kann mich deswegen grad nit so recht reinlesen. Aber ganz grob.

    Ich finde, dass sich das Beispiel bestens für CoreData eignet. Ich verstehe nur nicht ganz was Du mit füllen meinst. Soll das automatisch gehen? Dann müsstest Du ja schon im Vorfeld die Kategorien mit den Bildern verbinden.

    Und für die Programmierung: Wenn Du die Dictionaries mit Datenbedienst, dann kannst Du das auch gleich mit CoreData machen ;)

    Wie das mit dem codeseitigen Eintragen geht steht in dem Tut das ich verlinkt hatte.
     
  8. zorn

    zorn Weigelts Zinszahler (Rotfranch)

    Dabei seit:
    18.02.06
    Beiträge:
    251
    Also doch CoreData - hatte ich das doch richtig verstanden. Hab' hier leider grade keinen Apple zur Hand, deshalb alles theoretisch, aber wenn ich das Tutorial unter deinem Link korrekt verstanden habe kann ich meine Entities mit Daten füllen indem ich einfach die Entity in den Gui-Builder ziehe?
    Ich habe keine variablen Daten die mit CoreData verwaltet werden, alles statisch. Ich muss die Entities allo irgendwie 'füllen'.

    Zwei Probleme also noch:
    Da ich jeweils ein Bild mit einer Beschreibung abrufen möchte, Beispiel "frosch" + "pfad_zu_frosch.jpg". Mache ich also zwei Text Attribute und in das eine wie hier beschrieben einen Pfad zum Bild im Dateisystem, oder kann ich auch direkt das Bild in CoreData speichern. Wo müssten die Bilder liegen in meinem Projekt? Wie wäre der relative Pfad dahin?

    CoreData rules. Versuche mir jetzt noch mit Bindings viel arbeit zu sparen...
     
  9. MatzeLoCal

    MatzeLoCal Rheinischer Bohnapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.421
    Das mit dem Füllen kannst Du machen wie Du magst. Also rein prinzipiell.

    Erstmal GUI-seitig
    Wenn Du den Pfad speichern willst, dass genügt es, wenn Du das Bild auf eine NSTextField ziehst. Das nimmt dann autmatisch den Pfadnamen.. Die Beschreibung muss natürlich von Hand eingegeben werden. Es sei denn sie ist schon Bestandteil des Dateinamens, dann kannst Du den natürlich automatisch parsen, wenn ein neues Bild in das NSTextField für den Pfad gezogen wird.
    Ich wage mal zu behaupten, dass wenn Du die Beschreibung von Hand eingibst, Du für die Anwendung noch nicht mal den Editor (für Code) aufmachen musst.

    Codeseitiges Befüllen des CoreData-"Containers" (hast ja die wahl zwischen XML, Binary und SQLite) würde ich für eine automatisierte Bearbeitung empfehlen. Dann musst Du dir natürlich auch was zur Generierung der Beschreibung einfallen lassen.

    Du kannst natürlich auch das Bild speichern. Dafür gibt es aber verschiedene Möglichkeiten, z.B. Base64.

    Der Link von Amin Negm-Awad zeigt Dir sehr gut, wie Du rein via GUI eine CoreData-Anwendung hinbekommst. Der Link von mir zeigt, was codeseitig zu tun wäre.
     
  10. zorn

    zorn Weigelts Zinszahler (Rotfranch)

    Dabei seit:
    18.02.06
    Beiträge:
    251
    Hey - vielen Dank für deine Hilfe. Ich werd' die Pics im FS ablegen, versuche die CoreData Variante ohne Code. Wollte eben das hier ausprobieren, funktioniert bei mir leider nicht...

    {
    Prototype UI Generation

    We've mentioned that you can use Cocoa bindings to connect a Core Data managed object context to your application's user interface. However, early in an application's development life cycle when you are exploring what kinds of objects you need to capture in the data model, you can take advantage of a new feature of Interface Builder that will create prototype interfaces for you. All you need to do is Option-drag an entity from the Xcode Data Model design tool onto a window in Interface Builder and a comprehensive interface will be created for you.

    To be sure, this interface probably doesn't match what you want to expose to users when your application is finished, but it is a powerful way to explore the functionality of your data model during development.
    }
     
  11. MatzeLoCal

    MatzeLoCal Rheinischer Bohnapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.421
    Ich hab das zwar noch nie gebraucht, aber bei mir geht das.

    Einfach da, wo Du dein Datenmodel anlegst auf das jeiligen Entinty klicken. Option (Alt) gerückt halten, das Entity in den InterfaceBuilder (und dort in dein "Anwendungsfenster") ziehen.
     
  12. zorn

    zorn Weigelts Zinszahler (Rotfranch)

    Dabei seit:
    18.02.06
    Beiträge:
    251
    Hab' Xcode neu installiert jetzt funktioniert das auch. Recht nützlich. Ich werd' mir jetzt eine kleine GUI bauen um meine Entities zu füllen. Vielen Dank für eure Geduld und Hilfe - bin viel weiter gekommen und immer noch motviert - ein gutes Zeichen. Die Links sind beide super, aber das Videotutorial hat mich natürlich sehr beeindruckt. Sehr hilfreich auch mal zu sehen wie schnell das alls gehen kann. Gute Vorgabe. Titel war ja ADC Video Tutorial Series, allerdings hab' ich keine weiteren Teile der Serie finden können. Hat mir jemand einen Tip wo sich die verstecken? Oder gibts momentan nur die für CoreData? Oder ist das so zu verstehen dass diese CoreData Clip-Sammlung die Serie ist? Lol...
     
  13. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    Das ist ein Speicherformat und völlig irrelevant für die "Bedienung" von Core Data. Es kann auch XMLs schreiben. Deshalb ist es kein XML-Parser. Und morgen kann es vielleicht die Dateien in Grabsteine meißeln. Das macht es nicht zum Steinmetz-Framework.

    Du "bedienst" Core Data nicht wie ein rDBMS. (Du kannst das zwar äußerst begrenzt, aber du kannst dir auch Nadeln unter die schieben.)
     
  14. MatzeLoCal

    MatzeLoCal Rheinischer Bohnapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.421
    Ich wollte damit auch nicht sagen, dass sich CoreData wie eine rDBMS bedienen lässt. Siehe auch:

    Aber es kann eine rationale Datenbank füllen und somit deren Vorteile nutzen. Und CoreData muss auch kein (für alles nutzbarer) XML-Parser sein, wenn es XMLs schreibt und liest. Es muss seine eigenen Daten lesen und schreiben können...

    Um beides legt sich das Framework aussen rum... es gibt dem Entwickler also nur eine Schnittstelle. Dem Entwickler ist die Datenquelle von der er liest bzw schreibt nun lattte. Sein Interface ist immer das gleiche. Er kann sich aber nun für das jeweilige Format und dessen Vor- und Nachteile entscheiden.... mit einer Codezeile.
     
  15. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    Na, er kann die Vorteile einer rDBMS gerade nicht wirklich nutzen:

    a) Bei Behandlung wie in einer DB (abgekürzte Bezeichnung) bekommst du ein Laufzeitproblem.
    b) Gerade das, was eine DB stark macht, nämlich das Verknüpfen von Tabellen geht nicht. Es gibt kein JOIN, WHERE usw., sobald man die Entität selbst verlässt. Es wäre also ein rDBMS mit einem klitzekleinen r.
    c) Transaktionsmanagement gibt es nicht wirklich.
    d) Das Ganze ist dokumentenbasiert.

    Ich hatte ihn so verstanden, dass er *seine* "DB" füllen möchte. Dafür ist es erst einmal gleichgültig, ob das mittels SQL, XML oder was auch immer persistiert. Es ist eigentlich schon falsch gedacht. (Daher auch mein OP): Er füllt keine DB, sondern ein Dokument.
     
  16. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    Von dem Ablegen im FS kann ich dir (teilweise) abraten, weil ich es so mache (machen muss). Das Problem liegt darin, dass der User selbst an das FS kommt. Du musst das also nachhalten und synchronisieren. Nicht unbedingt trivial. Wenn es dir gleichgültig ist, kannst du es freilich so machen. Ist dann halt User-Problem.

    Core Data kann aber auch mit "BlOBs" umgehen. Im Prinzip nennt die Dokumentation mehrere Möglichkeiten, eigene Datentypen zu verwenden. Es läuft letztendlich darauf hinaus, dass du zwischen deinem Datentypen (NSImage) und einem NSData-Objekt hin- und herwandelst.
     
  17. zorn

    zorn Weigelts Zinszahler (Rotfranch)

    Dabei seit:
    18.02.06
    Beiträge:
    251
    >Von dem Ablegen im FS kann ich dir (teilweise) abraten, weil ich es so mache (machen muss). Das >Problem liegt darin, dass der User selbst an das FS kommt. Du musst das also nachhalten und >synchronisieren. Nicht unbedingt trivial. Wenn es dir gleichgültig ist, kannst du es freilich so >machen. Ist dann halt User-Problem.

    Also - ich bin Anfänger in Sachen Cocoa - und in meiner Naivität meine ich mit im FS Ablegen, dass meine Bilder nach compilation mit dem .app geliefert werden. Momentan ziehe ich z.B. ein Bild auf meine CoreData Entity und habe so den Pfad zum Bild gestored. Ein ImageView greift dann auf den Pfad zu. Wie bekomme ich nur die Folder mit den Bildern so in mein Projekt dass die nach compilation im Package sind. Habe auf doof versucht den Bilderfolder in meinen XCode Resources Folder zu ziehen. Die Bilder wurden dann zwar importiert, die Pfade waren aber immer noch auf den original Desktop-Folder geeicht. Bestimmt gibts da eine supereasy Möglichkeit, aber wie schon so oft funktioniert mein Gehirn noch zu kompliziert für die Applewelt und ich komm' einfach nicht drauf (wer auf Arbeit gezwungen ist mit Windows zu arbeiten weiss wovon ich spreche...)

    Meine User würden als nicht an die Bilder kommen(jedenfalls nicht ohne tools und fachwissen), da sie im build.app gestored sind. Denke das sollte klappen, oder?
     
  18. MatzeLoCal

    MatzeLoCal Rheinischer Bohnapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.421
    Das wird wohl nicht gehen. CoreData speichert, sorry wenn ich mich jetzt irre, in ~/Application Support/APP-NAME. Umbiegen, dass CoreData ins App-Resource speichert geht nicht.
    Allerdings frage ich mich da grad selbst, ob Du dann überhaupt CoreData brauchst. Deine Daten sind ja nicht dynamisch, sondern bleiben im ausgelieferten Zustand.
     
  19. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    Ja, du bist mit CD auf dem falschen Wege. Ich hatte dich ebenso verstanden wie Matze. Alos: CD dient dazu, dass du dein Dokument darin modellierst. Bei deinen Bildern handelt es sich aber offenkundig um Resourcen. Diese fügt du dem Projekt in Xcode hinzu, welche sie dann automatsch in dein Bundel kopiert. Du kannst auch programmatisch darauf zugreifen -pathForResource:oops:fType (NSBundle) oder -imageNamed: (NSImage).
     
  20. zorn

    zorn Weigelts Zinszahler (Rotfranch)

    Dabei seit:
    18.02.06
    Beiträge:
    251
    Ich kann nicht den Speicherort der CoreData Daten ändern. Kann ich kaum glauben, werd' ich recherchieren. Jedenfalls bin ich schon ziemlich verwöhnt, und hab' mir auch schon eine schöne GUI gebaut um die Daten einzupflegen, von meinen ganzen Bindings ganz zu schweigen. Ist auch super um später weiteren Content zu adden - also nö - CoreData bleibt. Da müsste ich ja unmengen Code schreiben um das mit Resourcen hinzubekommen...

    Meine Hauptbedenken waren wie ich denn die Bilder ausliefern kann, dachte ich kann alles easy in ein .app packen, auf die Homepage stellen und gut. Mit Bildern unter /Lib/AppSupport/ kann ich gut leben. Musste mir solche Gedanken noch nicht machen, aber muss ich mich dann auch noch um einen Installer kümmern, der die Files da hin packt? Kann ich das eventuell am einfachsten mit einem .pkg machen? Denke schon, oder? Am liebsten wär' mir immer noch ein store im .app, dann könnte man mein Tool einfach in den App-Folder ziehen und gut.
    .pkg müsste aber funktionieren, oder? (Gibts da ein nettes Tool oder muss ich mit den Shell-Tools vorlieb nehemn. Komme aus der Unix Welt, aber aus .debs und .rpms hab' ich noch nichts gebaut...)
     

Diese Seite empfehlen