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

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

QR कोड के बारे में क्या?

क्यूआर कोड

QR (क्विक रिस्पांस) कोड दुनिया में सबसे लोकप्रिय प्रकार का विज़ुअल कोड है। यह आपको 3KB तक के मनमाने डेटा को एनकोड करने की अनुमति देता है और इसमें विभिन्न त्रुटि सुधार स्तर होते हैं, जिससे आप आत्मविश्वास से बंद या गंदे कोड के एक तिहाई भी पढ़ सकते हैं।

लेकिन क्यूआर कोड के साथ दो समस्याएं हैं:

• 3KB पर्याप्त नहीं है
• अधिक डेटा एन्कोडेड, स्कैन करने के लिए छवि के लिए उच्च गुणवत्ता की आवश्यकताएं

यहां 1276 बाइट्स के साथ 40 वें संस्करण (उच्चतम रिकॉर्डिंग घनत्व) का क्यूआर कोड है:

अपने कार्य के लिए, मुझे यह सीखने की ज़रूरत थी कि मानक उपकरणों (स्मार्टफ़ोन / टैबलेट) पर डेटा का ~ 15KB हस्तांतरण कैसे किया जाए, इसलिए यह प्रश्न स्वयं ही पैदा हो गया - क्यूआर कोड के अनुक्रम को चेतन क्यों नहीं करना चाहिए और डेटा को टुकड़ों में स्थानांतरित नहीं करना चाहिए?

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

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

TXQR

तो txqr प्रोजेक्ट का जन्म हुआ (Tx - ट्रांसमिशन और QR से), जो शुद्ध गो पर क्यूआर को एन्कोडिंग / डिकोड करने के लिए एक पुस्तकालय को लागू करता है और डेटा संचारित करने के लिए एक प्रोटोकॉल।

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

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

इसके अलावा, फ्रेम का आकार और आवृत्ति भी गतिशील रूप से बदली जा सकती है, जो प्राप्तकर्ता की क्षमताओं के अनुकूल है।

