गाइडबुक का लंबा इतिहास - मैंने 5 साल तक स्मार्ट हाइकिंग ट्रेल्स के लिए एक सेवा कैसे लिखी

कई के पास एक या एक से अधिक घर परियोजनाएं हैं। ये छोटी उपयोगिताओं, प्रयोगात्मक टुकड़े, नई प्रौद्योगिकियों के नमूने, फेसबुक "हत्यारे" और बहुत कुछ हैं। विशेष रूप से कम अक्सर ऐसी परियोजनाएं लंबे समय तक लगी रहती हैं।

लेख में मैं अपना अनुभव साझा करूंगा और आपको बताऊंगा कि कैसे 5 साल तक मैंने कभी-कभी सेंट पीटर्सबर्ग के लिए एक स्मार्ट गाइडबुक के विकास पर काम किया, कैसे मैं इस व्यवसाय को छोड़ने में कामयाब नहीं हुआ, परियोजना के प्रति दृष्टिकोण कैसे बदल गया और अंत में क्या हुआ।

कई संदिग्ध तकनीकी समाधान और साइकिल नीचे वर्णित हैं, लेकिन आश्चर्यचकित न हों - उनमें से लगभग सभी उस समय उपलब्ध लक्ष्यों और संसाधनों के लिए उचित हैं (= आमतौर पर मेरा ज्ञान और समय)

विचार

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

इसलिए, स्मार्ट मार्गों के निर्माण का विचार आया। उपयोगकर्ता ए और बी का चयन करता है और क्लासिक लघु मार्ग को प्राप्त नहीं करता है, लेकिन इसके करीब कुछ है, लेकिन पास के आकर्षण से गुजर रहा है।

इस तरह के एक गाइड के दर्शक न केवल पर्यटक हैं, बल्कि स्थानीय निवासी भी हैं जो अपने विशिष्ट मार्गों को घर / कार्य / स्टोर में विविधता लाना चाहते हैं (और ऐप में ऐसी समीक्षाएं थीं!) या शहर को जानने के लिए बेहतर है।

टीएल, डॉ
लब्बोलुआब यह है कि वांडर एंड्रॉइड एप्लिकेशन है, जो अब केवल सेंट पीटर्सबर्ग के लिए काम करता है।

अधिनियम 1: प्रोटोटाइप

यह विचार 2014 में विश्वविद्यालय में वापस आया, मुझे यह भी सुनिश्चित नहीं था कि यह विचार मूल रूप से मेरा था, किसी न किसी समूह में समूहों को तोड़ने, परियोजनाओं के साथ आने और उन्हें एक टर्म पेपर के रूप में पूरा करने के लिए आवश्यक था। वे दुर्घटनाग्रस्त हो गए और परियोजना का विचार उत्पन्न किया, और फिर TravelPath नाम शुरू हुआ।

यह एक वेब सेवा माना जाता था, मैं PHP के बारे में थोड़ा जानता था, इसलिए मैंने PHP को चुना।
कई समस्याओं को हल करना आवश्यक था:

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

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

यदि मैंने अपने पुराने कोड का सही ढंग से पता लगाया, तो मैंने वस्तुओं को लाने के लिए निम्न टैग का उपयोग किया:

• building अर्थ cathedral , chapel , church एक church श्रेणी बन गया है
• fountain मूल्यों के साथ fountain monument में गिर जाता है
• artwork और viewpoint साथ tourism monument , zoo और museum से museum और theme_park से park
• boundary_stone , castle , memorial , monument मूल्यों के साथ historic monument श्रेणी में जाता है
• park में एक मूल्य के साथ leisure स्वाभाविक रूप से park समाप्त होता park

हमने सभी प्राप्त वस्तुओं को एक डेटाबेस में निर्देशांक और आनन्द के साथ रखा है! सेंट पीटर्सबर्ग में 1,200 से अधिक अंक जारी किए गए हैं।

