Master React Native Alert: API Anleitung & Best Practices

Sie aktivieren Alert.alert() auf React Native, testen Sie auf iPhone und Android, und es fühlt sich fertig an. Dann öffnet jemand die Webanwendung und nichts erscheint. Oder Android ignoriert die Benachrichtigungssequenz, die Sie auf iOS verwendet haben. Oder zwei Teile der App lösen Benachrichtigungen aus und der Benutzer wird in einem chaotischen Stapel von Dialogen gefangen.

Das ist die Form der React Native Alert API. Sie ist großartig für schnelle, native Bestätigungsflüsse. Sie ist auch eng, plattformgebunden und leicht zu missbrauchen in der Produktion. Die gute Nachricht ist, dass der glückliche Weg einfach ist und die rauhen Kanten vorhersehbar sind, wenn Sie wissen, wo sie sind.

Inhaltsverzeichnis

• Anzeige einfacher Nachrichten mit Alert.alert
  • Was die grundlegende Anfrage bietet
  • Wo Teams es missbrauchen
  • Gute Verwendungsfälle für eine einfache Benachrichtigung
• Bearbeitung von Benutzereingaben mit Bestätigungsbuttons
  • Auswahl von Buttonetiketten, die Fehler minimieren
  • Was die tatsächlichen Buttonstile bedeuten
  • Ein sichereres Bestätigungsmodell
• Navigation bei Plattform-Sonderheiten und Eingabeprompten
  • iOS und Android passen nicht perfekt zusammen
  • Web-Unterstützung benötigt seinen eigenen Plan
  • Einfaches Web-Polyfill-Muster
• Wann verwenden Sie einen benutzerdefinierten Modalfenster anstatt eines Benachrichtigungsfensters?
  • Bei Native-Benachrichtigungen können Sie sich nicht um code herumdrücken
  • Einfaches Entscheidungsfilter
  • Gute Kandidaten für benutzerdefinierte Modalfensterbibliotheken
• Produktionsmuster für zuverlässige React Native-Benachrichtigungen
  • Zentralisieren Sie Benachrichtigungen anstatt sie überall aufzurufen
  • Barrierefreiheit ist Teil der Implementierung
  • Testen Sie den Auslöser, nicht das Plattform-Fenster
  • Eine Produktionsbasis, die hält

Anzeige einfacher Nachrichten mit Alert.alert

Für grundlegende Benachrichtigungs-UI, React Native Alert ist immer noch das schnellste Werkzeug im Box. Sie importieren Alert, rufen Alert.alert(), und die Plattform rendernt ein natives Dialog. Keine zusätzliche Abhängigkeit, kein benutzerdefinierter Modalszustand, keine Stylingsarbeit.

Die einfachste Version benötigt nur einen Titel und eine Nachricht:

import React from 'react';
import { View, Button, Alert } from 'react-native';

export default function ProfileScreen() {
  const showSavedMessage = () => {
    Alert.alert('Profile updated', 'Your changes were saved successfully.');
  };

  return (
    <View style={{ padding: 24 }}>
      <Button title="Save profile" onPress={showSavedMessage} />
    </View>
  );
}

Dieses Muster funktioniert gut, wenn der Benutzer keine bedeutsame Wahl treffen muss. Denken Sie an „Einstellungen gespeichert“, „Sitzung abgelaufen“ oder „Funktion nicht verfügbar zum jetzigen Zeitpunkt“. Das Dialog unterbricht den Fluss, es sollte also Informationen bereitstellen, die der Benutzer sofort benötigt, nicht jedoch geringfügige Statuslärm.

Was die grundlegende Anrufung bietet

Eine einfache Alert.alert(title, message) ist nützlich, weil sie natürlich bleibt. Das Betriebssystem übernimmt die visuelle Darstellung, die Schaltflächenrollen und das Standardinteraktionsmuster. Für viele Teams ist das genau der richtige Kompromiss.

Eine paar praktische Regeln helfen, es nützlich zu halten:

• Verwenden Sie einen direkten Titel. "Upload fehlgeschlagen" ist klarer als "Hinweis".
• Halte die Nachricht kurz.. Benachrichtigungen sind für den sofortigen Kontext, nicht für eine lange Erklärung.
• Reserviere Benachrichtigungen für wichtige Informationen.. Wenn der Benutzer ohne Unterbrechung fortfahren kann, ist ein Toast oft eine bessere Wahl.

