तुमच्या अ‍ॅपमध्ये सूचना कशा जोडाव्यात: इन-अ‍ॅप, ईमेल आणि पुश

वेब अ‍ॅपमध्ये सूचना जोडण्यासाठी, इन-अ‍ॅप सूचनांपासून सुरुवात करा: न वाचलेले आयटम दाखवणारा बेल आयकॉन आणि सूचनांचा टेबल तुमच्या डेटाबेसमध्ये. वापरकर्ते दूर असताना त्यांना कळायला हव्या अशा गोष्टींसाठी एक email प्रदाता वापरून ईमेल जोडा, आणि वेळेवर अलर्ट महत्त्वाचे असतील तेव्हाच web push जोडा, कारण त्यासाठी service worker, वापरकर्त्याची परवानगी आणि iPhone वर अ‍ॅप Home Screen वर सेव्ह असणे आवश्यक आहे. तुम्ही कोणतेही चॅनेल वापरा, सर्व सूचना एकाच ठिकाणी सर्व्हरवर तयार करा आणि वापरकर्त्यांना काय मिळावे ते निवडू द्या.

हे मार्गदर्शक चॅनेलची तुलना करते, एक साधी आर्किटेक्चर दाखवते आणि AI अ‍ॅप बिल्डरसह वापरता येतील असे प्रॉम्प्ट्स देते.

मुख्य चॅनेलची तुलना

बहुतेक अ‍ॅप्सना इन-अ‍ॅप आणि ईमेल दोन्ही हवे असतात. पुश आणि SMS तेव्हाच फायदेशीर असतात जेव्हा वेळ खरोखर महत्त्वाची असते, जसे बुकिंगची आठवण किंवा तयार झालेली ऑर्डर.

सूचना प्रणाली कशी जुळते

सोपी आणि मध्यवर्ती ठेवा:

1. काहीतरी घडते. कमेंट पोस्ट होते, पेमेंट अयशस्वी होते, बुकिंग उद्या असते.
2. तुमचा सर्व्हर एक फंक्शन कॉल करतो, जसे notify(user, type, data).
3. ते फंक्शन वापरकर्त्याच्या पसंती तपासते आणि notifications टेबलमध्ये एक रो लिहिते (बेलसाठी).
4. मग ते इतर चॅनेलवर पाठवते जे वापरकर्त्याने त्या प्रकारासाठी सुरू केले आहेत: तुमच्या प्रदात्यामार्फत ईमेल, Push API द्वारे पुश.
5. फ्रंटएंड न वाचलेल्या सूचना दाखवतो आणि उघडल्यावर त्या वाचलेल्या म्हणून चिन्हांकित करतो.

एकच प्रवेश बिंदू असल्यास तुम्ही चॅनेल जोडू शकता, मजकूर बदलू शकता किंवा पसंतींचा आदर करू शकता, कोडबेसमध्ये शोधाशोध न करता.

काय साठवायचे

सूचना टेबलला सहसा हवे असते: user ID, प्रकार (उदाहरणार्थ comment_reply), एक छोटे शीर्षक आणि मजकूर, संबंधित पानाची लिंक, तयार झाल्याची वेळ आणि वाचल्याची वेळ. वेगळे पसंती टेबल प्रत्येक वापरकर्त्याने प्रत्येक प्रकारासाठी कोणते चॅनेल हवे ते साठवते.

नव्या सूचना दाखवणे

• पान पाहताना लोड करा आणि दर 30–60 सेकंदांनी poll करा. सोपे आणि विश्वसनीय.
• रिअल-टाइम अपडेट्स WebSockets किंवा server-sent events सह त्वरित वाटतात, पण अधिक हलणारे भाग जोडतात. तात्काळ अपडेट्स महत्त्वाचे नसतील तर polling ने सुरुवात करा.

ईमेल सूचना

ईमेलला पाठवणारा प्रदाता आणि सत्यापित डोमेन लागते; तपशील तुमच्या अ‍ॅपमधून ईमेल कसे पाठवावे मध्ये आहेत. सूचनांसाठी विशेषतः:

• सर्व्हरवरून पाठवा, ब्राउझरमध्ये कधीही प्रदात्याची key ठेवू नका.
• गर्दी करणाऱ्या घटनांना बॅच करा. "3 new comments" असा एकच ईमेल तीन ईमेलपेक्षा चांगला.
• कमी-प्राधान्याच्या हालचालींसाठी दैनिक किंवा साप्ताहिक डायजेस्ट द्या.
• अत्यावश्यक नसलेल्या ईमेलमध्ये अनसबस्क्राइब किंवा प्राधान्य लिंक ठेवा. मार्केटिंग ईमेलचे नियम देशानुसार वेगळे असतात; तुम्हाला काय लागू होते ते तपासा.