2. एक मार्ग का निर्माण
यह पाठ्यक्रम के हिस्से के रूप में जटिल प्रणालियों को लागू करने के लिए नहीं था, और उस समय तकनीकी ज्ञान दुर्लभ था, इसलिए हमने मार्ग निर्माण को दो भागों में विभाजित करने का निर्णय लिया: मार्ग में वस्तुओं की पसंद और मार्ग निर्माण स्वयं। भाग में, इसने भविष्य के भाग्य का निर्धारण किया, क्योंकि बाद में मैं इस योजना को बदलना नहीं चाहता था।

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

वस्तुओं का चुनाव खुद ही करना पड़ता था। इसने आवेदन की निम्नलिखित योजना को बदल दिया:

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

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

समस्या का एक बहुत स्पष्ट बयान नहीं है, एक ही एल्गोरिथ्म सामने आया, ए * ( विकी ) के समान: यह माना जाता है कि प्रत्येक बिंदु से प्रत्येक में परिवर्तन होते हैं। इसके अलावा, ए * में, एबी मार्ग की खोज करते समय वर्टेक्स एन में जाने की कीमत आमतौर पर निम्नानुसार व्यक्त की जाती है: f(n) = g(An) + h(nB) , जहां g(x,y) एक्स से वाई और h(x,y) से पथ की लंबाई है h(x,y) x से y की दूरी का एक अनुमानी अनुमान है। मेरी कीमत समान है - f(n) = h(x,n) + h(n,y) * q , जहाँ q एक स्थिर से कम है 1. q के मान को बदलकर, आप मार्ग में अंकों की संख्या को प्रभावित कर सकते हैं।

हम एल्गोरिथ्म को लागू करते हैं और, चीयर्स, सब कुछ काम करता है, इंटरफ़ेस को तेज करता है, एक डोमेन खरीदता है, इसे होस्टिंग पर अपलोड करता है, रिपोर्ट और अन्य नौकरशाही लिखता है और आनन्दित होता है! यह कुछ ऐसा दिखता था (और इसके बाद बहुत कुछ नहीं बदला):

कुल: मुझे एक शांत विचार का प्रोटोटाइप मिला, ओएसएम से परिचित हुआ, Google एपीआई, एक टीम के रूप में काम किया, विश्वविद्यालय में क्रेडिट मिला, और यह भी दिलचस्प था।

अधिनियम 2: पहला पूर्ण वेब संस्करण

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

यह 2015 में था, और मैंने यात्रापथ पर काम करना जारी रखा, इस घातक दोष का सुधार किया - मैंने अपने खुद के तरीकों का निर्माण करना शुरू कर दिया।

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

निम्नलिखित कार्य उत्पन्न हुए:

1. शहर का ग्राफ प्राप्त करना
यहाँ वही OSM हमें बचाता है। फिर से, xml प्रारूप में ग्राफ डाउनलोड करें, इसे पार्स करें, केवल आवश्यक प्रकार की सड़कों का चयन करें और डेटा की मात्रा में चमत्कार करें - उस समय 3 मिलियन से अधिक कोने और 500k किनारे बाहर आ गए। पहला विचार यह है कि ग्राफ असंबंधित हो सकता है।
मार्ग के निर्माण के लिए कोई भी आंगन, संलग्न क्षेत्र, अतुलनीय चीजें बहुत दिलचस्प नहीं हैं, इसलिए हम कुछ बिंदु का चयन करते हैं, इसमें से पूरे ग्राफ़ पर जाएं, पास किए गए सिरों को चिह्नित करें और ग्राफ़ का जुड़ा हिस्सा प्राप्त करें।
कुल मिलाकर, 600k से अधिक चोटियाँ और 150k किनारे बाहर आ गए।
डेटाबेस में प्राप्त को बचाया और बेहतर समय तक छोड़ दिया।

