Slik legger du til varsler i appen: i appen, e-post og push

For å legge til varsler i en nettapp, start med varsler i appen: en tabell med varsler i databasen og en klokkeikon som viser uleste elementer. Legg til e-post for ting folk må vite når de er borte, ved hjelp av en e-postleverandør, og legg til web push bare når tidsriktige varsler virkelig betyr noe. Push krever en service worker, brukerens tillatelse og, på iPhone, at appen er lagret på startskjermen. Uansett hvilke kanaler du bruker, bør alle varsler opprettes på ett sted på serveren, og brukerne bør kunne velge hva de vil motta.

Denne guiden sammenligner kanalene, viser en enkel arkitektur og gir ledetekster du kan bruke med en KI-app-bygger.

De viktigste kanalene sammenlignet

De fleste apper trenger varsler i appen pluss e-post. Push og SMS er verdt det når timingen virkelig betyr noe, for eksempel en påminnelse om bestilling eller en bestilling som er klar.

Slik henger et varslingssystem sammen

Hold det enkelt og sentralt:

1. Noe skjer. En kommentar blir lagt inn, en betaling feiler, en bestilling er i morgen.
2. Serveren din kaller én funksjon, for eksempel notify(user, type, data).
3. Funksjonen sjekker brukerens innstillinger og skriver en rad til tabellen notifications (for klokken).
4. Deretter sender den til andre kanaler brukeren har slått på for den typen: e-post via leverandøren din, push via Push API.
5. Frontend viser uleste varsler og markerer dem som lest når de åpnes.

Et enkelt inngangspunkt gjør at du kan legge til en kanal, endre formuleringer eller respektere innstillinger uten å lete gjennom hele kodebasen.

Hva du bør lagre

En tabell for varsler trenger vanligvis: bruker-ID, type (for eksempel comment_reply), en kort tittel og tekst, en lenke til relevant side, opprettelsestidspunkt og lesetidspunkt. En egen innstillingstabell lagrer hvilke kanaler hver bruker vil ha for hver type.

Vise nye varsler

• Last inn ved sidevisning og spør etter nye hvert 30.–60. sekund. Enkelt og pålitelig.
• Sanntidsoppdateringer med WebSockets eller server-sent events føles øyeblikkelige, men gir flere bevegelige deler. Start med polling hvis ikke øyeblikkelige oppdateringer er viktige.

E-postvarsler

E-post krever en leverandør for utsending og et verifisert domene. Detaljene står i slik sender du e-post fra appen din. For varsler spesifikt:

• Send fra serveren, aldri med en leverandørnøkkel i nettleseren.
• Samle hyppige hendelser. «3 nye kommentarer» i én e-post er bedre enn tre e-poster.
• Tilby et daglig eller ukentlig sammendrag for aktivitet med lav prioritet.
• Ta med en lenke for avmelding eller innstillinger i e-post som ikke er nødvendig. Reglene for markedsføringse-post varierer mellom land, så sjekk hva som gjelder for deg.

Web push-varsler

Web push lar nettstedet ditt sende varsler som ser ut som app-varsler. Slik fungerer det ifølge MDN-dokumentasjonen for Push API:

1. Nettstedet ditt registrerer en service worker, et skript som nettleseren kan kjøre i bakgrunnen.
2. Etter at brukeren har godtatt, abonnerer service workeren gjennom PushManager.subscribe(). Nettleseren returnerer et abonnement med et endepunkt og krypteringsnøkler.
3. Serveren din lagrer abonnementet, og når noe skjer, sender den en melding til endepunktet. Den signeres vanligvis med VAPID-nøkler (et nøkkelpar som identifiserer serveren din).
4. Nettleseren starter service workeren din, som viser varselet selv om siden din ikke er åpen.

MDN påpeker også at endepunktet bør holdes hemmelig, fordi det er nok å kjenne det for å sende meldinger til den brukeren.

iPhone og iPad

WebKit la til web push for webapper i iOS og iPadOS 16.4, med to vilkår fra kunngjøringen: nettstedet må være lagt til på startskjermen, og tillatelsen må spørres om som svar på en brukerhandling, for eksempel et trykk på en Abonner-knapp. På iPhone når push derfor bare brukere som har installert webappen din. Se native vs progressive web apps for hva det innebærer å installere en webapp.

Be om tillatelse på riktig måte

