သင့်အက်ပ်သို့ အသိပေးချက်များ ထည့်နည်း: အက်ပ်အတွင်း၊ အီးမေးလ်နှင့် push

အက်ပ်အတွက် အသိပေးချက်များ ထည့်ရန် အက်ပ်အတွင်း အသိပေးချက်များ ဖြင့် စတင်ပါ: ဒေတာဘေ့စ်ထဲရှိ notifications table နှင့် မဖတ်ရသေးသောအရာများကို ပြသသော bell icon။ အချိန်မရွေး သိထားသင့်သော အရာများအတွက် email provider ကို အသုံးပြု၍ အီးမေးလ် ထည့်ပါ၊ အချိန်နှင့်တပြေးညီ သတိပေးချက်များ အရေးကြီးမှသာ web push ထည့်ပါ၊ ၎င်းသည် service worker၊ အသုံးပြုသူခွင့်ပြုချက်နှင့် iPhone တွင် အက်ပ်ကို Home Screen တွင် သိမ်းထားရန် လိုအပ်သည်။ မည်သည့်ချန်နယ်များ သုံးသည်ဖြစ်စေ notification အားလုံးကို server တစ်နေရာတည်းတွင် ဖန်တီးပြီး အသုံးပြုသူများက မည်သည်တို့ကို လက်ခံမည်ကို ရွေးခွင့်ပေးပါ။

ဤလမ်းညွှန်သည် ချန်နယ်များကို နှိုင်းယှဉ်ပြီး ရိုးရှင်းသော architecture ကို ပြသကာ AI app builder ဖြင့် သုံးနိုင်သော prompt များကို ပေးသည်။

အဓိက ချန်နယ်များ နှိုင်းယှဉ်ချက်

အက်ပ်အများစုအတွက် အက်ပ်အတွင်းနှင့် အီးမေးလ် လိုအပ်သည်။ ချိန်းဆိုမှု သတိပေးချက် သို့မဟုတ် မှာယူမှု အဆင်သင့်ဖြစ်ကြောင်း ကဲ့သို့ အချိန်အရေးကြီးမှသာ push နှင့် SMS တန်ဖိုးရှိသည်။

အသိပေးချက်စနစ် အလုပ်လုပ်ပုံ

ရိုးရှင်းပြီး ဗဟိုပြုထားပါ:

1. တစ်ခုခု ဖြစ်ပေါ်သည်။ မှတ်ချက်တင်သည်၊ ငွေပေးချေမှု မအောင်မြင်သည်၊ ချိန်းဆိုမှု မနက်ဖြန်ရှိသည်။
2. သင့် server က function တစ်ခုကို ခေါ်သည်၊ ဥပမာ notify(user, type, data)။
3. ထို function က အသုံးပြုသူ ဦးစားပေးမှုများကို စစ်ပြီး notifications table ထဲသို့ row တစ်ခု ရေးသည် (bell အတွက်)။
4. ထို့နောက် အသုံးပြုသူ ဖွင့်ထားသော အခြားချန်နယ်များသို့ ပို့သည်: သင့် provider မှတစ်ဆင့် အီးမေးလ်၊ Push API မှတစ်ဆင့် push။
5. frontend က မဖတ်ရသေးသော အသိပေးချက်များကို ပြသပြီး ဖွင့်လိုက်သောအခါ ဖတ်ပြီးအဖြစ် မှတ်သည်။

entry point တစ်ခုတည်းရှိခြင်းက ချန်နယ်တစ်ခု ထည့်ခြင်း၊ စာသား ပြောင်းခြင်းနှင့် ဦးစားပေးမှုများကို လေးစားခြင်းကို codebase တစ်ခုလုံး ရှာမနေဘဲ လုပ်နိုင်စေသည်။

ဘာတွေ သိမ်းရမလဲ

notifications table တွင် များသောအားဖြင့် user ID၊ အမျိုးအစား (ဥပမာ comment_reply)၊ တိုတောင်းသော title နှင့် body၊ သက်ဆိုင်ရာစာမျက်နှာသို့ link၊ ဖန်တီးချိန်နှင့် ဖတ်ချိန် လိုအပ်သည်။ သီးခြား preferences table တွင် အသုံးပြုသူတစ်ဦးစီက အမျိုးအစားတစ်ခုစီအတွက် မည်သည့်ချန်နယ်များ လိုချင်သည်ကို သိမ်းသည်။

အသစ်အသိပေးချက်များ ပြသခြင်း