2. एक मार्ग का निर्माण
डेटा है, यह सब छोटे पर छोड़ दिया गया है: इस पर मार्गों का निर्माण करें। हमें कुछ नया आविष्कार नहीं करना है - एल्गोरिदम के पाठ्यक्रम को याद रखें, ग्राफ़ के साथ काम करने पर सावधानीपूर्वक लेख पढ़ें, ए * एल्गोरिथ्म लें, इसे पीएचपी में लागू करें। आनन्द करे सब कुछ धीरे-धीरे कैसे काम करता है, से निराश।

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

(लाल फ्रेम = ~ इस तरह का ग्राफ पथ बनाने के लिए पढ़ा गया था)

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

3. उचित समय में रूटिंग करना
यह तुरंत स्पष्ट हो गया कि अड़चन भंडारण है और डेटा के साथ काम करता है - खोज एल्गोरिथ्म स्वयं विशेष रूप से त्वरित नहीं है। और घुटने पर बेंचमार्क इस बात की पुष्टि करता है कि अधिकांश समय डेटाबेस और इसी तरह के जोड़तोड़ से पढ़ने में खर्च होता है।
ऐसे मामलों में क्या किया जाना चाहिए? इस ग्राफ को स्टोर न करें। लेकिन मेरे पास एक विशेष तरीका है, MySQL और कुछ भी नहीं है, लेकिन समस्या को हल करने की आवश्यकता है।

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

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

नीचे पंक्ति: मैं OSM डेटा से और भी बेहतर तरीके से परिचित हो गया, व्यवहार में मैंने ग्राफ़ की समस्याओं को हल किया (मामला जब ग्राफ़ एल्गोरिदम अंततः उपयोगी थे), मेरा पहला बेंचमार्क लिखा।

अधिनियम 3: पहला सामान्य वेब संस्करण

यहां एक उत्पाद के रूप में परियोजना के बारे में पहला विचार आता है जो किसी के लिए उपयोगी हो सकता है, और मेज पर शिल्प के बारे में नहीं।
तो आपको दो सबसे महत्वपूर्ण समस्याओं को हल करने की आवश्यकता है:

1. यह तुरंत स्पष्ट हो गया था कि पिछले पैराग्राफ में मार्गों का निर्माण करना गलत है।
2. ब्राउज़र में एक मार्गदर्शक किसी के लिए सुविधाजनक नहीं हो सकता है - आप शहर के चारों ओर घूमना चाहते हैं, एक सुविधाजनक एप्लिकेशन की तलाश में जहां आप पढ़ सकते हैं कि आसपास क्या है और इतने पर क्या है। संक्षेप में, कम से कम - आपको एक शांत अनुकूली इंटरफ़ेस की आवश्यकता है, और एक अच्छे तरीके से एक मोबाइल एप्लिकेशन।

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

हम ग्राहक के हिस्से को भी नहीं छूते हैं - इसकी ओर से, हमारी सेवा का एपीआई किसी भी तरह से नहीं बदलता है।

कुल : मैंने दूसरों द्वारा आवेदन के वास्तविक उपयोग के बारे में सोचा, यह एक सामान्य वास्तुकला और अच्छे मार्ग थे। वेब संस्करण अभी भी उपलब्ध है, हालांकि यह तब से नहीं बदला है। https://travelpath.ru/

अधिनियम 4: एंड्रॉइड ऐप

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

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

पहला लेआउट और प्रोटोटाइप
सबसे पहले, हम एक नए नाम के साथ आने की कोशिश कर रहे हैं, क्योंकि TravelPath एक बहुत, और बहुत संक्षिप्त नाम नहीं है। और इसलिए सिरिल के प्रयासों के माध्यम से एक अजीब लोगो के साथ "घूमना" दिखाई देता है:

मैंने इसे एक उत्साही व्यक्ति के साथ दृढ़ता से जोड़ा है, लेकिन सामान्य तौर पर मुझे यह पसंद है।

फिर भविष्य के आवेदन के पहले लेआउट दिखाई देते हैं:

