Како да додадете известувања во вашата апликација: во апликацијата, е-пошта и push

За да додадете известувања во веб-апликација, почнете со известувања во самата апликација: табела со известувања во базата на податоци и икона со ѕвонче што ги прикажува непрочитаните ставки. Додајте е-пошта за работи што луѓето треба да ги знаат кога не се активни, со давател на е-пошта, а web push додајте само кога навремените известувања навистина се важни, бидејќи бара service worker, дозвола од корисникот и, на iPhone, апликацијата зачувана на почетниот екран. Кои и да се каналите што ги користите, секое известување создавајте го на едно место, на серверот, и дозволете корисниците сами да избираат што ќе примаат.

Овој водич ги споредува каналите, покажува едноставна архитектура и дава упатства што можете да ги користите со AI градител на апликации.

Главните канали споредени

Повеќето апликации им треба известување во апликацијата плус е-пошта. Push и SMS вредат кога времето навистина е важно, како потсетник за резервација или нарачка што е подготвена.

Како се поврзува системот за известувања

Неговете едноставно и централизирано:

1. Нешто се случува. Се објавува коментар, плаќањето не успева, резервацијата е утре.
2. Серверот повикува една функција, на пример notify(user, type, data).
3. Функцијата ги проверува поставките на корисникот и запишува ред во табелата notifications (за ѕвончето).
4. Потоа испраќа до другите канали што корисникот ги вклучил за тој тип: е-пошта преку вашиот давател, push преку Push API.
5. Фронтендот ги прикажува непрочитаните известувања и ги означува како прочитани кога ќе се отворат.

Една единствена точка на влез значи дека можете да додадете канал, да го промените текстот или да ги почитувате поставките без да барате низ целата кодна база.

Што да се чува

Табелата за известувања обично треба: ID на корисникот, тип (на пример comment_reply), кус наслов и текст, врска до соодветната страница, време на создавање и време на читање. Посебна табела за поставки чува кои канали ги сака секој корисник за секој тип.

Прикажување на нови известувања

• Вчитување при прикажување на страницата и polling на секои 30–60 секунди. Едноставно и поуздано.
• Ажурирања во реално време со WebSockets или server-sent events делуваат моментално, но додаваат подвижни делови. Почнете со polling освен ако моменталните ажурирања навистина не се важни.

Известувања по е-пошта

Е-поштата бара давател за испраќање и верифициран домен; деталите се во како да испраќате е-пошта од вашата апликација. За известувањата специјално:

• Испраќајте од серверот, никогаш со клуч на давателот во прелистувачот.
• Групирајте ги честите настани. „3 нови коментари“ во една е-порака е подобро од три е-пораки.
• Понудете дневен или неделен преглед за активност со низок приоритет.
• Вклучете линк за отпишување или за поставки во неважната е-пошта. Правилата за маркетишка е-пошта се разликуваат по земја; проверете што важи за вас.

Web push известувања

Web push ви дозволува на страницата да испраќа известувања што изгледаат како известувања од апликација. Според документацијата на MDN за Push API, функционира вака:

1. Вашата страница регистрира service worker, скрипта што прелистувачот може да ја извршува во позадина.
2. Откако корисникот ќе се согласи, service worker-от се претплатува преку PushManager.subscribe(). Прелистувачот враќа претплата со крајна точка и клучеви за шифрирање.
3. Вашиот сервер ја чува таа претплата и, кога ќе се случи нешто, испраќа порака до крајната точка, обично потпишана со VAPID клучеви (пар клучеви што го идентификува вашиот сервер).
4. Прелистувачот го стартува вашиот service worker, кој го прикажува известувањето, дури и ако вашата страница не е отворена.

MDN исто така напоменува дека крајната точка треба да се чува тајна, бидејќи само со нејзино познавање може да се испраќаат пораки до тој корисник.

iPhone и iPad

WebKit додаде Web Push за веб-апликации во iOS и iPadOS 16.4, со два услова од најавата: страницата мора да е додадена на почетниот екран, а дозволата мора да се бара како одговор на дејство на корисникот, како допир на копчето Subscribe. Значи на iPhone push допира само до корисници што ја инсталирале вашата веб-апликација. Видете native наспрема progressive веб-апликации за тоа што значи инсталирање на веб-апликација.

Добро барање дозвола