• စာမျက်နှာဖွင့်သည့်အခါ တင်ပြီး ၃၀–၆၀ စက္ကန့်တိုင်း poll လုပ်ပါ။ ရိုးရှင်းပြီး ယုံကြည်ရသည်။
• Real-time update ကို WebSockets သို့မဟုတ် server-sent events ဖြင့် ပြုလုပ်နိုင်ပြီး ချက်ချင်းဖြစ်ဟန်ရှိသော်လည်း ရွေ့လျားသော အစိတ်အပိုင်းများ ပိုများသည်။ ချက်ချင်း update မလိုအပ်သရွေ့ polling ဖြင့် စတင်ပါ။

အီးမေးလ် အသိပေးချက်များ

အီးမေးလ်သည် ပို့ပေးသော provider နှင့် အတည်ပြုပြီးသား domain လိုအပ်ပြီး အသေးစိတ်ကို အက်ပ်မှ အီးမေးလ် ပို့နည်း တွင် ရှိသည်။ အသိပေးချက်အတွက်:

• server ဘက်မှ ပို့ပါ၊ provider key ကို browser တွင် ဘယ်တော့မှ မထားပါနှင့်။
• အဖြစ်အပျက် များများကို စုပါ။ "comment အသစ် ၃ ခု" ကို email တစ်စောင်တည်းဖြင့် ပို့ခြင်းက သုံးစောင် ပို့ခြင်းထက် ကောင်းသည်။
• အရေးနည်းသော လှုပ်ရှားမှုများအတွက် နေ့စဉ် သို့မဟုတ် အပတ်စဉ် digest ကို ပေးပါ။
• မလိုအပ်သော အီးမေးလ်များတွင် unsubscribe သို့မဟုတ် preferences link ထည့်ပါ။ ကြော်ငြာအီးမေးလ် စည်းမျဉ်းများသည် နိုင်ငံအလိုက် ကွဲပြားသည်၊ သင်နှင့် သက်ဆိုင်သည်ကို စစ်ဆေးပါ။

Web push အသိပေးချက်များ

Web push ဖြင့် သင့်ဆိုက်သည် အက်ပ်အသိပေးချက်ကဲ့သို့ ပေါ်လာသော သတိပေးချက်များ ပို့နိုင်သည်။ MDN ၏ Push API စာတမ်းအရ ၎င်းသည် အောက်ပါအတိုင်း အလုပ်လုပ်သည်:

1. သင့်ဆိုက်က service worker ကို မှတ်ပုံတင်သည်၊ browser က နောက်ကွယ်တွင် run နိုင်သော script ဖြစ်သည်။
2. အသုံးပြုသူ သဘောတူပြီးနောက် service worker က PushManager.subscribe() ဖြင့် subscribe လုပ်သည်။ browser က endpoint နှင့် encryption key များပါသော subscription ကို ပြန်ပေးသည်။
3. သင့် server က ထို subscription ကို သိမ်းပြီး တစ်ခုခု ဖြစ်သောအခါ endpoint သို့ message ပို့သည်၊ များသောအားဖြင့် VAPID key များ (သင့် server ကို ခွဲခြားသော key pair) ဖြင့် လက်မှတ်ထိုးထားသည်။
4. browser က သင့် service worker ကို စတင်ပြီး notification ကို ပြသည်၊ သင့်စာမျက်နှာ ဖွင့်မထားသည့်အချိန်ပင်ဖြစ်စေ။

MDN က endpoint ကို လျှို့ဝှက်ထားရမည်ဟု ထပ်ဖော်ထားသည်၊ အဘယ်ကြောင့်ဆိုသော် ထို endpoint ကို သိရုံဖြင့် ထိုအသုံးပြုသူထံ message ပို့နိုင်သောကြောင့်ဖြစ်သည်။

iPhone နှင့် iPad

WebKit က iOS နှင့် iPadOS 16.4 တွင် web အက်ပ်များအတွက် Web Push ကို ထည့်ခဲ့ပြီး ၎င်း၏ ကြေညာချက်တွင် အခြေအနေနှစ်ခု ပါရှိသည်: ဆိုက်ကို Home Screen သို့ ထည့်ထားရမည်၊ နှင့် ခွင့်ပြုချက်ကို အသုံးပြုသူ လုပ်ဆောင်ချက်တစ်ခုအတွက် တုံ့ပြန်၍ တောင်းဆိုရမည် (ဥပမာ Subscribe ခလုတ်ကို နှိပ်ခြင်း)။ ထို့ကြောင့် iPhone တွင် push သည် သင့် web အက်ပ်ကို တပ်ဆင်ထားသော အသုံးပြုသူများထံသာ ရောက်သည်။ web အက်ပ် တပ်ဆင်ခြင်း၏ အဓိပ္ပာယ်ကို native နှင့် progressive web app တွင် ကြည့်ပါ။

ခွင့်ပြုချက် ကောင်းကောင်း တောင်းနည်း