Spør ikke ved første besøk. Forklar nytten først («Få en påminnelse én time før timen»), og vis nettleserens forespørsel når brukeren trykker på en knapp. Hvis noen sier nei, kan nettleseren hindre deg i å spørre igjen. En for tidlig forespørsel kan derfor koste deg dem for godt.

Planlagte varsler trenger en utløser

«Påminnelse 24 timer før» eller «ukentlig oppsummering hver mandag» må kjøres etter en plan. Det er et problem med bakgrunnsjobber, som er dekket i slik kjører du bakgrunnsjobber. Et vanlig mønster: en ekstern planlegger kaller et beskyttet endepunkt hvert par minutter, og endepunktet sender det som forfaller.

Ledetekster til KI-byggeren

Start med varsler i appen:

Legg til varsler i appen. Opprett en tabell notifications (user, type, title, body, link, created_at, read_at). Legg til en serverfunksjon notify(userId, type, data) som alle funksjoner kaller. Vis en klokkeikon i toppfeltet med antall uleste, en nedtrekksliste med de 20 siste, og en knapp for å markere alle som lest. Hent nye varsler hvert 60. sekund.

Deretter innstillinger og e-post:

Legg til varselinnstillinger: for hver type (svar på kommentarer, omtaler, fakturering) kan brukeren velge i appen, e-post, begge eller ingen. notify() må respektere disse. Send e-post via [LEVERANDØR] med hemmeligheten [ENV_NAVN] bare på serveren. Gruppér e-poster om kommentarer slik at en bruker får høyst én e-post per 15 minutter.

Deretter push, hvis du trenger det:

Legg til valgfri web push. Registrer en service worker, generer VAPID-nøkler og lagre den private nøkkelen som hemmelighet. Legg til en knapp «Slå på varsler» i innstillingene som først ber om tillatelse når den klikkes. Lagre hvert abonnement per bruker og enhet, send push fra notify() når brukeren har takket ja, og slett abonnementer som push-tjenesten melder som utløpt.

Vanlige feil

• Varsler spredt rundt i koden. Hver funksjon sender sin egen e-post på sin måte, og innstillingene blir ignorert. Bruk én notify()-funksjon.
• Be om push-tillatelse ved sidelasting. De fleste sier nei, og du får kanskje ikke en ny sjanse.
• Ingen innstillinger. Brukere som ikke kan slå av plagsomme varsler, slår av alle eller slutter å bruke appen.
• Sending fra nettleseren. Nøkler for e-post og push hører hjemme på serveren.
• Ikke rydde bort døde push-abonnementer. Utløpte abonnementer hoper seg opp og kaster bort sendinger.
• Sensitive detaljer i varseltekst. Låseskjermer viser den. «Du har en ny melding» er tryggere enn selve meldingen.
• Ingen logg over hva som ble sendt. Når en bruker sier «jeg fikk aldri e-posten», hjelper logger med meldings-ID fra leverandøren deg å finne ut hvorfor.

Sjekkliste

• Én notify()-funksjon på serveren brukt overalt
• Tabell for varsler med lesestatus, og en klokke med antall uleste
• Innstillinger for kanal per type, respektert av notify()
• E-post sendt fra serveren med verifisert domene; sammendrag eller gruppering for hyppige hendelser
• Push-tillatelse spurt først etter en brukerhandling, med forklaring
• Push testet på datamaskin og på en iPhone med appen lagt til på startskjermen
• Utløpte push-abonnementer fjernet
• Ingen sensitivt innhold i push- eller e-postforhåndsvisninger
• Planlagte påminnelser har en pålitelig utløser

Varsler på Mythex

Mythex har ikke en innebygd e-post- eller push-tjeneste for appene du bygger, så du tar med din egen e-postleverandør og lager dine egne push-nøkler, lagret som prosjekthemmeligheter. Del i appen trenger bare prosjektets database, som Mythex legger til når du ber om det. Bygg med ledetekster som de over, test klokken og e-postene i forhåndsvisningen, og test push på din publiserte URL, fordi service workers og push krever en ekte HTTPS-adresse. Oppskriften i dokumentasjonen, Send e-post fra appen din, har en startledetekst. Mythex dokumenterer ikke planlagte jobber, så planlegg tidsstyrte påminnelser med en ekstern utløser slik det er beskrevet i slik kjører du bakgrunnsjobber.

Spørsmål