हम यह भी सोचते हैं, चर्चा करते हैं, दूसरा विकल्प दिखाई देता है, जो अनुप्रयोग का पहला संस्करण बन जाता है:

विकास की ओर से, मैंने जानबूझकर सभी प्रकार के फैशनेबल फ्रेमवर्क का उपयोग नहीं करने का फैसला किया है जो अलग-अलग जादू करते हैं - क्योंकि काम को समझने के बिना उनका उपयोग करते समय बड़े जोखिम होते हैं, और दोनों मूल बातें अध्ययन करते हैं और वे बहुत समय लेने वाली होती हैं। Google, हम आधिकारिक डॉक, शैक्षिक लेख पढ़ते हैं और हम कठिनाइयों को दूर करते हैं।

याद की जाने वाली समस्याओं और कार्यों में से:

• Android के लिए, ProGuard - एक उपयोगिता जो असेंबली के दौरान स्रोत कोड को संपीड़ित करती है, अप्रयुक्त को काट देती है, नामों को बदल देती है और बहुत कुछ। यह उचित है कि यह मौजूद है, लेकिन जब आप सिर्फ विकास में जाते हैं और इसे स्वयं करते हैं - तो यह स्पष्ट नहीं है कि नाम बदलने वाले क्षेत्र हैं और यह व्यवहार को प्रभावित कर सकता है। और यह सब कुछ केवल विधानसभा में होता है। रिहाई के परिणामस्वरूप, सब कुछ शांत है, लेकिन किसी कारण से कोई आंकड़े नहीं हैं। आप बैकएंड से बहस करना शुरू करते हैं - और क्लाइंट सामान्य क्षेत्र के नामों के बजाय कुछ बकवास भेजता है - a, b, c , आदि। ऐसा लगता है कि API कुशलता से इसे पार्स करने में सक्षम है, और तब आपको पता चलता है कि ProGuard ने कोशिश की और आपको इसके विन्यास में अपवाद के रूप में आवश्यक कक्षाएं निर्दिष्ट करने की आवश्यकता है। सामान्य तौर पर कुछ भी असामान्य नहीं है, लेकिन डिबगिंग घड़ी उड़ गई।
• एक दिलचस्प कार्य एप्लिकेशन डेटा को अपडेट कर रहा था। मुख्य डेटाबेस एक apk फ़ाइल के साथ आता है और मैं प्रत्येक रिलीज़ से पहले इसे अपडेट करता हूं। लेकिन आपको नेटवर्क पर अपडेट का समर्थन करने की भी आवश्यकता है ताकि किसी भी तरह के बदलाव होने पर क्लाइंट के पास हमेशा ताजा डेटा हो।
  पहले संस्करण में, मैंने अंतिम अपडेट के समय पर ध्यान केंद्रित करने का निर्णय लिया। एप्लिकेशन सबसे ताज़ी वस्तु के समय को संग्रहीत करता है, प्रत्येक शुरुआत में यह इस समय के साथ बैकेंड से पूछता है कि क्या कुछ नया दिखाई दिया है। अपडेट उसे भेजे जाते हैं, ग्राहक को प्राप्त वस्तुओं में से सबसे नया समय फिर से याद आता है (लेकिन अपडेट का समय ही नहीं, यह महत्वपूर्ण है)।
  यह पता चला कि मैंने बुरी तरह से सोचा - क्योंकि एक साल बाद एक पांचवीं श्रेणी दिखाई दी - इमारतें। और पुराने से नए संस्करण में अपग्रेड करते समय, एक समस्या उत्पन्न होती है। मुझे थोड़ा बदलना पड़ा और क्लाइंट प्रत्येक श्रेणी के लिए समय भेजता है, सामान्य नहीं। लेकिन यह योजना अभी भी सही नहीं है - वस्तुओं में नए क्षेत्रों को जोड़ते समय, समस्याएं पैदा होती हैं जिन्हें उस तरह हल नहीं किया जा सकता है। बेहतर करने के तरीके पर विचार हैं, लेकिन हाथ नहीं पहुंचे और सामान्य तौर पर कार्य बहुत प्राथमिकता नहीं है। नैतिकता - इन मुद्दों पर सावधानीपूर्वक दृष्टिकोण करना और अग्रिम में थोड़ा सोचना उचित है।

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

