Értesítések hozzáadása az appodhoz: alkalmazáson belüli, e-mail és push

Ahhoz, hogy értesítéseket adj egy webappához, kezdd alkalmazáson belüli értesítésekkel: egy értesítéstáblával az adatbázisban és egy harangikonnal, amely az olvasatlan elemeket mutatja. Az e-mailt azokra a dolgokra használd, amelyekről az embereknek távollétükben is tudniuk kell, e-mail-szolgáltatón keresztül, a webes push-t pedig csak akkor add hozzá, ha az időben érkező figyelmeztetések valóban fontosak, mert ehhez service worker, felhasználói engedély és iPhone-on a kezdőképernyőre mentett app szükséges. Bármelyik csatornát is használod, minden értesítést egyetlen helyen, a szerveren hozz létre, és hagyd, hogy a felhasználók válasszák ki, mit kapnak.

Ez az útmutató összehasonlítja a csatornákat, egyszerű architektúrát mutat, és promptokat ad, amelyeket AI app-építővel használhatsz.

A fő csatornák összehasonlítva

A legtöbb appnak az alkalmazáson belüli és az e-mailes értesítés kell. A push és az SMS akkor éri meg, ha az időzítés tényleg számít, például egy foglalás emlékeztetője vagy egy kész rendelés.

Hogyan illeszkedik össze egy értesítési rendszer

Tartsd egyszerűnek és központosítottnak:

1. Történik valami. Hozzászólást írnak, sikertelen a fizetés, holnap van egy foglalás.
2. A szervered egyetlen függvényt hív, például notify(user, type, data).
3. Ez a függvény ellenőrzi a felhasználó beállításait, és ír egy sort a notifications táblába (a harangnak).
4. Ezután továbbküldi más csatornákra, amelyeket a felhasználó az adott típushoz bekapcsolt: e-mailt a szolgáltatónkon át, push-ot a Push API-n keresztül.
5. A frontend megmutatja az olvasatlan értesítéseket, és megnyitáskor megjelöli őket olvasottnak.

Egyetlen belépési pont azt jelenti, hogy csatornát adhatsz hozzá, szöveget módosíthatsz, és tiszteletben tarthatod a beállításokat anélkül, hogy a kódbázisban kellene keresgélned.

Mit kell tárolni

Egy értesítéstáblának általában ezek kellenek: felhasználói azonosító, típus (például comment_reply), rövid cím és szöveg, hivatkozás a releváns oldalra, létrehozás ideje és olvasás ideje. Külön beállítástábla tárolja, melyik csatornát szeretné minden felhasználó minden típusnál.

Új értesítések megjelenítése

• Betöltés oldalmegtekintéskor, és lekérdezés 30–60 másodpercenként. Egyszerű és megbízható.
• Valós idejű frissítés WebSockettel vagy szerveroldali eseményekkel azonnalinak tűnik, de több mozgó alkatrészt ad. Kezdd a lekérdezéssel, hacsak nem fontos az azonnali frissítés.

E-mail-értesítések

Az e-mailhez küldő szolgáltató és ellenőrzött domain kell; a részleteket az e-mail küldése az appodból útmutató tartalmazza. Kifejezetten az értesítésekre:

• Szerverről küldj. A szolgáltatói kulcs soha ne kerüljön a böngészőbe.
• Csoportosítsd a sok eseményt. Egy e-mail „3 új hozzászólás” szöveggel jobb, mint három külön e-mail.
• Ajánlj napi vagy heti összefoglalót az alacsony prioritású tevékenységhez.
• Tegyél leiratkozási vagy beállítási linket a nem alapvető e-mailekbe. A marketing-e-mailekre vonatkozó szabályok országonként eltérnek; nézd meg, mi vonatkozik rád.

Webes push-értesítések

A webes push olyan figyelmeztetéseket tesz lehetővé, amelyek az app-értesítésekhez hasonlóan jelennek meg. Az MDN Push API dokumentációja szerint így működik:

1. Az oldalad regisztrál egy service workert, vagyis egy szkriptet, amelyet a böngésző a háttérben futtathat.
2. A felhasználó beleegyezése után a service worker feliratkozik a PushManager.subscribe() hívással. A böngésző egy feliratkozást ad vissza, amely egy végpontot és titkosítási kulcsokat tartalmaz.
3. A szervered elmenti ezt a feliratkozást, és amikor történik valami, üzenetet küld a végpontra, általában VAPID-kulcsokkal aláírva (ezek egy kulcspár, amely azonosítja a szerveredet).
4. A böngésző elindítja a service workeredet, amely megjeleníti az értesítést akkor is, ha az oldalad nincs nyitva.

Az MDN azt is megjegyzi, hogy a végpontot titokban kell tartani, mert ennek ismerete elég ahhoz, hogy üzeneteket küldj az adott felhasználónak.

iPhone és iPad

A WebKit az iOS és iPadOS 16.4 verziójától támogatja a webes push-t a webappoknál, a bejelentésük szerint két feltétellel: a webappot hozzá kell adni a kezdőképernyőhöz, és az engedélyt egy felhasználói művelet – például egy Feliratkozás gomb koppintása – után kell kérni. Tehát iPhone-on a push csak azokhoz a felhasználókhoz jut el, akik telepítették a webappodat. Arról, mit jelent egy webapp telepítése, lásd a natív és progresszív webappok útmutatót.

Hogyan kérj engedélyt jól