वेब पुश सूचना

वेब पुश तुमच्या साइटला अ‍ॅप सूचनांसारखे दिसणारे अलर्ट पाठवू देते. MDN च्या Push API दस्तऐवजानुसार, ते असे काम करते:

1. तुमची साइट service worker नोंदवते, ही एक स्क्रिप्ट जी ब्राउझर पार्श्वभूमीत चालवू शकतो.
2. वापरकर्त्याने सहमती दिल्यावर, service worker PushManager.subscribe() द्वारे सबस्क्राइब करतो. ब्राउझर एंडपॉइंट आणि एन्क्रिप्शन keys असलेले सबस्क्रिप्शन परत देतो.
3. तुमचा सर्व्हर ते सबस्क्रिप्शन साठवतो आणि जेव्हा काही घडते तेव्हा एंडपॉइंटला संदेश पाठवतो, सहसा VAPID keys (तुमच्या सर्व्हरची ओळख पटवणारी key जोडी) ने सही केलेला.
4. ब्राउझर तुमचा service worker सुरू करतो, जो सूचना दाखवतो, तुमचे पान उघडे नसले तरीही.

MDN असेही नमूद करते की एंडपॉइंट गुप्त ठेवला पाहिजे, कारण तो माहीत असणे त्या वापरकर्त्याला संदेश पाठवण्यासाठी पुरेसे आहे.

iPhone आणि iPad

WebKit ने iOS आणि iPadOS 16.4 मध्ये वेब अ‍ॅप्ससाठी Web Push जोडले, त्यांच्या घोषणेतील दोन अटींसह: साइट Home Screen वर जोडलेली असली पाहिजे, आणि परवानगी वापरकर्त्याच्या कृतीला प्रतिसाद म्हणून मागितली पाहिजे, जसे Subscribe बटणावर टॅप करणे. त्यामुळे iPhone वर, पुश फक्त ज्या वापरकर्त्यांनी तुमचे वेब अ‍ॅप इन्स्टॉल केले आहे त्यांच्यापर्यंत पोहोचते. वेब अ‍ॅप इन्स्टॉल करणे म्हणजे काय ते native vs progressive web apps मध्ये पहा.

परवानगी चांगल्या पद्धतीने मागणे

पहिल्या भेटीत परवानगी मागू नका. आधी फायदा समजावून सांगा ("तुमच्या वर्गाच्या एक तास आधी आठवण मिळवा"), आणि वापरकर्त्याने बटण टॅप केल्यावर ब्राउझरचा प्रॉम्प्ट दाखवा. कोणी नकार दिला तर ब्राउझर तुम्हाला पुन्हा विचारू देऊ शकत नाही, त्यामुळे अकाली प्रॉम्प्ट त्यांना कायमचे गमावू शकतो.

वेळापत्रकानुसार सूचनांना ट्रिगर लागतो

"वेळेच्या 24 तास आधी आठवण" किंवा "दर सोमवारी साप्ताहिक सारांश" यांना वेळापत्रकानुसार चालणारे काहीतरी लागते. ती बॅकग्राउंड-जॉब समस्या आहे, जी बॅकग्राउंड जॉब्स कसे चालवावेत मध्ये आहे. एक सामान्य पद्धत: एक बाह्य शेड्यूलर दर काही मिनिटांनी संरक्षित एंडपॉइंटला कॉल करतो, आणि तो एंडपॉइंट जे देय आहे ते पाठवतो.

तुमच्या AI बिल्डरला दिलेले प्रॉम्प्ट्स

इन-अ‍ॅपपासून सुरुवात करा:

इन-अ‍ॅप सूचना जोडा. notifications टेबल तयार करा (user, type, title, body, link, created_at, read_at). notify(userId, type, data) हे सर्व्हर फंक्शन जोडा जे प्रत्येक फीचर कॉल करते. हेडरमध्ये न वाचलेल्या संख्येसह बेल आयकॉन, नवीनतम 20 ची ड्रॉपडाउन यादी, आणि "सर्व वाचलेले म्हणून चिन्हांकित करा" बटण दाखवा. दर 60 सेकंदांनी नवीन सूचनांसाठी poll करा.

नंतर पसंती आणि ईमेल:

सूचना सेटिंग्ज जोडा: प्रत्येक प्रकारासाठी (कमेंट रिप्लाय, उल्लेख, बिलिंग) वापरकर्ता in-app, email, दोन्ही किंवा काहीच निवडू शकेल. notify() ने या पसंतींचा आदर केला पाहिजे. [PROVIDER] द्वारे ईमेल पाठवा, फक्त सर्व्हरवर [ENV_NAME] या secret द्वारे. कमेंट ईमेल्स गटबद्ध करा, जेणेकरून एका वापरकर्त्याला 15 मिनिटांत जास्तीत जास्त एक ईमेल जाईल.

