Sådan tilføjer du notifikationer til din app: i appen, e-mail og push

For at tilføje notifikationer til en webapp skal du starte med notifikationer i appen: en tabel med notifikationer i din database og et klokkeikon, der viser ulæste. Tilføj e-mail til ting folk skal vide, når de er væk, via en e-mailudbyder, og tilføj web push kun når rettidige alarmer virkelig betyder noget, for det kræver en service worker, brugerens tilladelse og, på iPhone, at appen er gemt på startskærmen. Uanset hvilke kanaler du bruger, skal du oprette alle notifikationer ét sted på serveren og lade brugerne vælge, hvad de vil modtage.

Denne guide sammenligner kanalerne, viser en simpel arkitektur og giver prompts, du kan bruge med en AI-app-builder.

De vigtigste kanaler sammenlignet

De fleste apps har brug for i appen plus e-mail. Push og SMS er værd besværet, når timingen virkelig betyder noget, f.eks. en booking-påmindelse eller en ordre, der er klar.

Sådan hænger et notifikationssystem sammen

Hold det enkelt og centralt:

1. Noget sker. En kommentar bliver skrevet, en betaling fejler, en booking er i morgen.
2. Din server kalder én funktion, f.eks. notify(user, type, data).
3. Funktionen tjekker brugerens indstillinger og skriver en række i tabellen notifications (til klokken).
4. Den sender derefter til de andre kanaler, som brugeren har slået til for den type: e-mail via din udbyder, push via Push API.
5. Frontend viser ulæste notifikationer og markerer dem som læst, når de åbnes.

ét indgangspunkt betyder, at du kan tilføje en kanal, ændre formuleringer eller respektere indstillinger uden at lede gennem kodebasen.

Hvad der skal gemmes

En notifikationstabel har typisk brug for: bruger-ID, type (f.eks. comment_reply), en kort titel og tekst, et link til den relevante side, oprettelsestidspunkt og læsetidspunkt. En separat indstillingstabel gemmer hvilke kanaler hver bruger ønsker for hver type.

Visning af nye notifikationer

• Hent ved sidevisning og poll hvert 30.–60. sekund. Enkelt og pålideligt.
• Realtidsopdateringer med WebSockets eller server-sent events føles øjeblikkelige, men tilføjer bevægelige dele. Start med polling, medmindre øjeblikkelige opdateringer virkelig betyder noget.

E-mail-notifikationer

E-mail kræver en udbyder til afsendelse og et verificeret domæne; detaljerne står i sådan sender du e-mails fra din app. Til notifikationer specifikt:

• Send fra serveren, aldrig med en udbydernøgle i browseren.
• Saml hyppige hændelser. "3 nye kommentarer" i én mail slår tre mails.
• Tilbyd en daglig eller ugentlig oversigt for aktivitet med lav prioritet.
• Inkludér et afmeldings- eller indstillingslink i ikke-nødvendige mails. Reglerne for markedsføringsmails er forskellige fra land til land; tjek hvad der gælder for dig.

Web push-notifikationer

Web push lader dit site sende alarmer, der vises som app-notifikationer. Ifølge MDN's dokumentation for Push API virker det sådan her:

1. Dit site registrerer en service worker, et script browseren kan køre i baggrunden.
2. Når brugeren har sagt ja, abonnerer service workeren via PushManager.subscribe(). Browseren returnerer et abonnement med et endpoint og krypteringsnøgler.
3. Din server gemmer abonnementet, og når noget sker, sender den en besked til endpointet, typisk signeret med VAPID-nøgler (et nøglepar der identificerer din server).
4. Browseren starter din service worker, som viser notifikationen, selv om din side ikke er åben.

MDN bemærker også, at endpointet skal holdes hemmeligt, for at kende det er nok til at sende beskeder til den bruger.

iPhone og iPad

WebKit tilføjede Web Push til webapps i iOS og iPadOS 16.4, med to betingelser fra deres meddelelse: sitet skal være føjet til startskærmen, og tilladelse skal bedes om som svar på en brugerhandling, f.eks. et tryk på en Abonnér-knap. Så på iPhone når push kun brugere, der har installeret din webapp. Se native apps vs. progressive web apps for, hvad det betyder at installere en webapp.

At bede om tilladelse på den rigtige måde

