जब मेल डिलीवर होता है: iOS में पुश नोटिफिकेशन का नुकसान

उपयोगकर्ता की ओर से, ईमेल क्लाइंट एक साधारण अनुप्रयोग है। Yandex.Mail डेवलपर्स ने यह भी मजाक किया कि आवेदन में केवल तीन स्क्रीन हैं: पत्रों की एक सूची; पत्र भेजना; स्क्रीन के बारे में।

लेकिन हुड के तहत बहुत सारी दिलचस्प चीजें हो रही हैं। कई मोबाइल ऐप की तरह, मेल उपयोगकर्ताओं के साथ बातचीत करने के लिए पुश नोटिफिकेशन का उपयोग करता है। कई आईओएस अनुप्रयोगों की तरह, ऐप्पल पुश अधिसूचना सेवा की प्रकृति के कारण मेल कुछ सूचनाएं खो देता है।

यैंडेक्स.मैल आईओएस समूह के प्रमुख असिया स्विरिडेंको साबित करेंगे कि सिस्टम की सीमाओं के साथ भी, पुश नोटिफिकेशन का नुकसान हो सकता है और अगर वे आपके आवेदन के लिए महत्वपूर्ण हैं तो लड़ना चाहिए। यह मेल के लिए सही है, क्योंकि नए अक्षरों की पुश सूचनाएँ वही होती हैं, जिसके लिए उपयोगकर्ता एप्लिकेशन इंस्टॉल करता है। यदि, आपके आवेदन के लिए, पुश सूचनाओं का वितरण इतना महत्वपूर्ण नहीं है, तो यह पता लगाना दिलचस्प है कि मोबाइल यांडेक्स कौन-सी बाइक है।


यह रिमोट नोटिफिकेशन के बारे में है, जो कि APNs (Apple Push Notification Service) के माध्यम से सर्वर से आने वाली सूचनाएं हैं। हम स्थानीय सूचनाओं पर बात नहीं करेंगे और इस बारे में बात करेंगे:

• पुश सूचनाओं के साथ काम करने के लिए एपीआई कैसा दिखता है। एक धक्का अधिसूचना वितरण योजना पर विचार करें और इस योजना में कहां नुकसान हो सकता है।
• आपने Yandex.Mail में नुकसान से निपटने का फैसला कैसे किया - पुश सूचनाओं की कतार।
• कैसे लॉग इन करें और क्या अन्य कठिनाइयों को पूरा कर सकते हैं।

हमारे पास क्या है और हम कहां खोते हैं

अब धक्का सूचनाओं के साथ काम करने के लिए एपीआई एक शक्तिशाली पर्याप्त चीज है जो आपको कई दिलचस्प चीजें करने की अनुमति देता है। लेकिन हमेशा ऐसा नहीं था।



पहले, पुश सूचनाएं बिल्कुल इस तरह दिखती थीं - यह एक दुर्भाग्यपूर्ण ब्लू डैशबोर्ड था जो स्क्रीन पर पॉप अप होता था, वर्तमान एप्लिकेशन के साथ काम करना अवरुद्ध करता था, कुछ भी करने की अनुमति नहीं देता था, और फिर हमेशा के लिए गायब हो गया, और इसके बारे में कोई और अनुस्मारक नहीं थे।

तब से अब तक काफी समय बीत चुका है।



हमारे लिए, डेवलपर्स के रूप में, यह सब iOS 3 में शुरू हुआ , जब तीसरे पक्ष के पुस्तकालयों के लिए पुश सूचनाएं उपलब्ध हो गईं।

नोटिफिकेशन सेंटर iOS 5 में दिखाई दिया , और पुश नोटिफिकेशन कहीं नहीं जाना बंद हो गया, अब वे Notification Center में बने हुए हैं, जहाँ उन्हें फिर से देखा जा सकता है।

IOS 6 ने Do Not Disturb की शुरुआत की । उपयोगकर्ता के पास समय की अवधि निर्धारित करने का अवसर है जिसके दौरान वह सूचनाएं प्राप्त नहीं करना चाहता है।

ये बदलाव मुख्य रूप से चिंतित हैं कि उपयोगकर्ता पुश सूचनाओं के साथ कैसे काम कर सकते हैं, कैसे वे अपने जीवन को अधिक आरामदायक बना सकते हैं, न कि यह कि कैसे डेवलपर्स सूचनाओं को प्रभावित कर सकते हैं।

डेवलपर्स के लिए, एक महत्वपूर्ण मील का पत्थर iOS 8 और नोटिफिकेशन एक्शन का उद्भव था , जिसने पुश सूचनाओं द्वारा एक विशिष्ट एप्लिकेशन के लिए विशिष्ट कार्य करने की अनुमति दी।

