Double-Werte aus Core Data into Array

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

  • Double-Werte aus Core Data into Array

    Hallo,

    ich habe noch eine weitere Frage.

    Ich habe ein Array mit Double-Werten

    [12.45, 15.76, 19.56, 27.32, 19.89, 29.54]

    Jetzt hab ich das so geändert, dass ich die Werte in Core Data eintrage/speicher

    Wie bekomme ich diese jetzt in die View zurück sodass ich sowas habe:

    [Entity.Attribut] und das wie das obige Beispiel verstanden wird?
  • Nur als kleiner Tipp nebenbei.

    Float oder Double werte wo du einen festen Nachkomma-Anteill hast (Also zum Beispiel Geldsummen, Temperaturen, Gradzahlen) solltest du intern nicht als float oder double behandeln sondern als int. Das verhindert Rechenfehler auf Grund der Fließkomma Ungenauigkeit.

    Als konkretes Beispiel Geldsummen:

    12.45 Euro einfach als 1245 Cent speichern und immer alles mit Cent rechnen. Damit bekommst du niemals Werte wie 12.0000000001 Euro, was bei Fließkomma Operationen oft passiert.
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • die Daten fetchen:

    1. Moeglichkeit:

    context ist dein NSManagedObjectContext

    Quellcode

    1. do {
    2. let result = try context.fetch(Person.fetchRequest())
    3. // result dann zurückgeben > in Repo
    4. } catch (let error) {
    5. }

    2. Moeglichkeit:

    direkt in der View den FetchRequest durchziehen:

    Quellcode

    1. @FetchRequest(entity: Favorite.entity(), sortDescriptors: [NSSortDescriptor(keyPath: \Favorite.name, ascending: true)])
    2. var favorites: FetchedResults<Favorite>

    Du wirst dich wahrscheinlich fuer die zweite Variante entscheiden. Aber nur weil etwas geht, ist es nicht unbedingt gut. Trenne besser die Schichten Data und Presentation von vornherein und baue dir einen CoreDataService, der IO an einem Platz fuer dich abhandelt.
  • Bei diesem Beispiel

    1. do {
    2. let result = try context.fetch(Person.fetchRequest())
    3. // result dann zurückgeben > in Repo
    4. } catch (let error) {
    5. }


    ist dann mein result das, was ich in meinem Array haben möchte und "Person" ist hier die Entität?

    Habe noch nicht so ganz verstanden wie das genau funktioniert.

    Mit dem FetchRequest wäre vermutlich wirklich einfacher, da ich schon einen habe und diesen dann erweitern könnte.
    Ich würde mir aber deinen Tipp mit dem Trennen zu Herzen nehmen. Wäre also um ein wenig mehr Erklärung diesbezüglich sehr dankbar
  • Quellcode

    1. func fetchAllData() -> Result<[Person], Error> {
    2. do {
    3. let result = try context.fetch(Person.fetchRequest())
    4. return .success(result)
    5. } catch (let error) {
    6. return .failure(error)
    7. }
    8. }
    Schichtentrennung Schlagwoerter:

    SRP
    Clean Architecture
    Modularisierung
    Kohäsion

    Diese Themen werden von vielen Einsteigern meist sehr vernachlässigt, weil man moechte schnell #Erfolge (es passiert was in der UI) sehen will. Nur ohne Architektur in der App wird es fast unmöglich wachsende Projekte unter Kontrolle zu behalten. Und wenn dann nichts mehr geht, ist die Codebasis so verworren, dass nur noch ein rewrite hilft.
    Je planloser und frei nach #WirMachenErstMal startet wird, desto mehr wird sich die Entwicklungsgeschwindigkeit im Laufe der Zeit verlangsamen und es ist nicht unwahrscheinlich, dass das Projekt unwartbar wird
  • Thallius schrieb:

    Float oder Double werte wo du einen festen Nachkomma-Anteill hast (Also zum Beispiel Geldsummen, Temperaturen, Gradzahlen) solltest du intern nicht als float oder double behandeln sondern als int. Das verhindert Rechenfehler auf Grund der Fließkomma Ungenauigkeit.
    Entweder so oder mit NSDecimalNumber. Ich nutze für Geldsummen immer NSDecimalNumber, das ist komplett Rechenfehler-/Fließkommafehler-frei und man spart sich die "Faktor 100"-Umwandung, welche bei Unachtsamkeit durchaus auch schnell zu einigen Bugs führen kann. Hier sind auch ein paar interessante Artikel dazu erwähnt: stackoverflow.com/questions/42…number-to-deal-with-money

    322 schrieb:

    Du wirst dich wahrscheinlich fuer die zweite Variante entscheiden. Aber nur weil etwas geht, ist es nicht unbedingt gut. Trenne besser die Schichten Data und Presentation von vornherein und baue dir einen CoreDataService, der IO an einem Platz fuer dich abhandelt.
    Guter Punkt. Ich war anfangs von den @FetchRequests auch ganz begeistert, weil man sehr schnelle Resultate kriegt. Mittlerweile nutze ich sie nur noch selten, weil es eine ordentliche Trennung von Model / View schwer macht und spätestens wenn ein leichtes Processing der Daten vor dem Anzeigen ins Spiel kommt, werden die Views sehr unhandlich. Mittels ObservableObject und NSFetchedResultsController kann man sich auch gut selbst einen generischen, automatisch aktualisierenden CoreData-Fetcher bauen, den man dann auch sehr handlich im außerhalb der View, (z.B. im ViewModel) verwenden kann (und ggf. eine Publisher-Pipeline dranhängen kann).