Bed ikke om tilladelse ved første besøg. Forklar fordelen først ("Få en påmindelse en time før din time"), og vis derefter browserens prompt, når brugeren trykker på en knap. Hvis nogen siger nej, må browseren ikke tillade dig at spørge igen, så en for tidlig forespørgsel kan miste dem for altid.

Planlagte notifikationer kræver en trigger

"Påmindelse 24 timer før" eller "ugentlig oversigt hver mandag" kræver noget, der kører efter en tidsplan. Det er et baggrundsjob-problem, som er dækket i sådan kører du baggrundsjobs. Et almindeligt mønster: en ekstern planlægger kalder et beskyttet endpoint hvert par minutter, og endpointet sender det, der er forfaldent.

Prompts til din AI-builder

Start med notifikationer i appen:

Tilføj notifikationer i appen. Opret en notifications-tabel (user, type, title, body, link, created_at, read_at). Tilføj en serverfunktion notify(userId, type, data), som alle funktioner kalder. Vis et klokkeikon i headeren med et antal ulæste, en dropdown med de seneste 20, og en knap til "markér alle som læst". Hent nye hvert 60. sekund.

Derefter indstillinger og e-mail:

Tilføj notifikationsindstillinger: for hver type (svar på kommentarer, omtaler, fakturering) kan brugeren vælge i appen, e-mail, begge eller ingen. notify() skal respektere disse. Send e-mail via [UDBYDER] med hemmeligheden [ENV_NAVN] kun på serveren. Gruppér kommentar-e-mails, så en bruger højst får én e-mail hvert 15. minut.

Derefter push, hvis du har brug for det:

Tilføj valgfri web push. Registrér en service worker, generér VAPID-nøgler og gem den private nøgle som en hemmelighed. Tilføj en knap "Aktivér notifikationer" i indstillingerne, der først beder om tilladelse, når den klikkes. Gem hvert abonnement pr. bruger og enhed, send push fra notify(), når brugeren har tilvalgt det, og slet abonnementer, som push-tjenesten melder som udløbet.

Almindelige fejl

• Notifikationer spredt rundt i koden. Hver funktion sender sin egen e-mail på sin egen måde, og indstillinger bliver ignoreret. Brug én notify()-funktion.
• At bede om push-tilladelse ved sideindlæsning. De fleste siger nej, og du får måske ikke en ny chance.
• Ingen indstillinger. Brugere, der ikke kan slå støjende alarmer fra, slår alle fra eller forlader appen.
• Afsendelse fra browseren. E-mail- og push-nøgler hører hjemme på serveren.
• Ikke at rydde døde push-abonnementer op. Udløbne abonnementer hober sig op og spilder afsendelser.
• Følsomme detaljer i notifikationsteksten. Låseskærme viser den. "Du har en ny besked" er tryggere end selve beskeden.
• Ingen log over, hvad der blev sendt. Når en bruger siger "jeg fik aldrig mailen", hjælper logs med udbyderens besked-ID'er dig med at finde ud af hvorfor.

Tjekliste

• Én server-side notify()-funktion brugt overalt
• Notifikationstabel med læsestatus, og en klokke med antal ulæste
• Kanalindstillinger pr. type, respekteret af notify()
• E-mail sendt fra serveren med et verificeret domæne; oversigt eller gruppering for hyppige hændelser
• Push-tilladelse bedes kun om efter en brugerhandling, med en forklaring
• Push testet på desktop og på en iPhone med appen føjet til startskærmen
• Udløbne push-abonnementer fjernet
• Ingen følsomt indhold i push- eller e-mail-forhåndsvisninger
• Planlagte påmindelser har en pålidelig trigger

Notifikationer på Mythex

Mythex har ikke en indbygget e-mail- eller push-tjeneste til de apps, du bygger, så du medbringer din egen e-mailudbyder og genererer dine egne push-nøgler, gemt som projekthemmeligheder. Delen i appen kræver kun projektets database, som Mythex tilføjer, når du beder om det. Byg med prompts som dem ovenfor, test klokken og e-mails i Preview, og test push på din udgivne URL, for service workers og push kræver en rigtig HTTPS-adresse. Opskriften Send e-mail fra din app i dokumentationen har en startprompt. Mythex dokumenterer ikke planlagte jobs, så planlæg tidsstyrede påmindelser med en ekstern trigger som beskrevet i sådan kører du baggrundsjobs.

Spørgsmål