Ne kérj engedélyt az első látogatáskor. Előbb magyarázd el az előnyt („Kapj emlékeztetőt egy órával az óra előtt”), és csak akkor mutasd a böngésző kérdését, amikor a felhasználó megnyom egy gombot. Ha valaki elutasítja, a böngésző lehet, hogy nem engedi újra megkérdezni, így egy korai kérdés véglegesen elveszíthet valakit.

Az időzített értesítésekhez indító esemény kell

A „emlékeztető 24 órával előtte” vagy a „heti összefoglaló minden hétfőn” olyasmit igényel, ami ütemezetten fut. Ez egy háttérfeladat-probléma, amelyet a háttérfeladatok futtatása útmutató tárgyal. Gyakori minta: egy külső ütemező néhány percenként meghív egy védett végpontot, amely elküldi az esedékes értesítéseket.

Promptok az AI app-építőnek

Kezdd az alkalmazáson belülivel:

Adj hozzá alkalmazáson belüli értesítéseket. Hozz létre egy notifications táblát (user, type, title, body, link, created_at, read_at). Adj hozzá egy notify(userId, type, data) szerverfüggvényt, amelyet minden funkció hív. A fejlécben jelenjen meg egy harangikon olvasatlan számlálóval, a legutóbbi 20 értesítés legördülő listával és egy „mindet olvasottnak jelöl” gombbal. 60 másodpercenként kérdezz le újakat.

Utána a beállítások és az e-mail:

Adj hozzá értesítési beállításokat: típusonként (válaszok a hozzászólásokra, megemlítések, számlázás) a felhasználó válassza ki, hogy alkalmazáson belül, e-mailben, mindkettőben vagy egyikben sem. A notify() tartsa tiszteletben ezeket. Küldj e-mailt a [SZOLGÁLTATÓ] segítségével, a [ENV_NAME] titkot használva, kizárólag a szerveren. A hozzászólásokról szóló e-maileket csoportosítsd úgy, hogy egy felhasználó legfeljebb egy e-mailt kapjon 15 percenként.

Végül a push, ha szükséged van rá:

Adj hozzá opcionális webes push-t. Regisztrálj egy service workert, generálj VAPID-kulcsokat, és a privát kulcsot tárold titokként. Adj hozzá egy „Értesítések bekapcsolása” gombot a beállításokban, amely csak kattintásra kéri az engedélyt. Minden feliratkozást tárolj felhasználónként és eszközönként, küldj push-okat a notify()-ból, ha a felhasználó bekapcsolta, és töröld azokat a feliratkozásokat, amelyeket a push-szolgáltató lejártnak jelez.

Gyakori hibák

• Szétszórt értesítések a kódban. Minden funkció a saját módján küld e-mailt, és a beállításokat figyelmen kívül hagyják. Használj egyetlen notify() függvényt.
• Push-engedély kérése oldalbetöltéskor. A legtöbben elutasítják, és lehet, hogy nem kapsz második esélyt.
• Nincsenek beállítások. Aki nem tudja kikapcsolni a zavaró értesítéseket, kikapcsolja mindet, vagy elmegy.
• Küldés a böngészőből. Az e-mail- és push-kulcsok a szerverre tartoznak.
• Lejárt push-feliratkozások nem törlése. A lejárt feliratkozások felhalmozódnak, és felesleges küldéseket okoznak.
• Érzékeny adatok az értesítés szövegében. A zárolási képernyőn megjelenik. Biztonságosabb a „Új üzeneted érkezett” szöveg, mint maga az üzenet.
• Nincs nyilvántartás arról, mi ment ki. Amikor valaki azt mondja, „nem kaptam meg az e-mailt”, a szolgáltató üzenetazonosítóival ellátott naplók segítenek kideríteni az okot.

Ellenőrzőlista

• Egyetlen szerveroldali notify() függvény, amelyet mindenhol használsz
• Értesítési tábla olvasási állapottal, és harang olvasatlan számlálóval
• Típusonkénti csatornabeállítások, amelyeket a notify() tiszteletben tart
• Az e-mail szerverről megy ki, ellenőrzött domainnel; összevonás vagy összefoglaló a sok eseményre
• Push-engedély csak felhasználói művelet után, magyarázattal
• A push tesztelve asztali gépen és iPhone-on, a kezdőképernyőre mentett appal
• A lejárt push-feliratkozások eltávolítva
• Nincs érzékeny tartalom a push- vagy e-mail-előnézetben
• Az időzített emlékeztetőknek megbízható indítójuk van

Értesítések a Mythexen

A Mythex nem tartalmaz beépített e-mail- vagy push-szolgáltatást az általad épített appokhoz, ezért a saját e-mail-szolgáltatódat kell használnod, a push-kulcsaidat pedig magad generálod, és a projekt titkaiként tárolod. Az alkalmazáson belüli rész csak a projekt adatbázisát igényli, amelyet a Mythex akkor ad hozzá, amikor kéred. Építs a fenti promptokkal, teszteld a harangot és az e-maileket az előnézetben, a push-t pedig a közzétett URL-en, mert a service workerek és a push valódi HTTPS-címet igényelnek. A dokumentációs E-mail küldése az appodból recept tartalmaz kezdő promptot. A Mythex nem dokumentálja az ütemezett feladatokat, ezért az időzített emlékeztetőket külső indítóval tervezd meg, ahogy a háttérfeladatok futtatása útmutató leírja.

Kérdések