Klasse zum Speichern von Daten

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

  • Klasse zum Speichern von Daten

    Hallo,

    ich habe aktuell eine Vorstellung in meinem Kopf weiß aber nicht direkt wie ich diese Vorstellung am geschicktesten umsetzen sollte.
    Ich entschuldige mich zu beginn schon mal, da man diese Frage wahrscheinlich mit elementaren Grundwissen beantworten können müsste aber ich stehe da, wie so oft, auf dem Schlauch.

    Also, angenommen man hat drei View Controller (First,SecondThird VC) in denen man immer das selbe anzeigen und auch ändern können möchte.

    Zur Verdeutlichung ein Bild eines Test Storyboards
    [Blockierte Grafik: https://picload.org/image/rraiardr/screen1.png]

    In dieser Test App wird ja der FirstVC beim Start aufgerufen, dabei soll der Text des Labels in eine eigene Klasse gespeichert werden.
    Beim Aufruf des SecondVC oder des ThirdVC soll aus der Klasse dann der Text ausgelesen werden.

    Ich hab mir dazu eine DataController Klasse (NSObject) erstellt, aber logischer Weise wenn ich die Klasse jedes mal neu initialisiere habe ich auch jedesmal eine leere Property.

    Ich suche nun nach dem Schritt die bereits initialisierte Klasse aufzurufen, bzw auf die Property, in der der Text gespeichert ist, zugreifen zu können, oder nach anderen eventuell sinnvolleren Lösungen.

    Bitte lasst die Steine ausnahmsweise in der Schublade :D , mir ist bewusst das diese Frage eine ziemlich blöde Frage ist, allerdings wollte ich von Leuten mit Erfahrung eine Meinung dazu hören.
  • DBocksteger schrieb:

    Such mal nach "Singleton" oder gib dein Objekt der Speicher-Klasse an die weiteren Controller weiter. :)
    Die Objekte jeweils an den nächsten ViewController weitergeben wollte ich vermeiden weil auch von außenstehenden ViewControllern eventuell darauf zugegriffen werden muss.
    Mit den Singletons funktioniert das super.

    matz schrieb:

    - NSUserDefaults (wenn es nicht zu viele Werte sind)
    - CoreData
    - eigenes JSON / XML-File
    - UserDefaults fällt leider weg da es schon recht viele Werte sein werden
    - CoreData wollte ich gerne ausschließen
    - eigene JSON Datei klingt noch ganz gut, das muss ich nochmal ausprobieren.

    Danke für eure Hilfe

    nussratte schrieb:

    Chronisch schrieb:

    mit elementaren Grundwissen beantworten können müsste
    lies doch einfach ein Buch, dann steht man auch nicht auf dem Schlauch
    Ja ich weiß, das sollte ich unbedingt machen. Habe mir schon das Buch von macmoonshine gekauft und auch schon angefangen zu lesen aber mir fehlt immer die Zeit weswegen ich dazu neige mir nur das was ich brauche mittels Internet zu suchen.
    Für meine freie Urlaubszeit liegt das Buch aber schon ganz oben auf dem Stapel.
  • Chronisch schrieb:

    Die Objekte jeweils an den nächsten ViewController weitergeben wollte ich vermeiden weil auch von außenstehenden ViewControllern eventuell darauf zugegriffen werden muss.

    Wat?

    Chronisch schrieb:

    Mit den Singletons funktioniert das super.

    Ist nur leider für den Anwendungsfall totaler Müll.

    Ich bekomme hier den Eindruck, du versuchst ein Objective-C Problem mit einem Java-Ansatz zu lösen.
    Würdest Du für Dein Projekt die 'Master Detail' Vorlage wählen, hättest Du (inklusive vorbereitetem Core Data) schon mal 80% Deiner Fragen beantwortet.
    Da eine Vorlage dafür existiert, kannst Du davon ausgehen, dass Dein Anliegen ein absoluter Grundlagen- und Standardfall ist.
    Du wirst nicht mit eigenem Objektgelöt arbeiten, sondern brav Core Data benutzen.
    Es gibt absolut kein Argument gegen die Nutzung von Core Data.

    Wenn Du auf JSON oder ähnlichen Schwachsinn setzen möchtest, darfst Du Dich gern mit allen Problemen bezüglich der Performance beim Laden, Speichern und Verwalten herumärgern, die Dir mit Core Data abgenommen werden. Das wirst Du sicherlich nicht können.

    Du wirst auch kein eigenes DataController Objekt zusammenstricken, sondern brav den für genau diesen Anwendungsfall entwickelten NSArrayController benutzen.
    Kurzerhand bist Du auch Dein 'außenstehende ViewController' Problem los: Dein NSArrayController weiß immer ganz genau, was gerade selektiert wurde.

    Immer gleich alles selbst besser machen wollen anstatt sich erst mal durch die mitgelieferten Beispiele zu probieren - wie herrlich naiv.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Marco Feltmann schrieb:

    Wenn Du auf JSON oder ähnlichen Schwachsinn setzen möchtest, darfst Du Dich gern mit allen Problemen bezüglich der Performance beim Laden, Speichern und Verwalten herumärgern, die Dir mit Core Data abgenommen werden. Das wirst Du sicherlich nicht können.

    Du wirst auch kein eigenes DataController Objekt zusammenstricken, sondern brav den für genau diesen Anwendungsfall entwickelten NSArrayController benutzen.
    Mal ganz ruhig mit die jungen Pferde - oder gibt es NSArrayController inzwischen für iOS?

    @Chronisch:
    Singleton ist aber in der Tat igitt - gerade weil Zugriff von x-beliebigen, aussenstehenden Objekten ein Antipattern ist.
    Was du brauchst ist eigentlich nur eine reine Modell-Klasse, welche die Daten vorhält, und die jedem ViewController, der sie braucht, zugewiesen wird.
    Dummerweise kann man in Storyboards nicht einfach Objekte anlegen, die mit mehreren Controllern verknüpft sind... aber es ist auch nicht so schwierig, jedem deiner eigenen VCs eine "modell"-Property (und am besten noch eine "injectModel" Methode) mitzugeben.
    Deinem Tabbar-Controller kannst du dieselbe Funktionalität in einer Extension verpassen, und da einfach alle children versorgen. Wenn du die extension gleich für UIViewController schreibst, bist du eigentlich schon fertig - eigentlich, denn leider gibt es in deinem Controller dann ein "Declarations from extensions cannot be overridden yet" :(
    Sei's drum, muss man halt etwas komplizierter arbeiten, deklariert ein "ModellUser"-Protokoll, mit einer injectModel-Methode und fertig ist der Lack.

    Quellcode

    1. extension UITabBarController: ModelUser {
    2. func injectModel(model: MyModelType) {
    3. for child in childViewControllers {
    4. if child = child as? ModelUser {
    5. child.injectModel(model)
    6. }
    7. }
    8. }
    9. }
  • matz schrieb:

    Ich bin auch kein reiner Buchleser weil es einfach trocken ist.
    Das ist auch typabhängig. Die eine saugt sich lieber erstmal drei Kilo Theorie rein, und geht dann in die Praxis. Der andere wurstelt drei Tage rum, und schaut danach ins Buch, wie es richtig geht. Dazwischen gibt's dann noch die, die zwischen Theorie und Praxis ständig abwechseln. Jedes wie es will. ;)

    Auf eine der beiden Seite ganz zu verzichten, ist allerdings eine schlechte Idee.
    „Meine Komplikation hatte eine Komplikation.“
  • matz schrieb:

    Chronisch schrieb:

    - CoreData wollte ich gerne ausschließen
    Warum? :)
    ich dachte in meiner Naivität das ein Speichern der Daten die per Json runter geladen und dann in einer Klasse gehalten werden performanter sein würde als die Daten runter zu laden, in CoreData speichern und dann wieder darauf zugreifen.

    Marco Feltmann schrieb:


    Chronisch schrieb:

    Mit den Singletons funktioniert das super.
    Ist nur leider für den Anwendungsfall totaler Müll.

    Ich bekomme hier den Eindruck, du versuchst ein Objective-C Problem mit einem Java-Ansatz zu lösen.
    Würdest Du für Dein Projekt die 'Master Detail' Vorlage wählen, hättest Du (inklusive vorbereitetem Core Data) schon mal 80% Deiner Fragen beantwortet.
    Da eine Vorlage dafür existiert, kannst Du davon ausgehen, dass Dein Anliegen ein absoluter Grundlagen- und Standardfall ist.
    Du wirst nicht mit eigenem Objektgelöt arbeiten, sondern brav Core Data benutzen.
    Es gibt absolut kein Argument gegen die Nutzung von Core Data.

    Wenn Du auf JSON oder ähnlichen Schwachsinn setzen möchtest, darfst Du Dich gern mit allen Problemen bezüglich der Performance beim Laden, Speichern und Verwalten herumärgern, die Dir mit Core Data abgenommen werden. Das wirst Du sicherlich nicht können.

    Du wirst auch kein eigenes DataController Objekt zusammenstricken, sondern brav den für genau diesen Anwendungsfall entwickelten NSArrayController benutzen.
    Kurzerhand bist Du auch Dein 'außenstehende ViewController' Problem los: Dein NSArrayController weiß immer ganz genau, was gerade selektiert wurde.

    Immer gleich alles selbst besser machen wollen anstatt sich erst mal durch die mitgelieferten Beispiele zu probieren - wie herrlich naiv.
    Danke dir für deine Erklärung, dann also doch CoreData. Wie oben beschrieben, dachte ich mir in meiner Unwissenheit ohne CoreData wäre performanter, mein Fehler.
    Den NSArrayController scheint es wirklich nur für macOS zu geben, gibt es dann noch eine gute Alternative oder dann doch ein eigen zusammengestrickter DataController?


    nussratte schrieb:

    Guck dir seine Themen und fragen an

    nussratte schrieb:

    zum scheitern verurteilt

    was bringt es dir wenn du was passendes findest aber nicht verstehst was da passiert und dann wieder hierher kommst um dir das erklären zu lassen?
    in der Zeit kannst du auch gleich das Buch lesen
    Ich bin auf einem ehemaligen Bauernhof groß geworden und mein Opa hat mir früher alles technische immer praktisch erklärt. Deshalb hab ich mir angewöhnt wild drauf los zu probieren.
    Ich bin der typische Ikea Idiot der das Paket auspackt die Anleitung zur Seite legt und dann wild was zusammenschraubt. Erst wenn es nach 3,4 Versuchen noch nicht geklappt hat wird dann ein Blick in die Anleitung riskiert.
    Ich weiß durchaus das diese Methode nicht die beste Methode ist, aber es macht mir auch so Spaß. Für mich muss etwas nicht nach dem ersten Versuch perfekt funktionieren, es ist für mich ein Erfolg wenn es überhaupt funktioniert.

    Meine bisherigen Fragen bezogen sich auf eine aller erste App, als ich damit angefangen habe, hatte ich null Komma gar keine Ahnung.Diese App wurde in der Firma in der ich angestellt bin entwickelt, in der kein Mitarbeiter bisher etwas mit App Entwicklung zu tun hatte. Das sollte ein Versuch werde um festzustellen was man machen kann, was es alles für Funktionen gibt. Mir ist durchaus bewusst das direkt zu Beginn ein Buch zu lesen die bessere Alternative wäre, und das habe ich auch, von dem Buch an dem macmoonshine mitgearbeitet hat gibt es ja noch eine Version für Einsteiger, das habe ich durchgelesen. Aber Chefs finden es einfach schöner schnelle Ergebnisse zu sehen, egal wie das umgesetzt wurde Hauptsache es funktioniert, als seine Angestellten stundenlang vor Büchern sitzen zu sehen. Mit neuen Test Apps wollte ich nun die Grundlagen die ich verpasst habe nachholen und verstehen, das ist der Grund warum ich jetzt sowas hier frage. In dieser ersten App ist vieles nicht optimal gelöst, und ich wollte jetzt schauen wie man es richtig, besser, performanter lösen hätte können um das für zukünftige Apps zu wissen.
  • nussratte schrieb:

    Guck dir seine Themen und fragen an
    Mein Fehler, tu ich normal tatsächlich ...

    macmoonshine schrieb:

    matz schrieb:

    Ich bin auch kein reiner Buchleser weil es einfach trocken ist.
    Das ist auch typabhängig. Die eine saugt sich lieber erstmal drei Kilo Theorie rein, und geht dann in die Praxis. Der andere wurstelt drei Tage rum, und schaut danach ins Buch, wie es richtig geht. Dazwischen gibt's dann noch die, die zwischen Theorie und Praxis ständig abwechseln. Jedes wie es will. ;)
    Auf eine der beiden Seite ganz zu verzichten, ist allerdings eine schlechte Idee.
    Jep, da gebe ich dir vollkommen recht und es schadet auch nicht ein Buch zu lesen ;) Gerade das von euch :P