Kako dodati obaveštenja u aplikaciju: u aplikaciji, email i push

Da biste dodali obaveštenja web aplikaciji, počnite sa obaveštenjima u aplikaciji: tabelom obaveštenja u bazi i ikonom zvonca koja prikazuje nepročitane stavke. Dodajte email za stvari koje ljudi treba da znaju kada nisu u aplikaciji, koristeći provajdera za email, a web push dodajte samo kada su blagovremena upozorenja bitna, jer zahteva service worker, dozvolu korisnika i, na iPhone-u, aplikaciju sačuvanu na početnom ekranu. Koje god kanale koristite, kreirajte svako obaveštenje na jednom mestu na serveru i neka korisnici biraju šta žele da primaju.

Ovaj vodič upoređuje kanale, pokazuje jednostavnu arhitekturu i daje prompt-ove koje možete koristiti sa AI alatom za izradu aplikacija.

Glavni kanali upoređeni

Većina aplikacija treba obaveštenja u aplikaciji plus email. Push i SMS vredi koristiti kada vreme zaista važi, poput podsetnika za rezervaciju ili porudžbine koja je spremna.

Kako se sistem obaveštenja uklapa

Neka bude jednostavno i centralizovano:

1. Nešto se desi. Objavljen je komentar, plaćanje ne uspe, rezervacija je sutra.
2. Vaš server poziva jednu funkciju, npr. notify(user, type, data).
3. Ta funkcija proverava korisnička podešavanja i upisuje red u tabelu notifications (za zvonce).
4. Zatim šalje na druge kanale koje je korisnik uključio za taj tip: email preko vašeg provajdera, push preko Push API-ja.
5. Frontend prikazuje nepročitana obaveštenja i označava ih pročitanim kada se otvore.

Jedna ulazna tačka znači da možete dodati kanal, promeniti tekst ili poštovati podešavanja bez traženja po celom kodu.

Šta čuvati

Tabela obaveštenja obično treba: ID korisnika, tip (na primer comment_reply), kratak naslov i tekst, link ka relevantnoj stranici, vreme kreiranja i vreme čitanja. Posebna tabela podešavanja čuva koje kanale svaki korisnik želi za svaki tip.

Prikazivanje novih obaveštenja

• Učitavanje pri otvaranju stranice i proveravanje svakih 30–60 sekundi. Jednostavno i pouzdano.
• Ažuriranja u realnom vremenu pomoću WebSocket-a ili server-sent events deluju trenutno, ali dodaju pokretne delove. Počnite sa proveravanjem, osim ako trenutna ažuriranja nisu bitna.

Email obaveštenja

Email zahteva provajdera za slanje i verifikovan domen; detalji su u vodiču kako slati emailove iz vaše aplikacije. Za obaveštenja posebno:

• Šaljite sa servera, nikada sa ključem provajdera u pregledaču.
• Grupišite česte događaje. „3 nova komentara” u jednom emailu bolje je od tri zasebna emaila.
• Ponudite dnevni ili nedeljni pregled za aktivnost niskog prioriteta.
• Uključite link za odjavu ili podešavanja u neesencijalnim emailovima. Pravila za marketinške emailove se razlikuju po državama; proverite šta se primenjuje na vas.

Web push obaveštenja

Web push omogućava da vaš sajt šalje upozorenja koja izgledaju kao obaveštenja aplikacije. Prema MDN-ovoj dokumentaciji za Push API, radi ovako:

1. Vaš sajt registruje service worker, skriptu koju pregledač može da pokreće u pozadini.
2. Kada se korisnik saglasi, service worker se pretplaćuje preko PushManager.subscribe(). Pregledač vraća pretplatu sa krajnjom tačkom i ključevima za šifrovanje.
3. Vaš server čuva tu pretplatu i, kada se nešto desi, šalje poruku krajnjoj tački, obično potpisanu VAPID ključevima (par ključeva koji identifikuje vaš server).
4. Pregledač pokreće vaš service worker, koji prikazuje obaveštenje, čak i ako vaša stranica nije otvorena.

MDN takođe napominje da krajnju tačku treba čuvati u tajnosti, jer je dovoljno da se zna da bi se tom korisniku slale poruke.

iPhone i iPad

WebKit je dodao Web Push za web aplikacije u iOS-u i iPadOS-u 16.4, uz dva uslova iz njihove najave: sajt mora biti dodat na početni ekran, a dozvola se mora tražiti kao odgovor na radnju korisnika, poput dodira na dugme Pretplati se. Dakle, na iPhone-u push stiže samo korisnicima koji su instalirali vašu web aplikaciju. Pogledajte native vs progresivne web aplikacije za značenje instaliranja web aplikacije.

Dobro traženje dozvole