Не прашувајте при првата посета. Прво објаснете ја корисноста („Добијте потсетник еден час пред часот“), а потоа прикажете го прозорецот на прелистувачот кога корисникот ќе допре копче. Ако некој одбие, прелистувачот можеби нема да дозволи повторно прашување, па предвремената порака може засекогаш да го загуби.

Закажаните известувања им треба окидач

„Потсетник 24 часа пред“ или „неделен преглед секој понеделник“ бараат нешто што работи по распоред. Тоа е проблем со позадински задачи, опфатен во како да пуштате позадински задачи. Чест образец: надворешен распоредувач повикува заштитена крајна точка на секои неколку минути, а таа крајна точка ги испраќа оние што се должни.

Упатства за вашиот AI градител

Почнете со известувања во апликацијата:

Додај известувања во апликацијата. Создај табела notifications (user, type, title, body, link, created_at, read_at). Додај серверска функција notify(userId, type, data) што секоја функција ја повикува. Прикажи икона со ѕвонче во заглавјето со бројач на непрочитани, паѓачко мени со последните 20 и копче „означи сè како прочитано“. Проверувај за нови на секои 60 секунди.

Потоа поставки и е-пошта:

Додај поставки за известувања: за секој тип (одговори на коментари, спомнувања, наплата) корисникот избира во апликацијата, е-пошта, двете или ништо. notify() мора да ги почитува овие поставки. Испраќај е-пошта преку [ПРОВАЈДЕР] со тајната [ENV_NAME] само на серверот. Групирај ги е-поштите за коментари, така еден корисник да добие највеќе една е-порака на 15 минути.

Потоа push, ако ви треба:

Додај опционален web push. Регистрирај service worker, генерирај VAPID клучеви и приватниот клуч чувај го како тајна. Додај копче „Овозможи известувања“ во поставките што ја бара дозволата само кога ќе се кликне. Чувај ја секоја претплата по корисник и уред, испраќај push од notify() кога корисникот се согласил, и избриши ги претплатите што push сервисот ги јавува како истечени.

Чести грешки

• Известувањата расфрлани низ кодот. Секоја функција испраќа е-пошта на свој начин, а поставките се игнорираат. Користете една функција notify().
• Барање push дозвола при вчитување на страницата. Повеќето луѓе одбиваат, а можеби нема да добиете друга шанса.
• Без поставки. Корисниците што не можат да исклучат досадни известувања ги исклучуваат сите или заминуваат.
• Испраќање од прелистувачот. Клучевите за е-пошта и push припаѓаат на серверот.
• Непочистени мртви push претплати. Истечените претплати се натрупуваат и трошат испраќања.
• Чувствителни детали во текстот на известувањето. Заклучените екрани го прикажуваат. „Имате нова порака“ е побезбедно од самата порака.
• Нема запис за тоа што е испратено. Кога корисник ќе рече „никогаш не ја добив е-порака“, логовите со ID-а на пораките од давателот ви помагаат да дознаете зошто.

Контролна листа

• Една серверска функција notify() се користи секаде
• Табела за известувања со состојба на читање и ѕвонче со бројач на непрочитани
• Поставки за канали по тип, почитувани од notify()
• Е-пошта испратена од серверот со верифициран домен; групирање или преглед за честите настани
• Push дозволата се бара само по дејство на корисникот, со објаснување
• Push тестиран на компјутер и на iPhone со апликацијата додадена на почетниот екран
• Истечените push претплати се отстранети
• Нема чувствителна содржина во прегледите на push или е-пошта
• Закажаните потсетници имаат сигурен окидач

Известувања во Mythex

Mythex не вклучува вграден сервис за е-пошта или push за апликациите што ги градите, па сами донесувате давател за е-пошта и генерирате push клучеви, кои се чуваат како тајни на проектот. Делот за известувања во апликацијата треба само базата на податоци на проектот, која Mythex ја додава кога ќе ја побарате. Градете со упатства како горенаведените, тестирајте го ѕвончето и е-поштата во Preview, а push тестирајте на објавената URL адреса, бидејќи service worker-ите и push бараат вистинска HTTPS адреса. Рецептот во документацијата Испраќање е-пошта од вашата апликација има почетно упатство. Mythex не документира закажани задачи, па планирајте временските потсетници со надворешен окидач како што е опишано во како да пуштате позадински задачи.

Прашања