IOS 10 अधिसूचना सेवा विस्तार और अधिसूचना सामग्री विस्तार का परिचय देता है । पहले आपको उपयोगकर्ता को दिखाए जाने से पहले पुश अधिसूचना को संशोधित करने की अनुमति देता है। दूसरा है पुश नोटिफिकेशन पर पुश नोटिफिकेशन द्वारा कुछ यूआई दिखाना, जिसमें, उदाहरण के लिए, आप अधिक विस्तृत जानकारी प्रदर्शित कर सकते हैं। IOS 10 में, यह UI गैर-क्लिक करने योग्य था - आप देख सकते हैं, आप इसे स्पर्श नहीं कर सकते।

IOS 11 ने नोटिफिकेशन प्राइवेसी सेटिंग्स की शुरुआत की । अब उपयोगकर्ता सेटिंग्स में जा सकता है और संकेत कर सकता है कि वह चाहता है कि आने वाली सूचनाओं की सामग्री प्रदर्शित हो। यह सुरक्षा की दिशा में बहुत बड़ा कदम है। यह समझने के लिए आईओएस के केवल 8 संस्करणों को लिया गया था कि सभी उपयोगकर्ता नहीं चाहते कि व्यक्तिगत जानकारी अचानक टेबल पर पड़े आईफोन पर पॉप अप हो।

IOS 12 में, थ्रेड-आइडी द्वारा पुश नोटिफिकेशन को ग्रुप करना संभव हो गया और नोटिफिकेशन कंटेंट एक्सटेंशन का उपयोग करके हमने iOS 10 में जो UI प्राप्त किया वह क्लिक करने योग्य हो गया है। अब आप वहां बटन और जेस्चर कंट्रोल जोड़ सकते हैं - वह सब जो उपयोगकर्ता को UI के साथ इंटरैक्ट करने में मदद करता है।

आज पुश सूचनाएँ

जैसा कि आप देख सकते हैं, पुश नोटिफिकेशन एक लंबा सफर तय कर चुके हैं, और आज उनकी मदद से आप वास्तव में बहुत कुछ कर सकते हैं।

पाठ संदेश और स्थानीयकरण

पहले की तरह, हम एक धक्का सूचना में पाठ संदेश भेज सकते हैं, लेकिन अब आप इसके अतिरिक्त स्थानीयकरण के लिए कुंजी निर्दिष्ट कर सकते हैं।

"aps" : { "alert" : { "title" : "New Mail", "subtitle-loc-key" : "alert_subtitle_localization_key", "loc-key" : "alert_body_localization_key", } } 

यदि आप पेलोड अधिसूचना में subtitle-loc-key और loc-key निर्दिष्ट करते हैं, तो जब डिवाइस पर पुश नोटिफिकेशन आता है, तो आवश्यक मान एप्लिकेशन के लोकलवाइजिंग.स्ट्रिंग फ़ाइल में मिलेगा और उपयोगकर्ता को एक स्थानीय संदेश दिखाई देगा।

ध्वनि और महत्वपूर्ण चेतावनी

पहले की तरह, आप पेलोड नोटिफिकेशन में ध्वनियाँ जोड़ सकते हैं।

 "aps" : { "sound" : { "critical" : 1, "name" : "bingbong.aiff", "volume" : 1.0, } } 

IOS 12 में एक महत्वपूर्ण चेतावनी है। ये वे ध्वनियाँ हैं जो उपयोगकर्ता को डू नॉट डिस्टर्ब मोड में होने पर भी खेली जाएंगी।

आमतौर पर, उपयोगकर्ता की आवश्यकता नहीं होती है, उदाहरण के लिए, रात में एक पत्रिका सदस्यता के साथ एक आवेदन यह रिपोर्ट करने के लिए कि एक नया नंबर जारी किया गया है। इसलिए, ऐप्पल उन अनुप्रयोगों को प्रतिबंधित करता है जो महत्वपूर्ण चेतावनी का उपयोग कर सकते हैं। यदि आपका एप्लिकेशन स्वास्थ्य, सुरक्षा के साथ काम करता है, या आपको लगता है कि महत्वपूर्ण चेतावनी एक ऐसी चीज है जो उपयोगकर्ताओं को आपके एप्लिकेशन के साथ बातचीत करने में मदद कर सकती है, तो Apple को लिखें। शायद वे आपको इस कार्यक्षमता का उपयोग करने की अनुमति देंगे।

मौन सूचनाएँ

