local Notifications und das 64er Limit

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

  • PetTus schrieb:

    macht euch ruhig weiter einen Kopf - denn ich stehe aktuell vor einem weiteren Problem :/
    Entweder habe ich gerade ein Brett vorm Kopf oder es existiert wirklich eine Komplikation.

    Kurze Zusammenfassung vom Ist-Zustand
    • ich habe eine swift 2 app
    • aktuell kann jeder App Nutzer Eintragungen machen, welche in CoreData gespeichert und in einem TableView angezeigt werden
    • zu jedem Eintrag gibt der Nutzer ein Datum an (welches in der Zukunft liegt), um an diesem Tag und vorher an seinen jeweiligen Eintrag erinnert zu werden (mit Hilfe von Local Notifications, 2 Erinnerungen = 2 Notifications)
      • Problem dabei war die Limitierung von 64 local Notifications - da jeder Eintrag 2 Notifications registriert wären "nur" noch 32 Einträge möglich - das ist auf Dauer zu wenig.


    Zusammenfassung vom Soll-Zustand
    [*]Der Nutzer muss sich registrieren, damit seine Eintragungen in meine MYSQL Datenbank gespeichert werdenDer Nutzer soll die Möglichkeit haben mit anderen registrierte Nutzer eine gemeinsame Liste von Eintragungen zu führen
    [*]Aus diese Grund muss bei jedem Start der App, die CoreData Datenbank mit der MYSQL Datenbank synchronisiert werden
    [*]Die Local Notifications sollen durch Remote Notifications abgelöst werden, womit die Limitierung wegfallen würde
    • Nach dem sich der User registriert hat, wird auch sein Device Token in die Datenbank zu seinem Userdatensatz gespeichert
    • Ein PHP Script wird täglich ausgeführt und überprüft ob das gewählte Datum in der MYSQL Datenbank für einen Eintrag dem heutigen Datum entspricht und schickt darauf hin, eine Notification an den Ersteller dieses Eintrages (Device Token des Users liegt ja vor)


    Hoffe das war soweit verständlich erklärt :/ Problematik die ich jetzt aktuell sehe - der Device Token kann sich ja ändern.Z.B. Wenn ich die App deinstallieren und wieder installiere - das wäre dann aber nicht schlimm - denn dann müsste der User sich schließlich auch wieder in der App neu anmelden, dabei kann ich dann seinen alten Token aus der Datenbank durch den neuen Token ersetzen.Aber was mache ich, wenn sich der Token durch andere Gegebenheiten ändert -> SoftwareaktualisierungEntweder denke ich gerade zu kompliziert und es ist einfacher als gedacht. ODER es ist wirklich kompliziert ^^ Schon Mal vielen Dank vorab.
    Ich würde an deiner Stelle die Device-Tokens nicht im user Datensatz speichern sondern in einer separaten Tabelle "UserDeviceTokens", in der du die ID vom user mit n DeviceTokens ablegst. Das heißt, du überschreibst nicht den Datensatz, sondern merkst dir das neue Token zusätzlich.

    Geschickt wird die Notification dann an alle gespeicherten Tokens für den user und Tokens, bei denen Fehler auftraten, werden gelöscht.
    Man kann alles schaffen. Man muss es nur wollen ;)
    www.regetskcob.github.io

  • ja so werde ich es in etwa auch umsetzen.
    allerdings ist damit die Problematik nicht gelöst.

    Der neue Token kann ja nur übermittelt werden, wenn der User die App startet.
    Sollte er jetzt aber eine Softwareaktualisierung machen = device token ändert sich und er startet danach die App einige Tage nicht, wird meiner Datenbank der neue Token überhaupt nicht mitgeteilt.
    Somit würden die notifications in dem Zeitraum untergehen.


    * Dieses schweigen bedeutete nichts gutes * :(

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von PetTus ()

  • Sorry, sollte ich in der ganzen Thread-Historie etwas übersehen haben, aber...

    Ich finde eine Server-seitige Lösung, nur um Terminerinnerungen zu schicken, absoluten Overkill ... und wäre als Benutzer wegen Privacy-Aspekten auch sehr skeptisch. Als Betreiber wiederum halte ich den Verfügbarkeitsanspruch für kritisch.

    Kann nicht eine Local Notification die App im Hintergrund aktivieren, um den nächsten Zeitpunkt einer Alarmierung zu identifizieren und eine neue Notification einzustellen?

    Nochmals sorry, sollte ich den Thread in eine Loop schicken ... :)

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • Das wäre auch eine Variante, allerdings ist es mir nicht bekannt, das nach dem anzeigen einer Notification eine Aktion stattfinden kann.
    Außerdem hätten wir dann wieder das Problem mit der Synchronisation.

    Was ist wenn Nutzer A und Nutzer B eine gemeinsame Liste führen, Nutzer A seine App nicht an hat (noch nicht mal im Hintergrund) und Nutzer B erzeugt einen Eintrag in die Liste.
    Da würde Nutzer A keine Info drüber bekommen und keine Notification

  • PetTus schrieb:

    Der neue Token kann ja nur übermittelt werden, wenn der User die App startet.

    Sollte er jetzt aber eine Softwareaktualisierung machen = device token ändert sich und er startet danach die App einige Tage nicht, wird meiner Datenbank der neue Token überhaupt nicht mitgeteilt.
    Somit würden die notifications in dem Zeitraum untergehen.
    Dir fehlt die Verknüpfung zwischen Token und User. Wenn der User sich (erstmalig) registriert speicherst du seine ID und den Token auf dem iOS Device. Ändert sich der Token schickst du die User ID und den neuen Token an deinen Server, dieser kann den alten Token durch den neuen ersetzen (Datensatz ist ja durch User ID eindeutig).

  • ja, aber um herauszufinden, dass sich der Token geändert hat, müsste der User die App zumindest 1x starten, damit ich die Überprüfung laufen lassen kann.
    macht er dies mehrere tage nicht- bekommt er solange auch keine notifications = schlecht

  • moment mal, täglich?
    so wie ich das verstanden habe, ist die Limitierung doch von 64 notifications pro App gesetzt.
    oder habe ich jetzt was falsch verstanden? ist dies nur eine Tageslimitierung, das eine App nicht mehr also 64 notifications PRO Tag feuern darf, aber mehr als 64 speichern, wenn die nicht am selben Tag erscheinen?

    ach app on a device is limited to 64 scheduled local notifications. The system discards scheduled notifications in excess of this limit, keeping only the 64 notifications that will fire the soonest. Recurring notifications are treated as a single notification.
    Verstehe ich jetzt als 64 Notifications insgesamt, egal an welchen Tagen die erfolgen.
    Das ist mir aus diesem Grund zu wenig:

    Gehen wir Mal vom Durchschnitt aus.
    Jeder Eintrag der gemacht wird, bekommt 2 Notifications für 2 unterschiedliche Tage.
    Macht unterm Strich dann nur noch 32 Einträge die man machen kann - und das ist definitiv zu wenig

  • PetTus schrieb:

    Jeder Eintrag der gemacht wird, bekommt 2 Notifications für 2 unterschiedliche Tage.
    Macht unterm Strich dann nur noch 32 Einträge die man machen kann - und das ist definitiv zu wenig
    Aber das ist doch genau der Punkt: Wenn der Nutzer die App bei so vielen Benachrichtigungen nicht einmal öffnet, kannst du entweder auch Kalendererinnerungen verwenden, oder der Nutzer hat schlicht und ergreifend kein Interesse mehr an deiner App.
    „Meine Komplikation hatte eine Komplikation.“

  • Kalendererinnerungen wären ja eine Option - allerdings möchte ich nicht das man diese Einträge sieht, da diese sonst den eigentlichen Kalender des Users voll machen würde.
    Außerdem sieht die Notification von meiner App schöner aus (weil z.B. dass App Icon mit angezeigt wird) im Gegensatz zu Kalendererinnerung.



    macmoonshine schrieb:

    oder der Nutzer hat schlicht und ergreifend kein Interesse mehr an deiner App.

    und das kann man so pauschal ja auch nicht sagen. Die App soll den User ja an Einträge erinnern die auch in ferner Zukunft liegen können, ohne das er die App öffnen muss.
    Kann ja schlecht als Voraussetzung angeben: "Öffnen Sie die App in regelmäßigen Abständen, damit die Notifications gesetzt werden und ihr device token überprüft werden kann" :/

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von PetTus ()