MapConductor क्या है ── मानचित्र SDK को "बाद में चुनने योग्य" बनाना

MapConductor एक ओपन-सोर्स SDK है जो एक समान API के माध्यम से मानचित्र SDK को संभालने के लिए है। यह Android (Jetpack Compose), iOS (SwiftUI), React (TypeScript)के लिए उपलब्ध है, और वर्तमान में यह 15 प्रदाताओं का समर्थन करता है। लाइसेंस Apache-2.0 है।

यह पहला लेख है, इसलिए यह क्या करता है, और यह कब काम आता है, इसे फिर से लिख रहा हूँ।

मानचित्र SDK सभी अच्छी तरह से बनाए गए हैं

Google Maps, Mapbox, HERE, ArcGIS, MapLibre, MapTiler, TomTom, Longdo, Mappls ── सभी मानचित्र SDK लंबे समय से बेहतर बनाए गए हैं, और उनमें से प्रत्येक की अपनी विशेषताएँ हैं। सड़कों और पतों का विस्तार, नेविगेशन, GIS संपत्तियों के साथ कनेक्शन, डिज़ाइन की स्वतंत्रता, समर्थित क्षेत्र। "कौन सा सबसे अच्छा है" इस प्रश्न का कोई सामान्य समाधान नहीं है, और उत्तर बनाए जाने वाले ऐप और दिए जाने वाले क्षेत्र के आधार पर बदलता है।

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

यह यह नहीं कि हर कंपनी का डिज़ाइन खराब है। बल्कि यह कि हर कंपनी अपनी विशेषज्ञता के अनुसार ध्यान से डिज़ाइन करती है, इसलिए अवधारणाएँ और नामकरण मेल नहीं खाते, बस इतना ही। जो चीज़ें मेल नहीं खातीं, उन्हें मेल खिलाना SDK प्रदान करने वाले का काम नहीं, बल्कि उसके ऊपर लिखने वाले का काम है। MapConductor यह एक काम अपने ऊपर लेता है।

यह क्या करता है

ऐप केवल MapConductor के एकीकृत API पर निर्भर करता है। प्रदाता-विशिष्ट अंतर ड्राइवर सोख लेता है, इसलिए प्रदाता बदलने पर बदलना होगा केवल निर्भरता मॉड्यूल, मैप व्यू का प्रकार, और स्टेट ऑब्जेक्ट का प्रकार — ये तीन चीज़ें। मार्कर, आकृतियाँ, कैमरा ऑपरेशन, और इवेंट लिखने का तरीका नहीं बदलता।

kotlin // ओवरले की घोषणा शाखा के बाहर रखें। प्रदाता बदलने पर दोबारा नहीं लिखना होगा val overlays: @Composable MapViewScope.() -> Unit = { Marker(markerState) Polyline(routeState) }

if (useMapLibre) { MapLibreMapView(state = maplibre, content = overlays) } else { GoogleMapView(state = googlemaps, content = overlays) }

दो को एक ही स्क्रीन पर साथ रखकर, रनटाइम में बदला भी जा सकता है। बदलने वाले को ताज़ा कैमरा सौंप दें तो दृश्य में छलांग भी नहीं लगेगी।

जो चीजें मेल खाती हैं, वे केवल लिखने का तरीका नहीं हैं

जब आप "सामान्य API" सुनते हैं, तो सबसे बड़ी चिंता यही होती है कि अगर लिखने का तरीका मेल खाता है, तो परिणाम मेल नहीं खाते। ज़ूम 14 का दृश्य वातावरण के अनुसार भिन्न है, दो बिंदुओं के बीच की दूरी Android और iOS पर मेल नहीं खाती ── यह वास्तव में होता है।

MapConductor यह SDK की ओर से संभालता है।

अगर यह सिर्फ एक रैपर है जो प्रत्येक SDK के मेथड को अलग-अलग कॉल करता है, तो आप जो कुछ भी कर पाएंगे, वह "सबसे कम सुविधाओं वाले SDK" के स्तर तक सीमित हो जाएगा। इसीलिए हम यह नीति अपना रहे हैं कि जो कुछ भी कम है, उसे खुद से लिखकर पूरा किया जाए।

यह किस काम आता है

सिर्फ एक API सीखने की ज़रूरत है

मैप SDK में वेंडर के हिसाब से अवधारणाएँ और नामकरण भी अलग-अलग होते हैं, इसलिए हर बार प्रोवाइडर बदलने या प्लेटफ़ॉर्म बदलने पर फिर से सीखना पड़ता है। MapConductor में आपको सिर्फ एक API सीखना होता है, और Android, iOS और React में कहीं भी नाम और अर्थ एक जैसे हैं। Android में मिली जानकारी iOS में भी उसी तरह काम करती है, और टीम में कोई नया आता है तो पढ़ने के लिए वेंडर की संख्या के हिसाब से चीज़ें बढ़ाने की ज़रूरत नहीं होती।

