Protocol vs. Notification

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

  • Protocol vs. Notification

    Moin Moin,

    ich würde gerne wissen wie ihr die Benutzung von Protocol und Notification handhabt.

    Im Prinzip kann man ja eigentlich immer wenn man ein Protocol und damit ein delegate nutzen kann auch einfach eine Notification schicken.
    Ich hab für mich noch nicht so ganz raus wann ich nun lieber ein Protocol nehme und wann eine Notification.

    Ich finde bei Notifications verliert man irgendwann den überblick, wer wann wo ne Notification schickt (wenn man irgendwann zu viel davon gebrauch macht).
    Protocol empfinde ich als etwas geordneter, wobei es gefühlt auch "mehr" arbeit ist.

    also wie handhabt ihr das?
    wann Protocol und wann Notification ?
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint:

  • Der Unterschied ist, einfach gesagt, das gleiche Prinzip, wie bei ER-Diagrammen:
    • Wenn es nur einen sinnvollen Empfänger geben kann oder soll, nimmst Du ein Delegate. Das ist in der Regel dann der Fall, wenn Entscheidungen anfallen. Beispielsweise lassen sich Entscheidungen wie should do something nur sehr schlecht über Benachrichtigungen realisieren. (1-zu-1-Beziehung)
    • Wenn es mehrere potentielle Empfänger (und Sender) gibt, sind Benachrichtigungen besser geeignet; so kommunizieren beispielsweise Modelcontroller mit Viewcontrollern. (n-zu-m-Beziehung).

    BTW: Eine bestimmte Benachrichtigung sollte in der Regel auch nur von einer bestimmten Stelle versendet werden, da sie über ein bestimmtes Ereignis informiert („Es ist gerade XY passiert.“); sie sollten keine Intention, wie z. B. „zeichne gefälligst den View neu“, haben. Von daher sehe ich das Problem mit der mangelnden Übersichtlichkeit nicht.
    „Meine Komplikation hatte eine Komplikation.“

  • nussratte schrieb:


    Ich finde bei Notifications verliert man irgendwann den überblick, wer wann wo ne Notification schickt (wenn man irgendwann zu viel davon gebrauch macht).


    Das ist genau der Plan: Du möchtest Sender und Empfänger entkoppeln. Der Sender erzeugt ein Ereignis ohne sich weiter darum zu kümmern ob sich jemand dafür interessiert, ein klassisches Publish/Subscribe Messaging Pattern.

    nussratte schrieb:


    Protocol empfinde ich als etwas geordneter, wobei es gefühlt auch "mehr" arbeit ist.


    'Protocol' und 'Delegate' sind erst mal zwei verschiedene Sachen. Delegation benutzt du wenn Objekte Aufgaben für andere übernehmen sollen, das Protokoll (auch "Interface" in Java) beschreibt dabei einfach die Schnittstelle und erwartetes Verhalten.

    Den Unterschied kannst du schön bei dem UIApplication sharedApplication Singleton sehen. Es hat sein App Delegate, dass für Zustandsänderungen — wie zum Beispiel die Initialisierung bei Start — innerhalb der App zuständig ist. Ohne das würde die App nicht funktionieren, also wird klar eine Aktion angeordnet und auf das Ergebnis gewartet.

    Andererseits können Zustandsänderungen der App auch für andere Objekte von Interesse sein - oder eben auch nicht. Deshalb sendet UIApplication noch Notifications aus, allerdings ohne sich dafür zu interessieren ob jemand zuhört.

    macmoonshine schrieb:


    Wenn es mehrere potentielle Empfänger (und Sender) gibt, sind Benachrichtigungen besser geeignet; so kommunizieren beispielsweise Modelcontroller mit Viewcontrollern. (n-zu-m-Beziehung).


    Das verstehe ich nicht ganz. Kannst du mal ein Beispiel für eine Kommunikation zwischen Modelcontroller und Viewcontrollern nennen?

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

  • SteveJ schrieb:


    Das verstehe ich nicht ganz. Kannst du mal ein Beispiel für eine Kommunikation zwischen Modelcontroller und Viewcontrollern nennen?


    Das ist doch die Grundlage eines MVC

    Ein Controller ändert etwas im Modell und das Modell verschickt Nachrichten an alle ViewController, die Daten aus dem Modell darstellen, dass sich was geändert hat.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Das sind zwei völlig unterschiedliche und nicht mal austauschbare Konzepte.

    Protocol/delegate sind synchron, d.h. der Methodenaufruf wird erst abgearbeitet bis es weitergeht. Man kann auch einen Wert zurückbekommen.

    Notifications sind asynchron - kommen später (vielleicht auch nie) an. In der Regel dann, wenn das System nicht weiter ausgelastet ist. Außerdem ist die Kommunikation einseitig, und wie schon jemand geschrieben hat mit vielen möglichen Empfängern.

    Vergleiche es mit einem Telefonat vs. Marktschreier.

  • Thallius schrieb:

    SteveJ schrieb:


    Das verstehe ich nicht ganz. Kannst du mal ein Beispiel für eine Kommunikation zwischen Modelcontroller und Viewcontrollern nennen?


    Das ist doch die Grundlage eines MVC


    Modelcontroller hast du in 'grundlegendem' MVC nicht, das sind Dinger wie NSDocument.

    Thallius schrieb:


    Ein Controller ändert etwas im Modell und das Modell verschickt Nachrichten an alle ViewController, die Daten aus dem Modell darstellen, dass sich was geändert hat.


    Da hast du keine "n-zu-m-Beziehung". Views interessieren sich normalerweise für ein bestimmtes Modell und beobachten dieses, nicht für allgemeine Änderungen - es gibt also nicht "mehrere potentielle [...] Sender".

  • SteveJ schrieb:

    Thallius schrieb:

    SteveJ schrieb:


    Das verstehe ich nicht ganz. Kannst du mal ein Beispiel für eine Kommunikation zwischen Modelcontroller und Viewcontrollern nennen?


    Das ist doch die Grundlage eines MVC


    Modelcontroller hast du in 'grundlegendem' MVC nicht, das sind Dinger wie NSDocument.

    Thallius schrieb:


    Ein Controller ändert etwas im Modell und das Modell verschickt Nachrichten an alle ViewController, die Daten aus dem Modell darstellen, dass sich was geändert hat.


    Da hast du keine "n-zu-m-Beziehung". Views interessieren sich normalerweise für ein bestimmtes Modell und beobachten dieses, nicht für allgemeine Änderungen - es gibt also nicht "mehrere potentielle [...] Sender".



    :?: :?: :?: :?:

  • Notifcations werden im technischen Sinne (Multithreading) synchron verarbeitet, kommen also garantiert an. Nur das Distributed-Notification-Center postet asynchron im Sinne von Multithreading. Semantisch ist das natürlich asynchron, wobei man ja gar nicht von einem "Ankommen" sprechen kann, weil man ja gar nicht weiß, wo sie ankommen sollen.

    Ansonsten kann ich mir nur nur selbst zitieren:
    Notifications sind asynchrone Nachrichten, die innerhalb eines Programms oder sogar zwischen den Programmen ausgetauscht werden. Sie dienen dazu, Zustandsänderungen an unbekannte Emfpänger mitzuteilen.

    Ein Delegate ist demgegenüber ja dem Sender stets konkret bekannt.
    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"?

  • hns schrieb:

    Notifications sind asynchron - kommen später (vielleicht auch nie) an.

    Das ist so nicht richtig.
    A notification center delivers notifications to observers synchronously. In other words, when posting a notification, control does not return to the poster until all observers have received and processed the notification. To send notifications asynchronously use a notification queue, which is described in “Notification Queues.”

    Michael