Halte Benachrichtigungen klein und entscheidend. Wenn der Benutzer einen Absatz lesen muss, ist das Dialogfenster wahrscheinlich falsch.

Wo Teams es missbrauchen

Der häufigste Fehler ist das Missbrauchen von Benachrichtigungen als allgemeines Nachrichtensystem. Wenn jede erfolgreiche Aktion ein Blockierendes Dialogfenster zeigt, fühlt sich die App schnell schwer an. Native-Benachrichtigungen sind am stärksten, wenn sie den Benutzer für einen Grund stoppen.

Ein weiterer Fehler ist das zu eng an Komponenteninnereien koppeln von Benachrichtigungen. Ein kleiner Button-Handler ist anfangs in Ordnung, aber sobald Flüsse mehrere Screens und asynchrone Aktionen umfassen, werden Benachrichtigungsaufrufe überall, die man sich schwer überlegen kann. Das ist einer der Gründe, warum Teams oft frühzeitig die umgebenden UX-Muster standardisieren, genauso wie sie die Standardisierung der Splash-Screen-Behavior in React Native-Anwendungen tun. Gute Verwendungsfälle für eine einfache Benachrichtigung.

Szenario

Wenn Sie den Benutzer dazu bringen möchten, zwischen verschiedenen Pfaden zu wählen, ist der buttons nächste Schritt der Alert.alert() Array. Das ist, wo

mehr als nur ein einfaches Nachrichtenfenster wird.

Benutzerinput mit Bestätigungsbuttons verwalten buttons array matters.

Ein häufiger Bestätigungsdialog ist wie folgt:

import React from 'react';
import { View, Button, Alert } from 'react-native';

export default function DangerZone() {
  const confirmDelete = () => {
    Alert.alert(
      'Delete item',
      'This action cannot be undone.',
      [
        {
          text: 'Cancel',
          style: 'cancel',
        },
        {
          text: 'Delete',
          style: 'destructive',
          onPress: () => {
            console.log('Deleting item...');
          },
        },
      ]
    );
  };

  return (
    <View style={{ padding: 24 }}>
      <Button title="Delete item" onPress={confirmDelete} />
    </View>
  );
}

Jeder Knopf ist ein Objekt. In der Praxis wirst du drei Eigenschaften am häufigsten verwenden:

• text ist die Beschriftung, die dem Benutzer angezeigt wird.
• onPress läuft aus, wenn der Knopf betätigt wird.
• style beschreibt die Bedeutung, insbesondere auf iOS.

Die Wahl von Knopfbeschriftungen, die Fehler minimieren

Das API ermöglicht es Ihnen, "OK" zu schreiben und weiterzumachen. Das ist normalerweise nicht ausreichend. Die Beschriftung sollte die Folgen beschreiben, insbesondere für zerstörerische Aktionen.

Vergleichen Sie diese beiden Sätze:

• Schwache Beschriftungen: OK / Abbrechen
• Bessere Beschriftungen: Löschobjekt / Objekt behalten

Die zweite Version entfernt die Ambiguität. Das ist in destruktiven Flüssen wichtig, und es ist noch wichtiger, wenn die Warnung nach einem Fehler oder einer asynchronen Operation erscheint. Der Text der Schaltfläche sollte antworten, „Was passiert, wenn ich auf diese Schaltfläche tippe?“

Wenn Ihr Fluss Text von dem Benutzer sammelt, ist ein sauberes Begleitmustern das Paaren von Warnungen mit expliziten Formulareingaben wie einer dedizierten Implementierung von React Native TextInput anstatt versuchen, den Dialog zu überbordieren.

Welche Schaltflächenstile tatsächlich Bedeutung haben

Der style Textfeld ist semantisch, nicht dekorativ. Verwenden Sie es, um Absichten zu kommunizieren.

Technische Benchmarking von Gluestack zeigt, dass sich Plattformkonventionen hier auswirken. iOS platziert die Abbrechen Schaltfläche auf der linken Seite und Bestätigen auf der rechten Seite, während Android das umkehrt. Verstöße gegen diese Konventionen führen zu einem Anstieg der Benutzerverwirrungsmetriken um 25% in globalen Märkten und 45% von kritischen Pfadwarnungen in Produktionsanwendungen fehlt oft eine verpflichtende Abbruch- oder Beendigungsoption, was die unumkehrbaren Aktionen und die Supportanfragen erhöht. Diese Analyse weist auch darauf hin, dass benutzerdefinierte Warnungsimplementierungen oft bei der Lesereihenfolge für assistive Technologien scheitern. Siehe die Gluestack-Warnleitfaden.