मैप SDK का नाम शामिल न होने वाला कोड लिखा जा सकता है

GeoPoint और MarkerState किसी भी मैप SDK के हिस्से नहीं हैं। रूट बनाना, यह तय करना कि क्या किसी सीमा के भीतर आता है, और क्या दिखाना है — ये सब लॉजिक SDK के टाइप से अलग करके लिखे जा सकते हैं। मैप से जुड़ी सामान्य चीज़ों को, हर प्रोवाइडर के लिए अलग से बनाने के बजाय, एक लाइब्रेरी के रूप में भी अलग निकाला जा सकता है।

स्पेसिफिकेशन पर चर्चा सिर्फ एक बार होती है

अगर Android, iOS और Web में अलग-अलग मैप SDK का इस्तेमाल किया जा रहा है, तो मार्कर का व्यवहार और कैमरे के नंबर का मतलब एक जैसा नहीं होता, और एक ही फीचर के स्पेसिफिकेशन पर आपको 3 बार चर्चा करनी पड़ती है। एक कॉमन मॉडल होने पर ये 3 बार सिर्फ 1 बार हो जाती है।

"चुनने का विकल्प" होने की स्थिति बनाना चाहते हैं

यह तक बात उन लोगों की है जो मैप को एकीकृत कर रहे हैं। MapConductor जो करना चाहता है, वह इतना तक सीमित नहीं है।

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

एक सामान्य API होने से, यह क्रम बदल जाता है। वास्तव में चलाकर, उसी ऐप की उसी स्क्रीन पर देखकर तुलना करें, और उसके बाद निर्णय लें। निर्णय लेने वाले कारक हैं — मूल्य, समर्थित क्षेत्र, डेटा की नवीनता, रेंडरिंग की गुणवत्ता — यानी जहाँ वास्तव में प्रतिस्पर्धा होती है।

इसलिए MapConductor इस तरह बनाया गया है कि यह किसी भी कंपनी की ताकत को नहीं छुपाता। सामान्य रूप से केवल वही बुनियादी कार्यक्षमताएँ एकीकृत हैं जो हर प्रदाता में मौजूद होती हैं। स्टेट ऑब्जेक्ट के getMapViewHolder() को कॉल करके आप मूल मैप व्यू और मैप इंस्टेंस को सीधे निकाल सकते हैं, इसलिए जो कार्यक्षमताएँ केवल उस प्रदाता के पास हैं, उन्हें आप उस कंपनी के API का सीधे उपयोग करके लिख सकते हैं। यदि यह सब कुछ छुपाने वाला एक रैपर होता, तो अंतर करने वाले कारक समाप्त हो जाते, लेकिन ऐसा नहीं है। "सामान्य भाग MapConductor में, और प्रतिस्पर्धा का मैदान हर कंपनी के API में" — यह संयोजन आम बात हैn

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

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

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

उपयुक्त और अनुपयुक्त स्थितियाँ

यह उपयुक्त है, जब ऐसा हो।

• कई प्लेटफ़ॉर्म पर समान मैप अनुभव प्रदान करना हो
• भविष्य में प्रदाता बदलने की संभावना रखनी हो
• मार्कर, आकृतियाँ, कैमरा जैसे मानक मैप प्रदर्शन मुख्य हों
• हज़ारों से लाखों मार्कर का प्रबंधन करना हो
• दूरी और क्षेत्रफल के प्रदर्शन में संगतता की आवश्यकता हो

इसके विपरीत, यह उपयुक्त नहीं है, जब ऐसा हो।

• विशिष्ट प्रदाता-विशिष्ट उन्नत अभिव्यक्तियाँ मुख्य हैं (कस्टम शेडर, वेंडर-विशिष्ट लेयर्स)
• टर्न-बाय-टर्न नेविगेशन आदि के लिए, SDK की समर्पित कार्यक्षमता ही उद्देश्य है
• 1 प्लेटफ़ॉर्म, 1 प्रदाता में पूर्ण होता है, और भविष्य में बदलने की योजना नहीं है

हालांकि, यह सब कुछ या कुछ भी नहीं की स्थिति नहीं है। नेटिव मैप इंस्टेंस तक हमेशा पहुँच है, इसलिए विशेष भाग केवल प्रदाता-विशिष्ट कोड से लिखने की संरचना संभव है।

शुरू करें

MapLibre बिना API की काम करता है, इसलिए पहला मैप दिखने तक लगभग 5 मिनट लगते हैं।

• शुरू करें — MapLibre से पहला मैप दिखाना
• MapConductor क्यों — इस लेख की आधार विचारधारा
• आर्किटेक्चर — एकीकृत API, Core, और ड्राइवर का विभाजन
• समर्थित प्रदाता और सेटअप — प्लेटफ़ॉर्म-वार स्थापना चरण

विकास की प्रगति और रिलीज़ Discord पर सार्वजनिक हैं। डिज़ाइन पर राय और बग रिपोर्ट का स्वागत है। कोड GitHub पर है।