प्रोटोकॉल स्वयं बहुत सरल है, और इसका मुख्य ऋण यह है कि बड़ी फ़ाइलों के लिए (हालांकि यह कार्य के दायरे से परे है, लेकिन स्कैनिंग के दौरान स्केप किया गया एक फ्रेम स्कैनिंग समय को दोगुना कर देगा - प्राप्तकर्ता को फिर से पूर्ण चक्र की प्रतीक्षा करनी होगी। कोडिंग सिद्धांत में ऐसे मामलों के लिए समाधान हैं - फाउंटेन कोड , लेकिन मैं इसे निम्नलिखित कुछ मुफ्त दिनों के लिए छोड़ दूंगा।

सबसे दिलचस्प बिंदु एक मोबाइल एप्लिकेशन लिखना था जो इस प्रोटोकॉल का उपयोग कर सकता है।

GoMobile

यदि आपने गोमोबाइल के बारे में नहीं सुना है, तो यह एक ऐसी परियोजना है जो आपको आईओएस और एंड्रॉइड परियोजनाओं में गो पुस्तकालयों का उपयोग करने की अनुमति देती है और इसे एक अश्लील सरल प्रक्रिया बनाती है।

मानक प्रक्रिया इस प्रकार है:

• आप नियमित गो कोड लिखें
• gomobile bind ... रन gomobile bind ...
• अपने मोबाइल प्रोजेक्ट में परिणामी कलाकृति (ओं) ( yourpackage.framework. या yourpackage.aar ) की प्रतिलिपि बनाएँ
• अपना yourpackage आयात yourpackage और एक नियमित पुस्तकालय की तरह इसके साथ काम करें

आप कोशिश कर सकते हैं कि यह कितना आसान है।

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

स्विफ्ट के लिए एक नौसिखिया के रूप में (भले ही मैं स्विफ्ट 4 किताब पढ़ता हूं), काफी कुछ क्षण थे जब मैं कुछ सरल पर अटक गया, यह पता लगाने की कोशिश कर रहा था कि यह कैसे सही है और अंत में, सबसे अच्छा समाधान इस कार्यक्षमता को लागू करने के लिए जाओ और उपयोग करें। gomobile के माध्यम से। मुझे गलत मत समझो, स्विफ्ट कई मायनों में एक अद्भुत भाषा है, लेकिन, अन्य प्रोग्रामिंग भाषाओं की तरह, यह एक ही काम करने के लिए बहुत सारे तरीके प्रदान करता है, और पहले से ही पिछड़े असंगत परिवर्तनों का एक सभ्य इतिहास है। उदाहरण के लिए, मुझे एक साधारण बात करने की ज़रूरत थी - मिलीसेकंड सटीकता के साथ एक घटना की अवधि को मापने के लिए। Google और StackOverflow पर एक खोज के कारण अलग-अलग, विरोधाभासी और अक्सर पुराने समाधानों की मेजबानी हुई, जिनमें से कोई भी, अंत में, मेरे लिए या तो सुंदर दिखे या संकलक के लिए सही। 40 मिनट का समय व्यतीत करने के बाद, मैंने अभी गो पैकेज में एक और तरीका बनाया है, जिसे time.Since(start) / time.Millisecond कहा जाता है और इसके परिणाम का उपयोग स्विफ्ट से सीधे किया जाता है।

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

TXQR परीक्षक

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

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

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

वेक्टी और गोफरजेएस

मेरे जीवन में, मुझे फ्रंट-एंड इंटरफेस के विकास से ऐसा आनंद नहीं मिला है।

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

शुरुआत के लिए, यह है कि आप कैसे वेक्टी (कोई "प्रारंभिक परियोजना" कोड जनरेटर पर फ़ाइलों और फ़ोल्डरों के टन बनाने का एक नया प्रोजेक्ट शुरू करते हैं) - बस main.go:

 ackage main import ( "github.com/gopherjs/vecty" ) func main() { app := NewApp() vecty.SetTitle("My App") vecty.AddStylesheet(/* ... add your css... */) vecty.RenderBody(app) } 

किसी भी UI घटक की तरह एक एप्लिकेशन, केवल एक प्रकार है: एक संरचना जिसमें vecty.Core प्रकार शामिल है और vecty.Component इंटरफ़ेस (एक Render() विधि से मिलकर Render() को लागू करना चाहिए। और वह सब है! फिर आप डोम के साथ काम करने के लिए प्रकार, विधियों, कार्यों, पुस्तकालयों के साथ काम करते हैं, और इसी तरह - कोई छिपा हुआ जादू और नए नियम और अवधारणाएं नहीं। यहाँ मुख्य पृष्ठ के लिए सरलीकृत कोड दिया गया है:

 / App is a top-level app component. type App struct { vecty.Core session *Session settings *Settings // any other stuff you need, // it's just a struct } // Render implements the vecty.Component interface. func (a *App) Render() vecty.ComponentOrHTML { return elem.Body( a.header(), elem.Div( vecty.Markup( vecty.Class("columns"), ), // Left half elem.Div( vecty.Markup( vecty.Class("column", "is-half"), ), elem.Div(a.QR()), // QR display zone ), // Right half elem.Div( vecty.Markup( vecty.Class("column", "is-half"), ), vecty.If(!a.session.Started(), elem.Div( a.settings, )), vecty.If(a.session.Started(), elem.Div( a.resultsTable, )), ), ), vecty.Markup( event.KeyDown(a.KeyListener), ), ) } 

आप शायद अब कोड देख रहे हैं और सोच रहे हैं - डोम के साथ कितना निराधार काम है! मैंने भी पहले ऐसा सोचा था, लेकिन जैसे ही मैंने काम करना शुरू किया, मुझे एहसास हुआ कि यह कितना सुविधाजनक था:

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

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

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

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

हालाँकि, वास्तविक जादू तब शुरू होता है जब आप जावास्क्रिप्ट में गो कोड संकलित करते हैं। यह बहुत डराने वाला लगता है, लेकिन, वास्तव में, आप सिर्फ gopherjs build कहते हैं और एक सेकंड से भी कम समय में, आपके पास एक ऑटो-जेनरेट की गई जावास्क्रिप्ट फाइल है जो आपके मूल HTML पेज में शामिल होने के लिए तैयार है (एक नियमित एप्लिकेशन में केवल एक खाली बॉडी टैग और इसे शामिल करना शामिल है जेएस स्क्रिप्ट)। जब मैंने पहली बार इस कमांड को चलाया था, तो मुझे बहुत सारे संदेश, चेतावनी और त्रुटियों को देखने की उम्मीद थी, लेकिन नहीं - यह काल्पनिक रूप से तेज़ और चुपचाप काम करता है, यह केवल संकलक त्रुटियों के मामले में एक-लाइनर्स को प्रिंट करता है जो कि गो संकलक द्वारा उत्पन्न होते हैं, इसलिए यह बहुत स्पष्ट है। लेकिन यह ब्राउजर कंसोल में त्रुटियों को देखने के लिए और भी ठंडा था, जिसमें स्टैक के निशान थे .go फाइलें और सही लाइन! यह बहुत अच्छा है।

क्यूआर एनीमेशन मापदंडों का परीक्षण

कई घंटों के लिए मेरे पास एक वेब एप्लिकेशन तैयार था जिसने मुझे परीक्षण के लिए मापदंडों को जल्दी से बदलने की अनुमति दी:

• एफपीएस - फ्रेम दर
• क्यूआर फ़्रेम का आकार - प्रत्येक फ्रेम में कितने बाइट्स होने चाहिए
• क्यूआर रिकवरी स्तर - क्यूआर त्रुटि सुधार स्तर

और परीक्षण स्वचालित रूप से चलाएं।

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

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

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

मोबाइल डिवाइस को यह बताने की समस्या थी कि वास्तव में कनेक्ट करने के लिए कहां, और क्यूआर कोड का उपयोग करके इसे हल किया गया है!

परीक्षण प्रक्रिया इस तरह दिखती है:

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

नतीजतन, मेरे लिए जो कुछ बचा था, वह बस एक तिपाई पर फोन लगाने के लिए था, एप्लिकेशन लॉन्च करना, और फिर दो कार्यक्रमों ने खुद सभी गंदे काम किए, विनम्रता से क्यूआर कोड और वेबस्केट के माध्यम से संचार :)

अंत में, मैंने परिणामों के साथ CSV फ़ाइल डाउनलोड की, इसे RStudio और प्लॉटली ऑनलाइन चार्ट मेकर के लिए भेजा और परिणामों का विश्लेषण किया।

परिणाम

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

• एफपीएस - 3 से 12
• क्यूआर फ्रेम का आकार 100 से 1000 बाइट्स (50 की वृद्धि में) है
• QR त्रुटि सुधार के सभी 4 स्तर (कम, मध्यम, उच्च, उच्चतम)
• स्थानांतरित फ़ाइल आकार - 13KB बेतरतीब ढंग से उत्पन्न बाइट्स

कुछ घंटों बाद मैंने CSV डाउनलोड किया और परिणामों का विश्लेषण करना शुरू किया।

एक तस्वीर एक हजार शब्दों से अधिक महत्वपूर्ण है, लेकिन इंटरैक्टिव 3 डी विज़ुअलाइजेशन एक हजार चित्रों की तुलना में अधिक महत्वपूर्ण हैं। यहां परिणामों का एक दृश्य है (क्लिक करने योग्य):

सबसे अच्छा परिणाम 1.4 सेकंड था, जो लगभग 9KB / s है! यह परिणाम 11 फ्रेम प्रति सेकंड की आवृत्ति, 850 बाइट्स के फ्रेम आकार और त्रुटि सुधार के औसत स्तर पर दर्ज किया गया था। ज्यादातर मामलों में, हालांकि, इस गति से, कैमरा डिकोडर ने कुछ फ़्रेमों को छोड़ दिया, और मिस्ड फ़्रेम के अगले दोहराने के लिए इंतजार करना पड़ा, जिसके परिणामों पर बहुत नकारात्मक प्रभाव पड़ा - दो सेकंड के बजाय यह आसानी से 15, या एक समय सीमा 30 सेकंड के लिए सेट किया जा सकता था।

चर चर पर परिणामों की निर्भरता के ग्राफ इस प्रकार हैं:

फ़्रेम समय / आकार

जैसा कि आप देख सकते हैं, प्रत्येक फ्रेम में बाइट्स की संख्या के कम मूल्यों पर, अतिरिक्त एन्कोडिंग बहुत बड़ी है और कुल रीड टाइम, क्रमशः, भी है। प्रति फ्रेम में कुछ स्थानीय न्यूनतम 500-600 बाइट्स हैं, लेकिन इसके आगे के मान अभी भी खोए हुए फ़्रेमों को जन्म देते हैं। सबसे अच्छा परिणाम 900 बाइट्स में देखा गया था, लेकिन 1000 और इसके बाद के संस्करण की गारंटी लगभग फ्रेम हानि है।

समय / एफपीएस

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

समय / त्रुटि सुधार स्तर

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

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

निष्कर्ष

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

मैं भी एक नियमित समस्या को सुलझाने के उपकरण के रूप में Vecty के साथ Gomobile और GopherJS का उपयोग करने का आनंद लिया। ये बहुत परिपक्व परियोजनाएं हैं, जिनमें काम की उत्कृष्ट गति है, और, ज्यादातर मामलों में, यह "बस काम करता है" का अनुभव देता है।

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

इसलिए यदि आपने कभी Gomobile या GopherJS की कोशिश नहीं की है - मैं सलाह देता हूं कि आप अगले अवसर पर प्रयास करें। आपके समय का एक घंटा लगेगा, लेकिन यह वेब या मोबाइल विकास में अवसरों की एक पूरी नई परत खोल सकता है। कोशिश करने के लिए स्वतंत्र महसूस करो!

संदर्भ

• https://github.com/divan/txqr
• https://github.com/divan/txqr/tree/master/cmd/txqr-tester
• https://github.com/divan/txqr-tester-ios
• https://github.com/divan/txqr-reader
• https://github.com/gopherjs/vecty
• https://github.com/golang/mobile