ပထမဆုံး ဝင်ရောက်သည့်အခါ မမေးပါနှင့်။ အကျိုးကျေးဇူးကို အရင်ရှင်းပြပါ ("သင့်အတန်းမစမီ တစ်နာရီအလိုတွင် သတိပေးချက် ရယူပါ")၊ ထို့နောက် အသုံးပြုသူ ခလုတ်တစ်ခုကို နှိပ်သောအခါမှ browser prompt ကို ပြပါ။ တစ်စုံတစ်ဦးက ငြင်းလိုက်လျှင် browser က နောက်တစ်ကြိမ် မမေးခွင့်ပေးနိုင်သောကြောင့် စောစောစီးစီး မေးခြင်းက သူတို့ကို အမြဲတမ်း ဆုံးရှုံးစေနိုင်သည်။

အချိန်ဇယားဖြင့် အသိပေးချက်များ လိုအပ်သည့် trigger

"ရက် ၂၄ နာရီ မတိုင်မီ သတိပေးချက်" သို့မဟုတ် "တနင်္လာ နေ့တိုင်း အပတ်စဉ် အနှစ်ချုပ်" တို့သည် အချိန်ဇယားဖြင့် run ရန် တစ်ခုခု လိုအပ်သည်။ ၎င်းသည် နောက်ကွယ် job ပြဿနာဖြစ်ပြီး background job များ run နည်း တွင် ဖော်ပြထားသည်။ အသုံးများသော ပုံစံတစ်ခုမှာ ပြင်ပ scheduler တစ်ခုက ခိုင်မာသော endpoint ကို မိနစ်အနည်းငယ်တိုင်း ခေါ်ပြီး ၎င်းက ပို့ရမည့်အရာကို ပို့ခြင်း ဖြစ်သည်။

AI builder သို့ ပေးရမည့် prompt များ

အက်ပ်အတွင်းဖြင့် စတင်ပါ:

In-app notification များ ထည့်ပါ။ notifications table (user, type, title, body, link, created_at, read_at) ဖန်တီးပါ။ feature တိုင်းက ခေါ်သော server function notify(userId, type, data) ထည့်ပါ။ header တွင် မဖတ်ရသေးသော အရေအတွက်ပါသော bell icon၊ နောက်ဆုံး ၂၀ ခု dropdown နှင့် "အားလုံးကို ဖတ်ပြီးအဖြစ် မှတ်" ခလုတ် ပြပါ။ အသစ်များကို ၆၀ စက္ကန့်တိုင်း poll လုပ်ပါ။

ထို့နောက် ဦးစားပေးမှုများနှင့် အီးမေးလ်:

အသိပေးချက် settings ထည့်ပါ: အမျိုးအစားတစ်ခုစီ (comment reply၊ mention၊ billing) အတွက် အသုံးပြုသူက in-app၊ email၊ နှစ်ခုလုံး သို့မဟုတ် မည်သည်မှ မရွေးချယ်နိုင်စေပါ။ notify() က ဤအရာများကို လေးစားရမည်။ [PROVIDER] ဖြင့် အီးမေးလ် ပို့ပါ၊ server ပေါ်တွင်သာ secret [ENV_NAME] ကို သုံးပါ။ comment အီးမေးလ်များကို စုပါ၊ အသုံးပြုသူတစ်ဦးအတွက် ၁၅ မိနစ်လျှင် အီးမေးလ် တစ်စောင်ထက် မပို့ရ။

ထို့နောက် push လိုလျှင်:

optional web push ထည့်ပါ။ service worker မှတ်ပုံတင်ပါ၊ VAPID key များ ထုတ်ပြီး private key ကို secret အဖြစ် သိမ်းပါ။ settings တွင် "Enable notifications" ခလုတ်ထည့်ပါ၊ ခလုတ်ကို နှိပ်သောအခါမှသာ ခွင့်ပြုချက် တောင်းပါ။ subscription တစ်ခုစီကို အသုံးပြုသူနှင့် စက်အလိုက် သိမ်းပါ၊ အသုံးပြုသူ opt-in လုပ်ထားသည့်အခါ notify() မှ push ပို့ပါ၊ push service က သက်တမ်းကုန်ကြောင်း အစီရင်ခံသော subscription များကို ဖျက်ပါ။

အများဆုံးဖြစ်သော အမှားများ