उपयोगकर्ता चुप सूचना नहीं देखता है। वे सीधे आवेदन पर आते हैं, इसे जगाते हैं और आपको एप्लिकेशन को अद्यतित करने के लिए कुछ क्रियाएं करने की अनुमति देते हैं: सर्वर को अनुरोध भेजें, पृष्ठभूमि में डेटा का अनुरोध करें, डेटाबेस से डेटा अपडेट करें, यूआई को अपडेट करें ताकि जब उपयोगकर्ता आवेदन में प्रवेश करे, तो वह देखता है अद्यतन डेटा।

 "aps" : { "content-available" : 1 //   alert, sound  badge   payload } 

पुश नोटिफिकेशन को चुप रहने के लिए, आपको पेलोड में निर्दिष्ट करना होगा: "content-available" : 1 । और पेलोड में चेतावनी, ध्वनि और बैज कुंजी निर्दिष्ट न करें - वे पुश सूचनाओं के लिए पूरी तरह से बेकार हैं जो उपयोगकर्ता को नहीं दिखाए जाएंगे।

अधिसूचना समूहन

संदेशों को समूहीकृत करने के लिए, आपको पेलोड में "थ्रेड-आईडी" निर्दिष्ट करना होगा। एक ही एप्लिकेशन के भीतर कई मान हो सकते हैं, यदि आप अलग-अलग तरीकों से समूह बनाना चाहते हैं: खातों द्वारा, प्राप्तकर्ता द्वारा, विषय द्वारा।

 "aps" : { "thread-id" : "any_thread_identifier" } 

यह बहुत सुविधाजनक है, क्योंकि अब पुश नोटिफिकेशन लॉक स्क्रीन पर सभी जगह नहीं लेते हैं, लेकिन एक साथ समूहीकृत होते हैं। यदि आप पहले से ही इस कार्यक्षमता का उपयोग नहीं कर रहे हैं, तो यह शुरू करने का समय है।

इसे दिखाने से पहले अधिसूचना बदलें

प्रदर्शित होने से पहले पुश सूचनाएँ बदली जा सकती हैं। ऐसा करने के लिए, आपको आवेदन के लिए अधिसूचना सामग्री एक्सटेंशन को जोड़ना होगा और didReceive विधि को ओवरराइड करना didReceive । इस पद्धति में, आप अधिसूचना सामग्री प्राप्त कर सकते हैं और इसे संशोधित कर सकते हैं।

 "aps" : { "mutable-content" : 1 } override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { guard let mutableContent = request.content.mutableCopy() as? UNMutableNotificationContent else { contentHandler(request.content); return } mutableContent.subtitle = "Got it!" contentHandler(mutableContent) } 

उदाहरण के लिए, आप अधिसूचना में मीडिया सामग्री के लिए एक लिंक भेज सकते हैं, एक्सटेंशन में सामग्री डाउनलोड कर सकते हैं और डाउनलोड की गई अधिसूचना को संलग्न कर सकते हैं। उसके बाद, एक नए संदर्भ के साथ कॉल पूरा करें, और उपयोगकर्ता को एक विस्तारित पुश अधिसूचना दिखाएं। आप शीर्षक, उपशीर्षक आदि को बदल सकते हैं।

एक और दिलचस्प मामला यह है कि आप एक एन्क्रिप्टेड संदर्भ के साथ एक धक्का अधिसूचना भेज सकते हैं, यदि आप चाहते हैं कि डेटा अतिरिक्त रूप से संरक्षित हो, और Apple ने इसे नहीं देखा। अधिसूचना सामग्री एक्सटेंशन में, आप उन्हें डिक्रिप्ट कर सकते हैं और उपयोगकर्ता को पहले से ही डीक्रिप्ट किए गए डेटा दिखा सकते हैं।

छिपी अधिसूचना सामग्री

IOS 11 में, पुश सूचनाओं की सामग्री को छिपाना संभव हो गया, और हम, डेवलपर्स के रूप में, इसे किसी भी तरह से प्रभावित नहीं कर सकते। यदि उपयोगकर्ता ने "नोटिफिकेशन नोटिफिकेशन कंटेंट" को टिक किया है, तो एक तरीका या दूसरा इसे छिपाया जाएगा। हम जो कुछ भी कर सकते हैं वह UNNotificationCategory के माध्यम से एक प्लेसहोल्डर को निर्दिष्ट करने के लिए है जो सामग्री के बजाय प्रदर्शित होगा (डिफ़ॉल्ट रूप से यह अधिसूचना है), और यह निर्धारित करने के लिए कि शीर्षक या उपशीर्षक दिखाना है या नहीं।

 let commentCategory = UNNotificationCategory(identifier: "comment-category", actions: [], intentIdentifiers: [], hiddenPreviewsBodyPlaceholder: NSString.localizedUserNotificationString(forKey:"COMMENT_KEY",arguments: nil), options: [.hiddenPreviewsShowTitle]) 

एप्लिकेशन लॉन्च किए बिना अधिसूचना चरण

एप्लिकेशन को लॉन्च किए बिना पुश नोटिफिकेशन क्रियाओं को करने के लिए, आपको एक श्रेणी बनाने और उसमें कार्रवाई जोड़ने की आवश्यकता है। श्रेणी पहचानकर्ता को पेलोड अधिसूचना के श्रेणी क्षेत्र में पारित किया जाता है। आप विभिन्न क्रियाओं को विभिन्न प्रकार की सूचनाओं से जोड़ सकते हैं।

 "aps" : { "category" : "message" } let action = UNNotificationAction(identifier:"reply", title:"Reply", options:[]) let category = UNNotificationCategory(identifier: "message", actions: [action], minimalActions: [action], intentIdentifiers: [], options: []) UNUserNotificationCenter.current().setNotificationCategories([category]) 

समृद्ध सूचनाएँ

इस एक्सटेंशन में, आप अतिरिक्त क्रियाओं को संसाधित कर सकते हैं जिन्हें आपने पुश अधिसूचना में जोड़ा है और कस्टम UI प्रदर्शित करते हैं।

ऐसा करने के लिए, आपको एप्लिकेशन में अधिसूचना सामग्री एक्सटेंशन को जोड़ने की आवश्यकता है, इसमें एक वर्ग को परिभाषित करें जो UNNotificationContentExtension से विरासत में मिला है, और फिर एक नियमित UIViewController के साथ इसके साथ काम करें।

 class NotificationViewController: UIViewController, UNNotificationContentExtension { @IBOutlet var userLabel: UILabel? func didReceive(_ notification: UNNotification) { let content = notification.request.content self.title = content.title let userInfo = content.userInfo self.userLabel?.text = userInfo["video-user"] as? String } } 

यदि आप कस्टम क्रियाओं को संसाधित कर रहे हैं, तो यह याद रखना महत्वपूर्ण है कि ये क्रियाएं UI को अपडेट करने के लायक हैं जो आप उपयोगकर्ता को दिखा रहे हैं। इस विस्तार में व्यावसायिक तर्क को लागू करने का प्रयास करने की आवश्यकता नहीं है। मुख्य एप्लिकेशन में एक धक्का अधिसूचना के साथ कार्रवाई द्वारा सर्वर को एक अनुरोध भेजें, और यहां नहीं। यह स्थान केवल UI के लिए है।

पुश अधिसूचना वितरण योजना

देखें कि आप iOS में पुश नोटिफिकेशन के साथ कितना कर सकते हैं। संस्करण से संस्करण तक, हमारे पास अधिक से अधिक नई कार्यक्षमता है, लेकिन पुश अधिसूचना वितरण योजना अब बिल्कुल वैसी ही है जैसी कि आईओएस 3 में थी।



कोई यह सोचेगा कि पुश नोटिफिकेशन डिलीवरी स्कीम शुरू से ठीक थी, लेकिन ऐसा नहीं है।

धक्का सूचना वितरण योजना में तीन मुख्य नोड हैं:

• प्रदाता जो पेलोड धक्का सूचनाएं उत्पन्न करता है;
• एपीएन - ऐप्पल पुश अधिसूचना सेवा, जो एक अधिसूचना वितरित करती है;
• iOS डिवाइस और आपका एप्लिकेशन।

मैं इस भाग को छोड़ दूंगा कि कैसे पंजीकरण करना है, एक टोकन प्राप्त करना है, जहां इसे भेजना है। मान लीजिए हमारे पास यह सब है। आगे क्या होता है?

• प्रदाता एक पेलोड उत्पन्न करता है और इसे APN को भेजता है।
• APN इसे डिवाइस पर भेजता है।
• उपयोगकर्ता अपने डिवाइस पर एक धक्का संदेश देखता है।

मेल और कई अन्य एप्लिकेशन उन्नत धक्का सूचना वितरण योजना का उपयोग करते हैं। अधिसूचना सेवा एक्सटेंशन जोड़ा गया है, जो "mutable-content" : 1 साथ पुश नोटिफिकेशन प्राप्त करता है। प्रदाता को एक सर्वर में विभाजित किया जाता है जो एप्लिकेशन के बैकएंड लॉजिक से संबंधित होता है, और प्रदाता स्वयं, जो पेलोड उत्पन्न करता है और सदस्यता से संबंधित होता है।

यांडेक्स में, प्रदाता जो पेलोड बनाता है उसे XIVA कहा जाता है। XIVA एक सदस्यता डेटाबेस है। मेल तृतीय पक्ष पुस्तकालय के रूप में पुश सूचनाओं के साथ काम करने के लिए XIVA का उपयोग करता है।

मेल में, सदस्यता के साथ काम काफी गैर-तुच्छ रूप से आयोजित किया जाता है। हम केवल सूचनाओं के लिए आवेदन पर हस्ताक्षर नहीं करते हैं, हमारे पास बहु-खाता है। हम अलग-अलग खातों पर हस्ताक्षर कर सकते हैं, या एक खाते के भीतर यह चुन सकते हैं कि उपयोगकर्ता किन फ़ोल्डरों के लिए सूचनाएं प्राप्त करना चाहता है और वे कौन से नहीं चाहते हैं। XIVA इस सब से निपटता है। कुछ अन्य यैंडेक्स सेवाएं भी XIVA के माध्यम से काम करती हैं: अनुप्रयोगों, सूचनाओं, सदस्यता, टोकन के बारे में सभी जानकारी XIVA में संग्रहीत की जाती है।

नुकसान कहां हैं?

धक्का अधिसूचना वितरण योजना में चार तीर हैं, इनमें से तीन संक्रमणों में नुकसान हो सकता है।

सर्वर और XIVA के बीच, निम्नलिखित मामले में नुकसान हो सकता है। उपयोगकर्ता को एक पत्र मिला, सर्वर इसके बारे में जानता है, एक अधिसूचना उत्पन्न करता है और इसे XIVA को भेजता है। लेकिन XIVA इस जानकारी को खो सकता है, उदाहरण के लिए, यदि आवेदन में एक उपयोगकर्ता ने ऑफ़लाइन होने के दौरान एक विशिष्ट फ़ोल्डर में "सदस्यता लें" चुना। तब XIVA फ़ोल्डर में सदस्यता के बारे में जानकारी प्राप्त नहीं करेगा, और जब पेलोड आता है, तो यह बस इसे हटा देगा और उपयोगकर्ता अधिसूचना नहीं देखेगा।

XIVA और APN के बीच , नेटवर्क हानि हो सकती है। हम नेटवर्क को मुश्किल से प्रभावित कर सकते हैं, इसलिए हम इस बिंदु पर ध्यान केन्द्रित नहीं करेंगे।

यदि आप एक्सटेंशन का उपयोग नहीं कर रहे हैं, तो APNs और Extension, या APNS और iOS के बीच । यह सबसे आम प्रकार का नुकसान है। ऐसे नुकसान इसलिए होते हैं क्योंकि APN डिवाइस पर प्रति एप्लिकेशन एक से अधिक पुश स्टोर नहीं करते हैं। यदि, उपयोगकर्ता ऑफ़लाइन है, तो उसे कई सूचनाएं प्राप्त होती हैं, जब वह ऑनलाइन जाता है, तो वह केवल अंतिम संदेश देखेगा।

ये वही नुकसान हैं जो हमें डिलीवरी की गारंटी देने और पुश सूचनाओं पर भरोसा करने की अनुमति नहीं देते हैं। Apple स्पष्ट रूप से लिखता है कि डिलीवरी की गारंटी नहीं है।

एक्सटेंशन एप्लिकेशन और iOS के बीच, नुकसान नहीं हो सकता है , और Apple इसकी गारंटी देता है। यदि आप एक्सटेंशन का उपयोग करते हैं और पूरा करने के तरीके के साथ didReceiveContent को ओवरराइड करते हैं, भले ही आप इस पूर्णता को नहीं कहते हैं, फिर भी अधिसूचना को दिखाया जाएगा। यह याद रखना महत्वपूर्ण है। आप इसे कॉल नहीं कर सकते हैं या इसे कॉल करने का समय नहीं है, लेकिन तब अधिसूचना बिना किसी बदलाव के दिखाई देगी, जिस रूप में यह एपीएन से आता है।

हम देखेंगे कि हम एपीएन और एक्सटेंशन के बीच घाटे से कैसे निपटते हैं। लेकिन अगर आपको पुश नोटिफिकेशन डिलिवरेबिलिटी बढ़ाने की जरूरत है, तो पूरी स्कीम पर ध्यान दें। सेवा प्रदाता की ओर से किसी भी तरह की हानि होने पर जांच लें, यदि आपका प्रदाता एपीएन और इतने पर सामान्य रूप से बातचीत करता है। पूरी श्रृंखला की जांच करें और मापें, और फिर निष्कर्ष निकालें जहां नुकसान सबसे अधिक होता है और इस सर्किट के किस हिस्से को संशोधित किया जाना चाहिए।

पुश सूचना कतार

APNs और एक्सटेंशन के बंडल में नुकसान से निपटने का हमारा तरीका जिसे हमने पुश नोटिफिकेशन कतार कहा है।

यदि आप पूरी कहानी को एक वाक्यांश में संकुचित करते हैं, तो यह होगा:

यदि आप पुश अधिसूचना से चूक गए हैं, तो आप इसे फिर से अनुरोध कर सकते हैं।

हमारी सूचना वितरण योजना में, सभी समान प्रतिभागी हैं: XIVA, APN, एक्सटेंशन। सरलीकृत योजना इस तरह काम करती है:

• XIVA पुश सूचनाओं को संख्या देता है जिसे वह APN को भेजने का इरादा रखता है, और उसके बाद ही जानकारी भेजता है।
• एक्सटेंशन को पुश नोटिफिकेशन नंबर 1 प्राप्त होता है और कुछ समय बाद नंबर 3। यह समझता है कि कुछ डेटा गायब है।
• XIVA के पास अंतिम स्थिति प्राप्त अनुरोध के साथ भेजता है, फैलता है और लापता डेटा को फिर से भेजने के लिए कहता है।
• XIVA पुश नोटिफिकेशन का समर्थन करता है क्योंकि यह पेलोड डेटाबेस और सदस्यता डेटाबेस को संग्रहीत करता है। सभी सदस्यताएं कुछ समय के लिए संग्रहीत की जाती हैं और फिर से अनुरोध किया जा सकता है।
• हम फिर से पूछते हैं, हम एक धक्का अधिसूचना प्राप्त करते हैं, और हमारे पास ग्राहक के सभी संदेश हैं जो ग्राहक को प्राप्त होने चाहिए।

पहला अपेक्षित मुद्दा डुप्लिकेट नोटिफिकेशन है। जब हम XIVA से किसी संदेश का पुन: अनुरोध करते हैं, तो हमें पता नहीं होता कि भेजने के लिए कतार में क्या है, क्योंकि हम इसके साथ सीधे संपर्क नहीं करते हैं, बल्कि APN के माध्यम से करते हैं। मान लीजिए कि हमने देखा कि कुछ सूचनाएं गायब थीं, और XIVA को एक अनुरोध भेजा। XIVA पेलोड APNs के माध्यम से एक मिस्ड नोटिफिकेशन के साथ भेजा गया। लेकिन इससे पहले कि हम इसे प्राप्त करते, हमें एक और पेलोड मिला और एक पास के साथ भी। उन्होंने फिर पूछा - XIVA ने फिर भेजा।

ताकि सूचनाएं डुप्लिकेट न हों, हम एप्स-पतन-आईडी का उपयोग करते हैं। यह सेटिंग iOS की ओर से एक ही आईडी के साथ पुश नोटिफिकेशन को ध्वस्त करने की अनुमति देती है। यदि डिवाइस पर एक ही एप्स-पतन-आईडी के साथ कई पुश नोटिफिकेशन आए हैं, तो iOS उन्हें ध्वस्त कर देगा और उपयोगकर्ता को केवल एक सूचना दिखाई देगी।

Xiva

मैं आपको बताता हूं कि यह सब XIVA पर कैसे काम करता है, क्योंकि यह हमेशा उत्सुक होता है कि बैकएंड पर क्या होता है।

XIVA पुश अधिसूचना कतार से पहले अस्तित्व में था और एक सदस्यता डेटाबेस था। यह महत्वपूर्ण है कि डेटाबेस में सब कुछ उपयोगकर्ताओं द्वारा संग्रहीत किया गया था:

• कुंजी <service, user> ।
• पेलोड को मूल्य के रूप में संग्रहीत किया गया था (मेल के मामले में पत्रों के बारे में डेटा)।

XIVA ने डेटाबेस से डेटा लिया और APN या किसी अन्य सेवा को भेज दिया, क्योंकि यह न केवल iOS के साथ काम करता है। हमने इसका पुन: उपयोग करने का निर्णय लिया।

हम XIVA विकास टीम में आए और वास्तव में एक धक्का अधिसूचना कतार के लिए कहा। सिद्धांत रूप में, XIVA के पास इसके लिए पहले से ही सब कुछ था: डेटाबेस, पेलोड के लिए टीटीएल, यानी, उन्हें तुरंत हटा नहीं दिया जाता है, उन्हें अग्रेषित किया जा सकता है। केवल एक चीज जो गायब थी, वह यह थी कि वर्तमान XIVA कार्यान्वयन के भाग के रूप में पुश अधिसूचना कतार को कॉन्फ़िगर करना संभव था - यह बिना नंबरिंग के है।

पास-थ्रू नंबरिंग के लिए, पुश सूचनाओं को डिवाइस और app_name द्वारा क्रमांकित किया जाना चाहिए। यही है, एंड-टू-एंड नंबरिंग एक विशिष्ट डिवाइस के लिए और एक विशिष्ट एप्लिकेशन के लिए आवश्यक है ताकि क्लाइंट पक्ष पर भरोसा किया जा सके। हमने निम्नानुसार किया: XIVA डेटाबेस का पुन: उपयोग किया, लेकिन एक अलग कुंजी का उपयोग करके इसमें पेलोड लिखना शुरू किया। अब apns_queue एक सेवा के रूप में कार्य करता है, उपयोगकर्ता उपयोगकर्ता device_id + app_name रूप device_id + app_name - बहुत डेटा जिसे क्लाइंट पर नंबरिंग की आवश्यकता होती है, वह है, key: <apns_queue, device_id + app_name> ।

अब XIVA मुख्य डेटाबेस से डेटा लेता है और इसे कतार में डालता है जब इसे भेजने की आवश्यकता होती है। इस बिंदु पर, पेलोड एक नई नंबरिंग प्राप्त करते हैं, क्योंकि अब वे एक ही डेटाबेस में हैं, लेकिन एक अलग कुंजी के साथ। पहले से ही XIVA उन्हें बाहर ले जाता है और उन्हें APN के माध्यम से भेजता है। कुल में, क्लाइंट को आवश्यक पेलोड नंबरिंग प्राप्त होती है।

क्लाइंट अधिसूचना सेवा एक्सटेंशन का उपयोग करता है।

 public override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { // . . . } 

हम इसमें दी गई didReceive विधि को फिर से परिभाषित करते हैं और देखते हैं कि सर्वर से क्या आया। हम "mutable-content" : 1 को सभी पुश नोटिफिकेशन में जोड़ते हैं ताकि वे एक्सटेंशन में पड़ें, क्योंकि अन्यथा हम गणना में उन्हें ध्यान में नहीं रख सकते हैं।

आगे विधि के अंदर कोड में लगातार जांच होती है: क्या आवश्यक पेलोड आया था, क्या वे इसे पार्स कर सकते हैं। यदि पार्स नहीं किया गया है, तो यह संदेश XIVA का नहीं है। यदि संदेश XIVA से नहीं है, तो हम उसके साथ काम करना जारी नहीं रख सकते हैं और केवल APNs से आए नोटिफिकेशन के साथ कॉल पूरा कर सकते हैं, हम कोई गणना नहीं करते हैं।

 guard let payload = try? self.payloadParser.parsePayload(from: request.content.userInfo) else { //  ,     xiva contentHandler(request.content); return } 

हम लॉग करते हैं, जांचें कि क्या डिवाइसआईड बदल गया है, क्योंकि हम जानते हैं कि आईओएस में यह संभव है। ईमानदारी से, हमने डिवाइसआईड में बदलाव का सामना नहीं किया है, लेकिन सिर्फ मामले में हम इसे संसाधित कर रहे हैं, क्योंकि अगर यह बदल जाता है, तो हम XIVA से संख्याओं पर भरोसा नहीं कर पाएंगे।

 self.logger.logNotificationReceived(with: payload) if lastPositionDeviceId != deviceId { // deviceId ,    lastNotificationPosition = nil lastPositionDeviceId = deviceId } 

आगे हम देखते हैं, कि क्या हम इस पेलोड में XIVA डेटा प्राप्त कर सकते हैं, चाहे वे हैं या नहीं। यदि नहीं, तो कंटेंटहैंडलर को फिर से कॉल करें।

 guard let xivaInfo = payload.xivaInfo else { contentHandler(request.content); return } 

यदि डेटा है, तो यह देखने के लिए जांचें कि क्या डिवाइसआईड ने डेटा प्राप्त किया है। XIVA पेलोड को डिवाइस का हैश भेजता है, अगर यह सत्यापित है और मेल खाता है, तो हम जारी रखते हैं, नहीं, हम कंटेंटहैंडलर कहते हैं।

 guard isHashCompatible(deviceId: deviceId, deviceIdHash: xivaInfo.deviceIdHash) else { // payload device_id   device_id  contentHandler(request.content); return } 

अगला ब्लॉक यह देखने के लिए है कि क्या कोई सहेजी गई स्थिति है:

• यदि हमारे पास अंतिम सहेजी गई स्थिति नहीं है, तो हमें या तो अभी तक सूचनाएं प्राप्त नहीं हुई हैं और एक्सटेंशन में प्रवेश नहीं किया है, या किसी कारण से छोड़ दिया गया है। फिर अलग-अलग छूटे हुए को खोजने के लिए धक्का देने की कोई बात नहीं है, और हम फिर से पूरा होने को कहते हैं।
• अगर है, तो आगे बढ़ें।

 guard let lastPos = lastNotificationPosition else { //      lastNotificationPosition = xivaInfo.notificationPosition contentHandler(request.content); return } 

हम मिस्ड सूचनाओं की संख्या की गणना करते हैं। यदि गुम शून्य ठीक है, तो हमने कुछ भी याद नहीं किया है।

 let missedMessages = xivaInfo.notificationPosition - lastPos - 1 guard missedMessages > 0 else { //   push–     contentHandler(request.content); return } 

अन्यथा, हम XIVA से स्थिति डेटा लेते हैं - उसी निरंतर नंबरिंग से। इसके अलावा हम देखते हैं, क्या चूक की मात्रा एक निश्चित सेट मूल्य से अधिक नहीं है।

 lastNotificationPosition = xivaInfo.notificationPosition guard missedMessages <= repeatMaxCount else { //    ,   contentHandler(buildNewNotification()); return } 

इसकी आवश्यकता क्यों है? मान लीजिए कि उपयोगकर्ता लंबे समय से ऑफ़लाइन है, और इस दौरान सौ संदेश जमा हो गए हैं। हम पूरे सौ (यह हमारे लिए आसान है) का अनुरोध करेंगे, XIVA पूरे सौ भेज देगा, और उपयोगकर्ता को सभी सूचनाएं प्राप्त होंगी। यहां तक ​​कि अगर हम उन्हें थ्रेड-आईडी द्वारा समूहित करते हैं (और हम उन्हें समूह देते हैं), सभी एक ही, प्रत्येक अधिसूचना के लिए, यह एक्सटेंशन कहा जाएगा, सभी चेक पास होंगे। ऐसा लगता नहीं है कि उपयोगकर्ता को सभी एक सौ सूचनाओं की आवश्यकता है। इसलिए, हम एक अधिसूचना तैयार करते हैं जिसमें हम लिखते हैं कि आपके पास 100 छूटे हुए संदेश हैं, आवेदन पर जाएं और देखें। और हम उपयोगकर्ता को वास्तव में यह संदेश दिखाते हैं, क्योंकि हम पुश सूचनाओं को बदल सकते हैं।

जब सभी चेक पास हो जाते हैं, तो हम XIVA को एक अनुरोध भेजते हैं: अंतिम स्थिति जो हमारे पास आई, और छूटे हुए संदेशों की संख्या। और देखो:

• यदि XIVA सफलतापूर्वक उत्तर देता है: "सब कुछ ठीक है, तो मैं डेटा भेजूंगा", हम उपयोगकर्ता को वर्तमान अधिसूचना दिखाते हैं और तब तक प्रतीक्षा करते हैं जब तक कि XIVA बाकी सब कुछ नहीं भेजता और उपयोगकर्ता उन सभी संदेशों को देखता है जो छूट गए हैं।
• यदि XIVA एक त्रुटि के साथ उत्तर देता है, तो हम उपयोगकर्ता को एक कस्टम सूचना दिखाते हैं कि उसके पास ऐसे संदेश हैं जो एप्लिकेशन में देखे जा सकते हैं।

 self.requestMissedNotifications(lastPosition: xivaInfo.notificationPosition, gap: missedMessages) { result in result.onValue { _ in self.logger.logNotificationProcessed(with: .success) contentHandler(request.content) }.onError { error in self.logger.logNotificationProcessed(with: .failure(error)) contentHandler(buildNewNotification()) } } 

इस प्रकार, क्लाइंट पर कार्यान्वयन बड़ी संख्या में चेक के लिए नीचे आता है जिसमें हमें पता चलता है कि क्या हम प्राप्त आंकड़ों के साथ काम कर सकते हैं।

लॉगिंग और अन्य कठिनाइयों

जैसा कि आप जानते हैं, यह सुनिश्चित करने के लिए कि दृष्टिकोण अच्छी तरह से काम करता है, आपको लॉग इन करने की आवश्यकता है। हमने सूचनाएं पहुंचाने के लिए एक नई विधि पर आंकड़े एकत्र करना शुरू किया और तुलना की कि कैसे वितरण में बदलाव आया है।

पुश-एक्सटेंशन की सीमाएं

पहली बात जो हमें सामने आई वह है पुश-विस्तार प्रतिबंध।

हमेशा नहीं बुलाया । यदि आप एप्लिकेशन सेटिंग में नोटिफिकेशन ड्रॉइंग को बंद कर देते हैं (नोटिफिकेशन प्राप्त करने की क्षमता चालू रहती है, लेकिन सभी संभावित रेंडरिंग को बंद कर दिया जाता है), एक्सटेंशन को कॉल नहीं किया जाएगा - रिकॉल के साथ सभी लॉजिक और, सबसे महत्वपूर्ण बात, लॉगिंग को नहीं कहा जाएगा। हम यह पता नहीं लगा पाएंगे कि हमारे लिए सबसे महत्वपूर्ण क्या है - क्या उपयोगकर्ता को कोई सूचना मिली है।

पुश-एक्सटेंशन की समय सीमा होती है । Apple प्रलेखन का कहना है कि लगभग 30 सेकंड के भीतर आपको एक संशोधित अधिसूचना के साथ पूरा करने की आवश्यकता है, अन्यथा प्रारंभिक अधिसूचना प्रदर्शित की जाएगी।

मुझे आश्चर्य है कि हमने इसका पता कैसे लगाया। हमने एक विशेषता लागू की जिसे हमने "सुंदर" पुश सूचनाएँ कहा, मीडिया तत्वों को सूचनाओं से जोड़ा, शीर्षक, उपशीर्षक बदल दिया। परीक्षण के दौरान, यह पता चला कि कुछ पुश सूचनाएँ सुंदर बन गईं, जबकि बाकी बदसूरत डकलिंग के रूप में बनी रहीं।

हमने इन पुश सूचनाओं के बीच अंतर को देखना शुरू किया और पाया कि कोई अंतर नहीं था, बस कुछ के लिए हम पूर्णता को कॉल करने में कामयाब रहे, लेकिन अन्य के लिए यह नहीं था। , , push- , APNs.

— . Apple , , push-extension, , , . , 12 .

Apple Developer Forum , , . , — 10 .

, . AppMetrica. , AppMetrica , Extension . , - .

: Extension .

push-extension UserDefaults. , , AppMetrica.

. . , , . , . , XIVA ( ), , .

, Notification Extension iOS 10 , Extension, , .

AppMetrica : , push-extension . AppMetrica push-, , . , AppMetrica Push SDK .

, . — , . , .



— , , .

, push-, , — .

, , . , …

: , , . , ? - , push-? , ? user experience ?

, 2–3–20 ?

, , , , , , , . , push-. , .

परिणाम

Push- iOS . , .. , .

push- ( ) . . XIVA. , , . , , . !

push-extension. , . , .

, . , , , , - . , push- . , , , App Store, , !

AppsConf , 21 22 , .. 50 , . 1 , — .