मग पुश, जर गरज असेल तर:

पर्यायी web push जोडा. service worker नोंदवा, VAPID keys तयार करा आणि private key secret म्हणून साठवा. सेटिंग्जमध्ये "Enable notifications" बटण जोडा जे फक्त क्लिक झाल्यावर परवानगी मागेल. प्रत्येक सबस्क्रिप्शन प्रति वापरकर्ता आणि डिव्हाइसनुसार साठवा, वापरकर्त्याने opt in केले असल्यास notify() मधून पुश पाठवा, आणि पुश सेवेने कालबाह्य म्हणून नोंदवलेली सबस्क्रिप्शन्स हटवा.

सामान्य चुका

• कोडभर विखुरलेल्या सूचना. प्रत्येक फीचर स्वतःचा ईमेल वेगळ्या पद्धतीने पाठवते, आणि पसंतींकडे दुर्लक्ष होते. एकच notify() फंक्शन वापरा.
• पेज लोडवर पुश परवानगी मागणे. बहुतेक लोक नकार देतात, आणि तुम्हाला दुसरी संधी मिळत नाही.
• पसंती नसणे. जे वापरकर्ते त्रासदायक अलर्ट बंद करू शकत नाहीत, ते सर्व बंद करतात किंवा निघून जातात.
• ब्राउझरमधून पाठवणे. ईमेल आणि पुश keys सर्व्हरवर असायला हव्यात.
• मृत पुश सबस्क्रिप्शन्स साफ न करणे. कालबाह्य सबस्क्रिप्शन्स साचतात आणि पाठवणे वाया जाते.
• सूचनेच्या मजकुरात संवेदनशील तपशील. लॉक स्क्रीनवर तो दिसतो. "तुमला नवीन संदेश आहे" हे संदेशापेक्षा सुरक्षित आहे.
• काय पाठवले गेले याची नोंद नसणे. जेव्हा वापरकर्ता म्हणतो "मला ईमेल मिळाला नाही", तेव्हा प्रदात्याच्या संदेश IDs असलेले लॉग कारण शोधायला मदत करतात.

चेकलिस्ट

• सर्वत्र वापरले जाणारे एकच सर्व्हर-साइड notify() फंक्शन
• वाचन स्थिती असलेला notifications टेबल, आणि न वाचलेल्या संख्येसह बेल
• प्रति-प्रकार चॅनेल पसंती, notify() द्वारे पाळल्या जातात
• सत्यापित डोमेनसह सर्व्हरवरून पाठवलेला ईमेल; गर्दी करणाऱ्या घटनांसाठी डायजेस्ट किंवा गटबद्धता
• स्पष्टीकरणासह, फक्त वापरकर्त्याच्या कृतीनंतर पुश परवानगी मागितली
• डेस्कटॉपवर आणि Home Screen वर अ‍ॅप जोडलेल्या iPhone वर पुश तपासला
• कालबाह्य पुश सबस्क्रिप्शन्स काढली
• पुश किंवा ईमेल पूर्वावलोकनात संवेदनशील मजकूर नाही
• वेळापत्रकानुसार आठवणींना विश्वसनीय ट्रिगर आहे

Mythex वर सूचना

Mythex तुम्ही बनवलेल्या अ‍ॅप्ससाठी अंगभूत ईमेल किंवा पुश सेवा देत नाही, त्यामुळे तुम्ही स्वतःचा ईमेल प्रदाता आणतो आणि स्वतःच्या पुश keys तयार करता, ज्या प्रोजेक्ट secrets म्हणून साठवल्या जातात. इन-अ‍ॅप भागासाठी फक्त प्रोजेक्टचा डेटाबेस लागतो, जो तुम्ही मागितल्यावर Mythex जोडते. वरील प्रॉम्प्ट्ससारखे प्रॉम्प्ट्स वापरून बनवा, Preview मध्ये बेल आणि ईमेल तपासा, आणि पुश तुमच्या प्रकाशित URL वर तपासा, कारण service workers आणि पुशला खरा HTTPS पत्ता लागतो. Send email from your app या docs रेसिपीमध्ये सुरुवातीचा प्रॉम्प्ट आहे. Mythex वेळापत्रकानुसार जॉब्स दस्तऐवजीकृत करत नाही, त्यामुळे वेळेवरच्या आठवणींचे नियोजन बॅकग्राउंड जॉब्स कसे चालवावेत मध्ये वर्णन केल्याप्रमाणे बाह्य ट्रिगरने करा.

प्रश्न