Berechnungen in Core Data

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

  • Marco Feltmann schrieb:

    [MCDan]
    Also mir ist der Beitrag schon aufgefallen. Da ich mit der ersten Zeile aber nix anfangen konnte, habe ich mich auf die mir bekannteren Apsekte gestürzt.

    MCDan schrieb:

    Ein Objekt könnte auch das/die Objekt(e) ermitteln, welche für die Berechnung von Differenzen etc. zu einem anderen Objekt erforderlich sind. Ein ManagedObject kann über den vorhandenen ManagedObjectContext die benötigten Objekte passend ermitteln.

    Wie kann es das denn tun, wenn alle Objekte unsortiert sind und es dringend das Objekt finden muss, dass vor ihm erstellt wurde?


    Die Logik, welche Objekt quasi das "Bezugsobjekt" zu einem Objekt bzw. einer Anforderung ist, muss man natürlich per Code festlegen. Bleiben wir mal bei dem Beispiel aus diesem Thread.

    Es gibt die Methode distanceToPreviousEntry. Diese Methode hat keinen Parameter, da das PreviousEntry in dem Objekt ermittelt werden kann. Da ein Entry ein Datum hat ist das PreviousEntry natürlich das Entry welches mit seinem Datum direkt vom dem eigenem Datum liegt. Dies könnte in etwa so aussehen:

    Quellcode

    1. - (float)distanceToPreviousEntry
    2. {
    3. MyClass *previousEntry = [self previousEntry]; // Das über den eigenen ManagedObjectContext ermittelte Objekt der eigenen Entity welches ein Datum direkt vor dem eigenem Datum hat.
    4. return self.kilometerstand - previousEntry.kilometerstand;
    5. }


    Die Methode previousEntry ermittelt per FetchRequest (fetchLimit = 1) mit passendem Predicate (datum < self.datum) und SortDescriptor (key = datum und ascending = NO) das Entry direkt vor sich "selbst".
  • Also ich würde das etwas mehr separieren. Die Berechnung des Spritverbrauchs gehört m.M. in eine eigene Klasse und sollte nicht mit der Datenhaltung vermischt werden. Diese bekommt eine Strecke und die Kilometer, und errechnet Dir den Verbrauch. Dann eine weitere Klasse, die Dir die benötigten Entitäten besorgt in Bezug auf einen gegebenen Zeitraum. Veil besser wiederverwendbar, einfach zu testen, völlig unabhängig von CoreData, Viewcontollern, usw.

    Gruß, Markus
  • Danke.

    Ich teste jetzt mal wie ich das am besten hinbekomme, die Berechnung des Verbrauchs ist noch etwas komplizierter,
    da je nach dem wenn die letzte Tankung keine Volltankung war, muss ich bis zum letzten Eintrag der eine Volltankung war
    zurückgehen und die dazwischen liegenden Liter der Teiltankungen mit einbeziehen.

    In meiner Android-APP habe ich das ja schon so umgesetzt, muss das nun für objectiv C und Core Data
    entsprechend umsetzen.

    Die Tips haben mir auf jeden Fall schon mal weitergeholfen udn den Weg gezeigt.
    MfG. Bernhard
    (hb-mobilesoft.de)