Today Extension und CoreData

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

  • Today Extension und CoreData

    Hallo, baue gerade an einer App, diese nutzt CoreData und besitzt auch eine TodayExtension. In der App selber nutze ich sharedApplication()
    Das geht aber nicht in der TodayExtension (sharedApplication()' is unavailable: Use view controller based solutions where appropriate instead.)

    Nun bin ich etwas überfragt, wie ich nun auf meine Daten aus CoreData zugreifen kann? Vielleicht hat ja jemand eine Idee, wie ich weiterkomme.

    Danke.
    404 Not Found

  • Du musst die Daten in einem gemeinsamen Container der App anlegen. Das geht jeweils unter App Groups in Capabilities der Targets. Der Container besteht aus einem Verzeichnis, auf das die App und die Erweiterung lesend und schreibend zugreifen dürfen. An das Verzeichnis kommst du über - containerURLForSecurityApplicationGroupIdentifier:.
    „Meine Komplikation hatte eine Komplikation.“

  • App Groups ist bereits für beide aktiviert.

    aktuell greife ich so drauf zu:

    let appDel: AppDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
    let contxt: NSManagedObjectContext = appDel.managedObjectContext!
    let freq = NSFetchRequest(entityName: "List")
    myList = contxt.executeFetchRequest(freq, error: nil)!
    404 Not Found

  • Den Store und ManagedObjectContext im App-Delegate anzulegen, ist eine Konvention, die du bei einer App-Extension brechen musst. Bei einer Today-Extension bietet sich dafür beispielsweise der View-Controller der Erweiterung an.

    Das Core-Data-Modell solltest du natürlich in einem gemeinsamen Framework ablegen. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • Manuel1987 schrieb:

    also den core date Bereich aus dem AppDelegate in eine eigene Klasse?
    Kannst du machen, musst du aber nicht. Noch mal:
    1. App initialisiert Core Data über App-Delegate (wie bisher)
    2. App-Extension macht das über den View-Controller.
    3. Core-Data-Model-Datei und Klassen der Entities in eigenes Framework, damit App und App-Extension das Model nutzen können.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Den Store und ManagedObjectContext im App-Delegate anzulegen, ist eine Konvention, die du bei einer App-Extension brechen musst. Bei einer Today-Extension bietet sich dafür beispielsweise der View-Controller der Erweiterung an.

    Das Core-Data-Modell solltest du natürlich in einem gemeinsamen Framework ablegen. ;)
    Ich finde ja, dass es einfach schlechter Stil ist, es ins AppDelegate oder den VC zu packen, denn da gehört es nicht hin. Die Xcode-Templates sind in dem Fall m.M.n. Müll. Hier werden die Probleme mit Singletons schön deutlich.

    @TE: mach Dir eine separate Klasse für den CD-Stack, die benutzt Du dann an den benötigten Stellen.

  • Markus Müller schrieb:

    macmoonshine schrieb:

    Wobei es in diesem Thread ja eher um das grundlegende Verständnis geht, dass der Core-Data-Stack nicht im App-Delegate untergebracht werden muss.
    Jup, sollte auch keine Kritik an Deinem Post sein, sondern am schlechten Beispiel, welches Apple mit seinen Templates gibt.
    Beste Grüße, Markus
    Habt ihr denn ein Beispiel, wie man es besser machen sollte? ;)

  • Markus Müller schrieb:

    sondern am schlechten Beispiel, welches Apple mit seinen Templates gibt.
    Jupp. Auch die Tatsache, dass beim Anlegen eines UITablewViews + Controller der Controller gleichzeitig auch Datasource und Delegate ist, führt wahrscheinlich in der Praxis zu einer Reihe richtig fetter ViewControllern mit zuviel Verantwortlichkeiten, die eigentlich ins Modell gehören.

    ciao

    gandhi

  • matz schrieb:

    Markus Müller schrieb:

    macmoonshine schrieb:

    Wobei es in diesem Thread ja eher um das grundlegende Verständnis geht, dass der Core-Data-Stack nicht im App-Delegate untergebracht werden muss.
    Jup, sollte auch keine Kritik an Deinem Post sein, sondern am schlechten Beispiel, welches Apple mit seinen Templates gibt.Beste Grüße, Markus
    Habt ihr denn ein Beispiel, wie man es besser machen sollte? ;)
    Na eine eigene Klasse CoreDataStack o.ä., die man dann entspr. nutzt und vor allem projektübergreifend wieder benutzen kann.

  • gandhi schrieb:

    Auch die Tatsache, dass beim Anlegen eines UITablewViews + Controller der Controller gleichzeitig auch Datasource und Delegate ist, führt wahrscheinlich in der Praxis zu einer Reihe richtig fetter ViewControllern mit zuviel Verantwortlichkeiten, die eigentlich ins Modell gehören.
    Naja, deren Methoden beinhalten in der Regel schon originäre Aufgaben des Viewcontrollers. Wo willst du die denn sonst unterbringen?
    „Meine Komplikation hatte eine Komplikation.“

  • Markus Müller schrieb:

    macmoonshine schrieb:

    Den Store und ManagedObjectContext im App-Delegate anzulegen, ist eine Konvention, die du bei einer App-Extension brechen musst. Bei einer Today-Extension bietet sich dafür beispielsweise der View-Controller der Erweiterung an.

    Das Core-Data-Modell solltest du natürlich in einem gemeinsamen Framework ablegen. ;)
    Ich finde ja, dass es einfach schlechter Stil ist, es ins AppDelegate oder den VC zu packen, denn da gehört es nicht hin. Die Xcode-Templates sind in dem Fall m.M.n. Müll. Hier werden die Probleme mit Singletons schön deutlich.
    @TE: mach Dir eine separate Klasse für den CD-Stack, die benutzt Du dann an den benötigten Stellen.
    Finde ich nicht. In der Regel – und dafür sind die Templates gedacht – ist der Core-Data-Stack eine applikationsweite Ressource.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Markus Müller schrieb:

    matz schrieb:

    Markus Müller schrieb:

    macmoonshine schrieb:

    Wobei es in diesem Thread ja eher um das grundlegende Verständnis geht, dass der Core-Data-Stack nicht im App-Delegate untergebracht werden muss.
    Jup, sollte auch keine Kritik an Deinem Post sein, sondern am schlechten Beispiel, welches Apple mit seinen Templates gibt.Beste Grüße, Markus
    Habt ihr denn ein Beispiel, wie man es besser machen sollte? ;)
    Na eine eigene Klasse CoreDataStack o.ä., die man dann entspr. nutzt und vor allem projektübergreifend wieder benutzen kann.
    Was soll denn in dieser Klasse drin sein?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Markus Müller schrieb:

    Ich finde ja, dass es einfach schlechter Stil ist, es ins AppDelegate oder den VC zu packen, denn da gehört es nicht hin. Die Xcode-Templates sind in dem Fall m.M.n. Müll. Hier werden die Probleme mit Singletons schön deutlich.

    @TE: mach Dir eine separate Klasse für den CD-Stack, die benutzt Du dann an den benötigten Stellen.

    Markus Müller schrieb:

    Jup, sollte auch keine Kritik an Deinem Post sein, sondern am schlechten Beispiel, welches Apple mit seinen Templates gibt.

    Beste Grüße, Markus

    Markus Müller schrieb:

    Na eine eigene Klasse CoreDataStack o.ä., die man dann entspr. nutzt und vor allem projektübergreifend wieder benutzen kann.
    Tatsächlich? Welchen Beitrag meinst du denn genau?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Na z.B. den mit dem CoreDataStack. Er braucht es ja in der AppExtension und da kann er das Delegate nicht verwenden. Natürlich kann er den Code duplizieren und dann später zwei Versionen pflegen und mit der Watch eine dritte. Vlt. soll auch ein weiterer Store dazukommen oder parent/child Kontexte, store-migration uswusf.

    Ich stimme Dir auch zu, dass so ein Stack eine applikationsweite Resource ist, aber das bedeutet ja nicht zwangsläufig, dass man sich deshalb das AppDelegate damit zumüllen muss. Eine separate Klasse mit dieser einen Zuständigkeit, gerne als property im AppDelegate.

    M.M.n. eine Frage der Codehygiene, aber selbstverständlich darf das jeder machen, wie er es für richtig hält.

    Beste Grüße, Markus