5 दिसंबर, 2016 एप्लिकेशन Google Play को हिट करता है
उनके पास केवल मूल कार्य थे - एक मार्ग बिछाने, अंकों के बारे में जानकारी देखने के लिए। लेकिन यह भी एक सफलता लग रहा था! सफलता, ज़ाहिर है, केवल उनकी अपनी आँखों में। एक समझ थी कि आवेदन अभी भी कच्चा है और इसमें सुधार करने की आवश्यकता है।

पहला पूर्ण संस्करण और मीडिया
इसलिए, मैं अगली रिलीज़ को एक पूर्ण संस्करण और पहला लॉन्च मानता हूं।
सबसे पहले, हमने डिजाइन और लोगो दोनों की समीक्षा की - अब यह इस तरह बन गया है:

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

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

अंत में, यह अच्छा निकला और आखिरकार आवेदन का पूरी तरह से उपयोग किया जा सका। 2 जून 2018 को, एक रिलीज़ रिलीज़ किया गया था और हमने इसे दुनिया को दिखाने की कोशिश करने का फैसला किया - हमने VKontakte और Instagram पर कुछ विज्ञापन खरीदे। लेकिन सबसे महत्वपूर्ण बात, उन्होंने कुछ मीडिया आउटलेट्स को लिखा। पेपर ने एप्लिकेशन के लॉन्च के बारे में एक नोट लिखा, इसके बाद कई पीटर्सबर्ग प्रकाशन - द विलेज, डॉग और अन्य - एक प्रशंसक के साथ लिखे गए या पुनर्मुद्रित किए गए। और अंत में यातायात था! एप्‍लीकेशन में चोटी, एक्टिविटी ग्राफ के साथ रस्साकसी भी हुई। बेशक, हमें लंबे समय तक खुशी नहीं मिली - लेकिन हमें पहले उपयोगकर्ता, एक उपयोगी प्रतिक्रिया मिली और सामान्य तौर पर यह बहुत प्रेरक था। उसी गर्मियों में, Google Play खोज से यातायात ध्यान देने योग्य था, जो बहुत ही मनभावन था, लेकिन बाद में परिणाम फिर से नहीं लाया जा सका।
सभी ने मिलकर, यह एक बहुत मजबूत प्रेरणा दी और आवेदन पर काम जारी रखने में मदद की।

आगे क्या करना है? संग्रहालय रात, बुराई गूगल, परिपत्र मार्गों

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

इस मोड के अलावा, बैकलॉग से भी हमें मार्ग का संरक्षण मिला और सबसे महत्वपूर्ण बात - परिपत्र मार्गों के बारे में सुविधा।

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

, .

, , :

, , , , , . — , , .

Kotlin , , Wander. , . , . , java — .

, , , . — The Village. - 1000 , 1400 . , Wander , , , . .

Google . — 2018 , API. — 2018- Places API . API, - — . .

— Places API , . , . , — Google Maps, . .

: android Google Play, . burovk , Wander , .

, , , — . , , , — . , — , . , , .

• — git tag v1.0.5 .
• , , , .
• - , .
• — , //etc .

Android . , , , .

— , .

! , . , , , , , .
:

1. — ? - ?
2. . , — .
3. IOS

. , IOS , .

— . Google Play .

निष्कर्ष

• , — . , . . , .
• — , . backend , , android Kotlin, , , . , .
• — . - , . - . , — .

. IOS ( ) — !

पुनश्च
— https://habr.com/post/414433/ . . , ( -!), .