Praktische Regel: Jede zerstörerische Warnung sollte eine explizite Möglichkeit zum Verlassen enthalten.

Für eine visuellere Durchführung der Schaltflächeneinstellungen und der Interaktionsablauf ist diese kurze Demo einen Blick wert.

Eine sicherere Bestätigungsanordnung

Wenn die Aktion empfindlich ist, sollte der Callback dünn sein:

Alert.alert(
  'Sign out',
  'You will need to log in again to continue.',
  [
    { text: 'Stay signed in', style: 'cancel' },
    {
      text: 'Sign out',
      style: 'destructive',
      onPress: async () => {
        try {
          await signOut();
        } catch (error) {
          Alert.alert('Sign out failed', 'Please try again.');
        }
      },
    },
  ]
);

Dieses Muster ist langweilig, und das ist gut. Warnungen sollten vorhersehbar bleiben.

Navigation durch Plattform-Sonderheiten und Eingabeprompt

Eine häufige Produktionsfehler sieht so aus. Der gleiche Alert.alert() Ruft auf iOS, funktioniert auf Android, dann funktioniert er nicht, sobald das Team eine Webversion bereitstellt. Der API sieht gleichmäßig in code aus, aber die Plattformen sind nicht.

iOS und Android passen sich nicht perfekt an

Die Reihenfolge der Schaltflächen ist der erste Ort, an dem Teams hängenbleiben.

React Native delegiert Benachrichtigungen an das Betriebssystem, sodass Benutzer native Konventionen sehen, nicht eine React Native-Abstraktion. Das ist in der Regel der richtige Kompromiss, aber es bedeutet, dass die Schaltflächenbeschriftungen unverwirrend bleiben müssen, um auf beiden Plattformen zu funktionieren. Alert.prompt Unterstützung für Eingabefelder ist der größere Unterschied. iOS unterstützt

für leichte Texteingabe. Android unterstützt dies nicht. Wenn ein Fluss von der Eingabe eines Passworts, der Umbenennung eines Elements oder der Erfassung eines kurzen Notizen innerhalb der Benachrichtigung selbst abhängt, ist dieser Fluss iOS-only, es sei denn, Sie bauen einen separaten Weg.

import { Alert, Platform } from 'react-native';

export function requestPassword() {
  if (Platform.OS === 'ios') {
    Alert.prompt(
      'Enter password',
      'Please confirm your password.',
      [
        { text: 'Cancel', style: 'cancel' },
        {
          text: 'Continue',
          onPress: (value) => {
            console.log('Password entered:', value);
          },
        },
      ],
      'secure-text'
    );
    return;
  }

  Alert.alert(
    'Confirmation required',
    'Please continue to the next screen to confirm this action.',
    [{ text: 'OK' }]
  );
}

Verwenden Sie eine Plattformprüfung frühzeitig anstatt zu glauben, dass die APIs übereinstimmen.

Das Android-Fallback ist weniger bequem. Es ist jedoch die sichere Wahl. In der Produktion ist eine Umleitung zu einer dedizierten Seite oder einem kontrollierten Modalfenster einfacher zu testen, einfacher zu lokalisieren und einfacher zugänglich zu machen als ein fiktiver Eingabefeld, der um nicht unterstützte Verhalten herumgebaut wird.

React Native’s official Alert API documentation lists support for iOS and Android in the Die offizielle Dokumentation von React Native Alert __CAPGO_KEEP_0__ listet die Unterstützung für iOS und Android in derReact Native Alert Referenz. Wenn Ihre App auch auf React Native Web oder Expo Web läuft, bleibt die Benachrichtigung ungewickelt und führt zu einem vollständigen Scheitern für diese Interaktionsroute in Web-Builds ().