Ne tražite dozvolu pri prvoj poseti. Prvo objasnite korist („Dobijte podsetnik sat vremena pre časa”), a zatim pokažite prompt pregledača kada korisnik dodirne dugme. Ako neko odbije, pregledač možda neće dozvoliti ponovno pitanje, pa preuranjeni prompt može zauvek da izgubi tog korisnika.

Zakazana obaveštenja traže okidač

„Podsetnik 24 sata pre” ili „nedeljni pregled svakog ponedeljka” zahtevaju nešto što radi po rasporedu. To je problem pozadinskih poslova, obrađen u vodiču kako pokretati pozadinske poslove. Čest obrazac: spoljni planer poziva zaštićenu krajnju tačku na svakih nekoliko minuta, a ta krajnja tačka šalje ono što je na redu.

Prompt-ovi za vaš AI alat

Počnite sa obaveštenjima u aplikaciji:

Dodajte obaveštenja u aplikaciji. Napravite tabelu notifications (user, type, title, body, link, created_at, read_at). Dodajte serversku funkciju notify(userId, type, data) koju poziva svaka funkcija. Prikažite ikonu zvonca u zaglavlju sa brojem nepročitanih, padajući meni sa poslednjih 20 i dugme „označi sve kao pročitano”. Proveravajte nova obaveštenja svakih 60 sekundi.

Zatim podešavanja i email:

Dodajte podešavanja obaveštenja: za svaki tip (odgovori na komentare, pominjanja, naplata) neka korisnik izabere u aplikaciji, email, oba ili nijedno. notify() mora to da poštuje. Šaljite email preko [PROVAJDER] koristeći tajnu [ENV_NAME] samo na serveru. Grupišite emailove o komentarima tako da jedan korisnik dobija najviše jedan email na 15 minuta.

Zatim push, ako vam treba:

Dodajte opcioni web push. Registrujte service worker, generišite VAPID ključeve i privatni ključ sačuvajte kao tajnu. Dodajte dugme „Uključi obaveštenja” u podešavanjima koje traži dozvolu tek kada se klikne. Čuvajte svaku pretplatu po korisniku i uređaju, šaljite push iz notify() kada je korisnik uključio, i obrišite pretplate koje servis za push javi kao istekle.

Česte greške

• Obaveštenja raštrkana po kodu. Svaka funkcija šalje svoj email na svoj način, a podešavanja se ignorišu. Koristite jednu funkciju notify().
• Traženje dozvole za push pri učitavanju stranice. Većina ljudi odbije, a možda nećete dobiti još jednu šansu.
• Bez podešavanja. Korisnici koji ne mogu da isključe dosadna upozorenja isključe sva ili odu.
• Slanje iz pregledača. Ključevi za email i push pripadaju serveru.
• Neuklanjanje mrtvih push pretplata. Istekle pretplate se gomilaju i troše slanja.
• Osetljivi detalji u tekstu obaveštenja. Zaključani ekrani ih prikazuju. „Imate novu poruku” je bezbednije od same poruke.
• Nema zapisa o tome šta je poslato. Kada korisnik kaže „nikad nisam dobio email”, logovi sa ID-jevima poruka od provajdera pomažu da saznate zašto.

Kontrolna lista

• Jedna serverska funkcija notify() koja se koristi svuda
• Tabela obaveštenja sa stanjem čitanja i zvonce sa brojem nepročitanih
• Podešavanja kanala po tipu, koja poštuje notify()
• Email se šalje sa servera uz verifikovan domen; pregled ili grupisanje za česte događaje
• Dozvola za push se traži tek nakon radnje korisnika, uz objašnjenje
• Push testiran na desktopu i na iPhone-u sa aplikacijom na početnom ekranu
• Istekle push pretplate uklonjene
• Nema osetljivog sadržaja u pregledu push-a ili emaila
• Zakazani podsetnici imaju pouzdan okidač

Obaveštenja na Mythexu

Mythex ne uključuje ugrađenu uslugu za email ili push za aplikacije koje pravite, pa sami donosite provajdera za email i generišete sopstvene push ključeve, sačuvane kao tajne projekta. Deo za obaveštenja u aplikaciji treba samo bazu projekta, koju Mythex dodaje kada to zatražite. Gradite prompt-ovima kao iznad, testirajte zvonce i emailove u Preview-u, a push testirajte na objavljenoj URL adresi, jer service worker-i i push zahtevaju pravu HTTPS adresu. Recept u dokumentaciji Slanje emaila iz vaše aplikacije ima početni prompt. Mythex ne dokumentuje zakazane poslove, pa planirajte podsetnike po vremenu uz spoljni okidač, kao što je opisano u vodiču kako pokretati pozadinske poslove.

Pitanja