• အသိပေးချက်များ ကုဒ်တစ်ခွင် ပြန့်နေခြင်း။ feature တိုင်းက အီးမေးလ်ကို သီးခြားပုံစံဖြင့် ပို့ပြီး ဦးစားပေးမှုများ လျစ်လျူရှုခံရသည်။ notify() function တစ်ခုတည်း သုံးပါ။
• စာမျက်နှာ load ချိန်တွင် push ခွင့်ပြုချက် တောင်းခြင်း။ လူအများစုက ငြင်းသည်၊ နောက်တစ်ကြိမ် အခွင့်အရေး မရနိုင်ပါ။
• ဦးစားပေးမှု မရှိခြင်း။ ပွစိပွစိ သတိပေးချက်များကို ပိတ်ခွင့်မရှိသော အသုံးပြုသူများက အားလုံးကို ပိတ်ကြသည် သို့မဟုတ် ထွက်သွားသည်။
• browser မှ ပို့ခြင်း။ အီးမေးလ်နှင့် push key များသည် server တွင်သာ ရှိရမည်။
• သေဆုံးပြီးသော push subscription များကို မရှင်းခြင်း။ သက်တမ်းကုန်သော subscription များ စုပုံပြီး ပို့ခြင်းကို အလဟဿ ဖြစ်စေသည်။
• အသိပေးချက် စာသားတွင် အရေးကြီးသော အသေးစိတ်များ။ lock screen တွင် ပေါ်သည်။ "message အသစ် ရှိသည်" ဟူသော စာသားသည် message ကိုယ်တိုင်ထက် ပို ဘေးကင်းသည်။
• ပို့ပြီးသောအရာ မှတ်တမ်း မရှိခြင်း။ အသုံးပြုသူက "အီးမေးလ် မရောက်ခဲ့" ဟု ပြောလျှင် provider message ID ပါသော မှတ်တမ်းများက ဘာကြောင့်ဖြစ်သည်ကို ရှာဖွေနိုင်စေသည်။

စစ်ဆေးစာရင်း

• notify() server function တစ်ခုတည်းကို နေရာတိုင်းတွင် သုံးထား
• ဖတ်ပြီးအခြေအနေပါသော notifications table နှင့် မဖတ်ရသေးသော အရေအတွက်ပါသော bell
• အမျိုးအစားလိုက် ချန်နယ် ဦးစားပေးမှုများ၊ notify() က လေးစားသည်
• server မှ အီးမေးလ် ပို့သည်၊ domain အတည်ပြုပြီး; အသံအုပ်စု ဖြစ်သော အဖြစ်အပျက်များအတွက် digest သို့မဟုတ် grouping
• push ခွင့်ပြုချက်ကို အသုံးပြုသူ လုပ်ဆောင်ချက်နောက်မှသာ ရှင်းလင်းချက်ဖြင့် တောင်းသည်
• push ကို desktop နှင့် Home Screen တွင် အက်ပ်ထည့်ထားသော iPhone တွင် စမ်းသပ်ထား
• သက်တမ်းကုန်သော push subscription များကို ဖယ်ရှားထား
• push သို့မဟုတ် အီးမေးလ် preview တွင် အရေးကြီးသော အကြောင်းအရာ မပါ
• အချိန်ဇယား သတိပေးချက်များတွင် ယုံကြည်ရသော trigger ရှိ

Mythex ရှိ အသိပေးချက်များ

Mythex က သင်တည်ဆောက်သော အက်ပ်များအတွက် built-in အီးမေးလ် သို့မဟုတ် push ဝန်ဆောင်မှု မပါဝင်ပါ၊ ထို့ကြောင့် သင့်ကိုယ်ပိုင် အီးမေးလ် provider ကို ယူဆောင်ပြီး ကိုယ်ပိုင် push key များကို ထုတ်ယူကာ project secret အဖြစ် သိမ်းပါ။ အက်ပ်အတွင်း အပိုင်းအတွက် သင်တောင်းဆိုသောအခါ Mythex ထည့်ပေးသော project ဒေတာဘေ့စ်သာ လိုအပ်သည်။ အထက်ပါလို prompt များဖြင့် တည်ဆောက်ပြီး bell နှင့် အီးမေးလ်များကို Preview တွင် စမ်းသပ်ပါ၊ push ကို သင်ထုတ်ပြန်ထားသော URL တွင် စမ်းသပ်ပါ၊ service worker နှင့် push သည် အမှန်တကယ် HTTPS လိပ်စာ လိုအပ်သောကြောင့်ဖြစ်သည်။ docs recipe အက်ပ်မှ အီးမေးလ် ပို့ခြင်း တွင် starter prompt ရှိသည်။ Mythex က အချိန်ဇယား job များကို စာတမ်းမတင်ထားသောကြောင့် အချိန်သတ်မှတ်သော သတိပေးချက်များကို background job များ run နည်း တွင် ဖော်ပြထားသည့်အတိုင်း ပြင်ပ trigger ဖြင့် စီစဉ်ပါ။

မေးခွန်းများ