Diskussion über die Unterstützung von React Native Web für Benachrichtigungen auf GitHub (

Behandeln Sie native Alerts als mobilen-only, es sei denn, Sie fügen einen Wrapper hinzu.

Dieser Wrapper hilft auch, wenn Ihr Team die Hybrid-Runzeit-Abwägungen zwischen Plattformen vergleicht, insbesondere in einer Reaktive Native vs. Capacitor Architektur-Vergleich.

Ein einfaches Web-Polyfill-Muster

Für viele Apps ist der erste funktionierende Fix eine kleine Abstraktion um die Plattform-Spaltung herum:

import { Alert, Platform } from 'react-native';

type ConfirmOptions = {
  title: string;
  message?: string;
  onConfirm?: () => void;
  onCancel?: () => void;
};

export function confirmDialog({
  title,
  message,
  onConfirm,
  onCancel,
}: ConfirmOptions) {
  if (Platform.OS === 'web') {
    const result = window.confirm(message ? `${title}\n\n${message}` : title);
    if (result) onConfirm?.();
    else onCancel?.();
    return;
  }

  Alert.alert(title, message, [
    { text: 'Cancel', style: 'cancel', onPress: onCancel },
    { text: 'OK', onPress: onConfirm },
  ]);
}

Dieses Muster löst den sofortigen Support-Engpass, aber es hat Grenzen. window.confirm Es gibt Ihnen fast keinen Kontrolle über die Gestaltung, das Fokusverhalten oder die Analytics- Hooks. Es ist ein vernünftiger Sicherheitsnetz für einfache Bestätigungen, nicht jedoch die endgültige Antwort für Flüsse, die eine Zugänglichkeitsprüfung, eine Benachrichtigungsanzeige oder eine konsistente Verhaltensweise auf mobilen und Web-Geräten benötigen.

Wann Sie einen benutzerdefinierten Modalfenster anstelle eines Alerts verwenden sollten

Native-Alert-Fenster sind stark, weil sie begrenzt sind. Diese gleiche Einschränkung ist der Grund, warum sie schnell nicht mehr die richtige Werkzeug sind.

Wenn Sie Marken, Layout-Kontrolle, Icons, Formulare, benutzerdefinierte Abstände, Animationstimer oder konsistente visuelle Konsistenz zwischen Plattformen benötigen, stoppen Sie, sich mit der API zu kämpfen. Verwenden Sie ein benutzerdefiniertes Modalfenster.

Native-Alerts können Sie nicht code umgehen

Sie können nicht Alert.alert() wie Ihr Design-System aussehen. Das ist bewusst so. React Native überträgt die Renderung an das Betriebssystem, sodass Sie native Erscheinungsbild und native Einschränkungen erben.

Das ist gut, wenn Sie eine schnelle Bestätigung wollen. Es ist schlecht, wenn das Produkt eine dieser Anfragen stellt:

• Ein mit Logo, Hilfetext und benutzerdefinierter Hierarchie versehener Bestätigungsdialog Ein mehrfeldiger Formularbereich
• innerhalb des Modals Ein reichhaltigerer destruktiver Workflow
• mit Checkbox-Bestätigung Ein Bewertungsanfrage oder eine Anfrage zur Produktbewertung
• Einige dieser Anfragen erfordern eine benutzerdefinierte Benutzeroberfläche, die nicht durch die native Alert-Implementierung bereitgestellt wird. mit Sternen, Illustration und benutzerdefinierten Schaltflächen

Einmal erscheinen diese Anforderungen, wird die native Benachrichtigung zu einem Sackgassen

Einfache Entscheidungsfilter

Verwende React Native Alert Verwende

Eine benutzerdefinierte Modaldialog hilft auch, wenn Ihre mobilen und Web-Anwendungen denselben Verhalten benötigen. Anstatt jede Plattform für immer speziell zu behandeln, können Sie einen zentralen Dialogkomponenten erstellen und Ihr Interaktionsmodell konsistent halten.

Der Moment, in dem Sie sich wünschen, dass Alert nur noch ein weiteres Prop hätte, bedeutet wahrscheinlich, dass Sie einen Modaldialog benötigen.

Vorschläge für benutzerdefinierte Modaldialogbibliotheken

Der integrierte Modal Komponente funktioniert, aber viele Teams wählen einen Wrapper wie react-native-modal weil er praktische Kontrolle über Sichtbarkeit, Hintergrundverhalten und Animation bietet.

Das ist besonders nützlich für Flows, die sich an Aktionsscheiben, unteren Schubladen oder zusammengesetzte Bestätigungsfelder anlehnen. Wenn Ihr Design näher an einem Menü liegt als an einem strengen nativen Warnhinweis, sind verwandte UI-Muster wie ein Ionischer Aktionsscheiben bieten oft eine bessere mentale Vorstellung als das Versuchen, Alert in die gewünschte Form zu bringen.

Einige Warnungen gelten hier. Ersetzen Sie nicht jede Warnung durch einen benutzerdefinierten Modalfenster nur, weil es besser aussieht. Native-Warnungen gewinnen immer noch für Geschwindigkeit, Vertrautheit und geringen Implementierungsrisiko. Verwenden Sie ein Modalfenster, weil die Interaktion es erfordert, nicht weil das Design-Team das Systemchrome ablehnt.

Produktionsmuster für zuverlässige React Native-Warnungen

Ein Löschungsvorgang schlägt fehl, der Wiederholungs-Handler wird ausgelöst und die Sitzungsabgelaufensicherung läuft gleichzeitig. Ohne eine klare Warnungsstrategie können Benutzer mit überlappenden Dialogen, verlorenem Fokus oder einer no-op auf der Webseite getroffen werden, weil Alert.alert ist dort nicht implementiert. Diese Fehler kommen normalerweise aus der Architektur und nicht aus der API-Aufruf selbst.

Zentralisieren Sie Warnungen anstatt sie überall aufzurufen

Direkte Alert.alert(...) Aufrufe, die über verschiedene Bildschirme verteilt sind, halten sich in einem größeren Codebase nicht. Ein Komponente handhabt einen API-Fehler, eine andere fragt nach Navigationsbestätigung und eine dritte warnt vor Auth-Ablauf. Wenn diese Ereignisse sich in der Nähe begeben, benötigen Sie eine Reihenfolge, eine Duplikation und eine Plattform-Abfalllogik an einem Ort.

Ein globales Warnungsdienst löst das. Verwenden Sie Redux, Zustand oder React Context. Die Wahl des Stores spielt weniger eine Rolle als der Vertrag. Warnungsanfragen gelangen in eine Warteschlange, ein Dialog ist zu einem Zeitpunkt aktiv und die Web kann hinter der gleichen Schnittstelle auf ein Modalfenster-Abfall zurückgreifen.

Entwickler, die Muster der Benachrichtigungsabstraktion diskutieren, haben wiederholt auf dieselbe Fehlerrate hingewiesen: Apps mit schlechter Struktur landen oft mit gestapelten Dialogen, die Benutzer fangen oder die Aktion verbergen, die sie ausführen müssen, manchmal beeinflusst sie etwa 30-40% von den in der Praxis diskutierten Implementierungen (Die Diskussion über die Implementierung der Benachrichtigungsabstraktion und der Dialogstapelung wurde bereits früher im Artikel erwähnt, daher wiederhole den Link hier nicht. Die praktische Lösung ist einfach. Wrap die __CAPGO_KEEP_0__ einmal, priorisieren die Anforderungen global und machen den Renderer für genau einen sichtbaren Benachrichtigungsdialog verantwortlich. was noted earlier in the article, so do not repeat that link here). The practical fix is simple. Wrap the API once, queue requests globally, and make the renderer responsible for exactly one visible alert.

Die Benutzeroberfläche abonniert das erste Queue-Element und renderet genau einen Dialog. Wenn der Benutzer ihn abblendet, entfernt der Dienst das Element und enthüllt das nächste.

type AlertRequest = {
  title: string;
  message?: string;
  buttons?: { text: string; onPress?: () => void; style?: 'default' | 'cancel' | 'destructive' }[];
};

type AlertStore = {
  queue: AlertRequest[];
  push: (alert: AlertRequest) => void;
  shift: () => void;
};

Die Barrierefreiheit ist Teil der Implementierung

Native-Benachrichtigungen bieten Ihnen gute Standards auf iOS und Android. Sobald Sie jedoch eine benutzerdefinierte Ersatzlösung für Web, reichhaltige Inhalte oder die Android-Prompt-Ersatzung einführen, übernehmen Sie die Verhaltensweise, die das Systemdialog kostenlos abgedeckt hat.

Gluestacks Vergleich der React Native-Benachrichtigungsoptionen weist darauf hin, dass benutzerdefinierte Modaleinführungen oft die erwartete Lesereihenfolge von

Titel → Nachricht → Schaltflächen brechen, mit Fehlern in diesem Bereich in ihrem Benchmark für die Barrierefreiheitshandhabung (Gluestacks Vergleich der React Native-Benachrichtigungsoptionen vs. Modalbarrierefreiheit). Diese spezifische Problematik ist wichtig, weil Benutzer mit Bildschirmlesern auf eine vorhersehbare Struktur angewiesen sind, um den Dialog zu verstehen, bevor sie darauf handeln.ca. 60% in ihrem Benchmark für die Barrierefreiheitshandhabung (Gluestacks Vergleich der React Native-Benachrichtigungsoptionen vs. Modalbarrierefreiheit). Diese spezifische Problematik ist wichtig, weil Benutzer mit Bildschirmlesern auf eine vorhersehbare Struktur angewiesen sind, um den Dialog zu verstehen, bevor sie darauf handeln.

Für eine benutzerdefinierte Benachrichtigungs-UI, halten Sie diese Liste kurz und streng:

• Verschieben Sie den Fokus in das Dialogfeld als es sich öffnet.
• Rufen Sie den Fokus auf den Auslöser zurück nach der Abmeldung.
• Halten Sie die Lesereihenfolge intakt: Titel, Nachricht, dann Aktionen.
• Bieten Sie einen klaren Abbruchpfad an, insbesondere für zerstörerische Flüsse.
• Beschriften Sie Aktionen genau. „Löschen“ ist besser als „OK“ wenn die Folgen zählen.

Zugänglichkeitsfehler in Benachrichtigungsflüssen sind leicht zu übersehen während normaler QA. Tastaturnutzer und Screenreader-Nutzer finden sie zuerst.

Testen Sie den Trigger, nicht die Plattformdialog

Einheiten-Tests sollten überprüfen, dass Ihr code die Warnung angefordert hat, die Sie erwartet haben. Sie sollten sich nicht auf die native Dialog- Runtime verlassen.

Eine häufige Jest-Pattern sieht wie folgt aus:

import { Alert } from 'react-native';

jest.spyOn(Alert, 'alert').mockImplementation(() => {});

it('asks for confirmation before deleting', () => {
  triggerDeleteFlow();

  expect(Alert.alert).toHaveBeenCalledWith(
    'Delete item',
    'This action cannot be undone.',
    expect.any(Array)
  );
});

Das hält die Tests auf die Geschäftslogik fokussiert und verhindert Hänge, die durch Dialogverhalten außerhalb der Testumgebung verursacht werden. Es drängt die Teams auch zu einem Wrapper API , der nützlich ist, wenn Web- und Android-Prompt-Begrenzungen eine benutzerdefinierte Fallback-Anforderung erzwingen.

Kunden-seitige Überwachung hilft hier auch. Teams, die bereits Interaktionsfehler in React Native-Anwendungen mit Sentry verfolgen fangen normalerweise mehr Warnungsbeziehungen auf, wenn die code-Pfade, die Warnungen auslösen, in explizitem Fehlerbehandlungs- und mit ausreichendem Kontext zum Wiederaufbau der Fluss protokolliert werden.

Eine Produktionsbasis, die hält

Für Apps, die über das Prototypenstadium hinausgehen, verwenden Sie einen kleinen Satz von Regeln:

1. Umwickeln Alert.alert mit einem Hilfsprogramm so dass die Web-Fallback-Logik an einem Ort lebt.
2. Anfragen in der Warteschlange global bearbeiten Damit ist nur ein Benachrichtigungssymbol gleichzeitig sichtbar.
3. Android-Fensterunterstützung als fehlend behandeln und einen Modalfallplan anstelle einer späten Verzweigung planen.
4. Abbruchaktionen erfordern zurückzuhalten, wenn es sich um zerstörerische oder unwiderrufliche Operationen handelt.
5. Benachrichtigungen in Tests simulieren und die Beschriftungen, Callbacks und die Reihenfolge überprüfen.
6. Einen benutzerdefinierten Modalfenster nur dann verwendenwenn dies erforderlich ist, wie z.B. für Web-Parität, Eingabefelder oder reichere Inhalte.

Dies hält native Benachrichtigungen schnell, wo sie gut funktionieren, und vermeidet es, den Code in eine Ecke zu malen, wenn sich spätere Plattformunterschiede zeigen.