डेवलपर की आंखों के माध्यम से विंडोज फोन के लिए शेरमेटेवो एप्लिकेशन का विकास

हाल ही में (हालांकि पहले से ही पिछले साल) Sheremetyevo आवेदन प्रकाशित किया गया था, जिसे रूस प्रदर्शनी के परिवहन में प्रदर्शित किया गया था। चूँकि मैं इस एप्लिकेशन का डिज़ाइनर था, और शेरेमेयेवो ने प्रदर्शनी में भाग लेने के लिए एक डेवलपर को आवंटित करने और कठिन मुद्दों पर परामर्श करने के लिए कहा, मैं बहुत खुशी से सहमत था - हर दिन मैं इस तरह की प्रदर्शनियों का दौरा करने का प्रबंधन नहीं करता (और यहां काम के दिनों के कारण भी।


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

आवेदन डिजाइन

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


अंजीर। डिजाइन मानचित्र (क्लिक करने योग्य चित्र (पीडीएफ))


प्रारंभिक डिजाइन ने बाद में मामूली बदलाव भी किए।


अंजीर। दृश्य डिजाइन (क्लिक करने योग्य चित्र (पीडीएफ))


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

ग्राहक अनुप्रयोग विकास।

आवेदन की मुख्य कार्यक्षमता एक उड़ान प्रदर्शन है। इस फ़ंक्शन को पहले पृष्ठ पर पैनोरमा तत्व का पहला टैब सौंपा गया था।

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



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

इस व्यवहार को अपने शुद्ध रूप में लागू करने के लिए कई परिस्थितियों द्वारा रोका गया था:

1. अनिवार्य दिशानिर्देश की आवश्यकता - यदि आप स्पष्ट रूप से इसके लिए साइन अप नहीं करते हैं, तो आप अधिसूचना के साथ टोस्ट उपयोगकर्ता को स्पैम नहीं कर सकते।

2. डेस्कटॉप से ​​सेकेंडरी टाइल को हटाने के बाद, एप्लिकेशन को लॉन्च किए बिना, यह पता लगाने का कोई तरीका नहीं है कि क्या टाइल को हटा दिया गया है, या तदनुसार उपयोगकर्ता को अनसब्सक्राइब करें।

अंत में, हम थोड़े अधिक जटिल संस्करण पर बस गए:

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

शायद आवेदन के सबसे जटिल घटकों में से एक POI ऑब्जेक्ट्स के नक्शे के साथ प्रत्येक मंजिल पर टर्मिनलों के लिए एक हवाई अड्डे का नक्शा है ( रुचि का बिंदु , लेख में मैं POI शब्द का उपयोग करूंगा, जो मानचित्र पर वस्तुओं को नामित करने के लिए हमारा कार्यशील शब्द बन गया है)। यह विचार था कि POI को मानचित्र पर प्रदर्शित किया जाता है और उन पर क्लिक करके हम इस POI के विवरण पृष्ठ पर जा सकते हैं और POI के विवरण पृष्ठ से इसके विपरीत हम उस मानचित्र पर जा सकते हैं जहां यह POI स्थित है। इसी समय, मानचित्र को श्रेणी द्वारा प्रदर्शित POI को फ़िल्टर करने में सक्षम होना चाहिए।

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

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

बाद में, जब हमें निर्देशांक के साथ POI के बारे में जानकारी प्राप्त हुई, तो मैंने परतों के साथ काम को फिर से लिखा, ताकि चयनित श्रेणियों के साथ POI के आइकन उस समय मुख्य सब्सट्रेट पर खींचे जा सकें जब नक्शा प्रदर्शित होता है।

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

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

स्कोरबोर्ड और मैप्स के अलावा, एप्लिकेशन में अभी भी POI के बारे में बहुत सारी जानकारी, एयरलाइनों पर डेटा, यात्रियों के लिए नियम और पृष्ठभूमि की जानकारी है। यह माना जाता है कि इसे बहुत कम ही अपडेट किया जाएगा, और सामग्री प्रबंधन प्रणाली को केवल बाद के संस्करणों की रिहाई के लिए विकसित करने की योजना बनाई गई थी। इसलिए, हमने JSON प्रारूप में फ़ाइलों के रूप में एप्लिकेशन के अंदर ऐसे डेटा को सीवे करने का फैसला किया, जिसमें उन्हें नेटवर्क से प्राप्त करना था।

अनुप्रयोग सर्वर साइड विकास

जब तक हमने एप्लिकेशन विकसित करना शुरू किया, तब तक हमारे पास सर्वर साइड के बुनियादी ढांचे के बारे में सटीक जानकारी नहीं थी। इसलिए, मैंने ASP.NET पर एक नियमित सर्वर एप्लिकेशन विकसित करने का निर्णय लिया। यह मान लिया गया था कि यह सामान्य रूप से वितरित समाधान होगा जो अलग-अलग समर्पित सर्वरों पर शेरमेतियोवो विशेषज्ञों द्वारा तैनात किया जाएगा।
लेकिन विकास के दौरान, ग्राहक से नई आवश्यकताएं प्रकट हुईं: सिस्टम के समर्थन को आउटसोर्स करने का एक अवसर होना चाहिए।

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

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

सरलीकृत रूप में सर्वर साइड की वर्तमान वास्तुकला इस प्रकार है।


नए संस्करण में, एकमात्र अंतर यह है कि सर्वर WP के लिए एक विशिष्ट WNS के साथ काम नहीं करता है, लेकिन तुरंत कई प्लेटफार्मों और एंड्रॉइड के लिए, IPhone एप्लिकेशन REST API से जुड़े हैं।

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

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

विंडोज फोन क्यों?

शायद यह सवाल प्रदर्शनी में सबसे लोकप्रिय सवालों में से एक था। विशेष रूप से इस तथ्य की पृष्ठभूमि के खिलाफ कि कुछ आगंतुकों में WP था। ऐसी प्रदर्शनियों में उपस्थिति मुझे यह देखने की अनुमति देती है कि मेरे सामाजिक सर्कल की प्राथमिकताएं अन्य "मंडलियों" की प्राथमिकताओं से कितनी भिन्न हो सकती हैं। यदि बहुमत नहीं है, तो मेरे आधे परिचित और मित्र जो स्मार्टफोन का उपयोग करते हैं, वे विंडोज फोन का उपयोग करते हैं (और मैं मानता हूं, कुछ के लिए मैंने पसंद में एक निश्चित भूमिका निभाई)। प्रदर्शनी में, इस तथ्य के बावजूद कि विभिन्न आँकड़ों के अनुसार एंड्रॉइड रूस में अग्रणी है, मुझे ऐसा लग रहा था कि IPhone उपकरणों का भारी बहुमत था, और जो लोग मुख्य रूप से सैमसंग गैलेक्सी का उपयोग करते थे, जिन्होंने अंततः इस मुद्दे को विशेष रूप से प्रासंगिक बना दिया।

एक छोटा विषयांतर विषय से थोड़ा हटकर है: यह मेरे दोस्तों के लिए एक रहस्य नहीं है कि यद्यपि मैं सभी प्लेटफार्मों के लिए विकसित कर रहा हूं, मेरी प्राथमिकता विंडोज फोन के लिए है। कुछ लोग केवल WP8 उपकरणों को छूने के लिए आए थे, कृपया नोकिया द्वारा प्रदान किए गए, जहां हमने एप्लिकेशन इंस्टॉल किए, और तदनुसार मैंने खुशी से न केवल आवेदन के बारे में सवाल किए, बल्कि WP मंच के बारे में भी सवाल किए। आश्चर्यजनक रूप से, Apple तकनीक के कई मौजूदा मालिक, जिन्होंने हमारे बूथ पर विंडोज फोन का परीक्षण किया, ने बेहद सकारात्मक प्रतिक्रिया दी। सबसे अधिक, यह मुझे लग रहा था, लोगों को प्रासंगिक जानकारी के साथ लाइव टाइल्स द्वारा रिश्वत दी गई थी और एक माध्यमिक टाइल को ठीक करने की बहुत संभावना थी (हमारे मामले में, उड़ानों के लिए अलग से लाइव टाइल को ठीक करने की संभावना)। केवल एक ही व्यक्ति था जिसने मुझे विंडोज फोन और हार्डवेयर बकवास के विषय पर कठोरता से पेश किया था, और हार्डवेयर और ओएस की तुलना में कूलर क्या हो सकता है, आईपीफोन की तुलना में (यहां तक ​​कि मेरी व्यक्तिगत लूमिया 920 ने भी उसे मना नहीं किया था, जिसे मैंने आनंद लिया था)। मैंने इस व्यक्ति के साथ पोलिमिक्स में संलग्न नहीं किया और आश्वस्त किया कि WP भी बुरा नहीं है - प्रदर्शनी में मैंने अपने आवेदन और विंडोज फोन प्लेटफॉर्म की क्षमताओं को दिखाया, और सभी ने खुद को निष्कर्ष बनाया।


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

सर्वर, क्लाइंट भागों और सामग्री के साथ काम करने के लिए विशेष रूप से विकसित उपयोगिताओं के लिए एक मंच (.NET) का उपयोग करके अपेक्षाकृत सस्ते बदलाव करना संभव हो गया है। प्रायः सभी तीन प्रकार की परियोजनाओं के लिए मॉडल के साथ केवल एक विधानसभा में परिवर्तन करना आवश्यक था (पोर्टेबल लाइब्रेरी के लिए विशेष धन्यवाद, जो अब VS2012 का हिस्सा बन गया और इसे VS2010 के विस्तार के रूप में प्रदान किया गया)। डेटा मॉडल में कोई भी बदलाव तुरंत सभी परियोजनाओं में दिखाई दिया।

कार्य में कठिनाइयों का सामना करना पड़ा।

विकास के स्तर पर

जैसा कि मैंने ऊपर लिखा था, ज्यादातर सभी कार्ड के साथ किए गए थे। यह विकास के लिए सबसे कठिन घटकों में से एक था, जिसमें आवश्यकताओं को कई बार बदला गया।
LongListSelector पहले से ही कई बार विफल हो गया है, और यहां तक ​​कि नवीनतम अपडेट में भी उन्होंने रेंडरिंग इमेज के बग को ठीक नहीं किया है, जो देखा जा सकता है अगर हेडर में सामान्य अक्षरों के बजाय टाइल्स का उपयोग करें। अंततः, इस बग को अपने दम पर ठीक करने के कुछ प्रयासों के बाद, हमने इसे उच्च-गुणवत्ता वाले टेलरिक समकक्ष के साथ बदलने का फैसला किया, जिसे इस बग को बख्शा गया।

Telerik नियंत्रण केवल भव्य हैं, लेकिन मैं रखरखाव की प्रकृति के कारण यथासंभव भुगतान किए गए उत्पादों से बचने की कोशिश करता हूं।

इस परियोजना में भी, मैंने अपने ओपन सोर्स प्रोजेक्ट WPExtensions, विशेष रूप से, AdvancedApplicationBar का उपयोग किया, जिसने ApplicationBar के साथ काम को बहुत सरल कर दिया। उदाहरण के लिए, POI के विवरण में, AppBar में उन बटनों को छिपाना आवश्यक था जिनके लिए कोई जानकारी नहीं थी (उदाहरण के लिए, किसी वेबसाइट को कॉल करना या खोलना इत्यादि), और मानक AppBar में दृश्यता गुण गायब था। तदनुसार, इस लाइब्रेरी का उपयोग करना एप्लिकेशनबीआर के साथ एमवीवीएम का उपयोग करना भी सुविधाजनक था। दुर्भाग्य से, उस संस्करण में, जो नगेट में निहित है, एक बदसूरत चिकोटी लगाने वाले AppBar के साथ कई कीड़े हैं। परियोजना में मैंने एक और हालिया संस्करण का उपयोग किया, इन कमियों से सुधारा, लेकिन इतनी अच्छी तरह से काम नहीं किया कि नगेट में बिछाने के लिए कोड की गुणवत्ता के संदर्भ में काम किया।

संगठनात्मक चुनौतियां

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

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

प्रमाणन मुद्दे

प्रमाणन, भी, आश्चर्य के बिना नहीं था।

हमारे मामले में, आवेदन ने इस तथ्य के कारण प्रमाणीकरण पारित नहीं किया कि आवेदन "चीन में धार्मिक भावनाओं का अपमान करता है।" क्या वास्तव में चीनी ने सामग्री को कृपया नहीं किया है, यह पता लगाना संभव नहीं था। इस प्रकार, हमने आवेदन को पुनः प्रकाशित करने के लिए एक और 5 दिन का समय गंवा दिया, बस मामले में सभी देशों को कसी हुई सामग्री आवश्यकताओं को छोड़कर।

भविष्य के संस्करणों में, हम चीन में प्रमाणित होने की उम्मीद करते हैं, और मैं केवल डेवलपर्स को सलाह दे सकता हूं कि यदि आवेदन को जल्दी जारी करने की आवश्यकता है, तो पहले प्रकाशन में उन देशों को बढ़ी हुई सामग्री आवश्यकताओं के साथ संकेत देना आवश्यक नहीं है, भले ही वे 100% सुनिश्चित हों कि कोई उल्लंघन नहीं है।