मोबाइल एप्लिकेशन के लिए डू-इट-ही-क्लाउड क्लाउड एपीआई। भाग 1

ज्वाइन करने के बजाय

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

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

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

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

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

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

मैं यह सब क्यों हूँ?

मैं खुद लंबे समय से सवाल से परेशान हूं, लेकिन मैं आवेदन के लिए अपने सर्वर बैकएंड को कैसे व्यवस्थित कर सकता हूं। सबसे पहले मैंने WCF सेवाओं का उपयोग करके अपना खुद का कुछ लिखा। फिर ASP.NET वेब एपीआई आया, जिसने जीवन को बहुत सरल बना दिया। लेकिन आज मैं कुछ और के बारे में बताना चाहता हूं। आसानी से उपयोग की जाने वाली चीजों के प्रशंसक के रूप में, मैं अपेक्षाकृत नई सेवा से आगे नहीं निकल सका, जो विंडोज एज़्योर क्लाउड प्लेटफॉर्म में दिखाई दी। इस सेवा का नाम Windows Azure Mobile Services Custom API है।

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

इस भाग में आगे मैं विंडोज एज़्योर में क्लाउड बैकएंड का उपयोग करने और बनाने और इसे मोबाइल डिवाइस से एक्सेस करने के तरीके के बारे में बात करना चाहता हूं। स्विच मत करो!

क्लाउड बैकएंड बनाना

क्लाउड बैकएंड बनाना, विंडोज एज़्योर में किसी भी अन्य सेवा की तरह, क्लाउड प्रबंधन पोर्टल से आता है। सबसे पहले आपको एक मोबाइल सेवा बनाने की जरूरत है, जो किसी प्रकार के नाम के साथ आ रही है:


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

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


इसे याद रखें, यह आगे भी हमारे लिए उपयोगी होगा।

एपीआई निर्माण

अपना पहला क्लाउड API बनाने के लिए, बस API टैब पर जाएं और Create a Custom API बटन पर क्लिक करें:


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


एक बार नया API बन जाने के बाद, हम इसे संपादित करना शुरू कर सकते हैं। प्रारंभ में, आपको इसके समान एक स्क्रिप्ट देखनी चाहिए:


शैक्षिक / परीक्षण उद्देश्यों के लिए, मैं इसे इस तरह प्राप्त करने के लिए इसे थोड़ा बदलने का सुझाव देता हूं:


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

एपीआई का उपयोग

इस लेख के लिए, हम परीक्षण एप्लिकेशन का उपयोग करेंगे जो Windows Azure मोबाइल सेवा कृपया हमें प्रदान करती है। ऐसा करने के लिए, त्वरित बनाएं पृष्ठ पर वापस जाएं (यह आइकन पर बादल और बिजली के साथ एक है), विंडोज फोन 8 का चयन करें (हालांकि अमीर चयन पर ध्यान दें) और एक नया विंडोज फोन ऐप बनाएं पर क्लिक करें:


आवश्यक प्लेट बनाने (टोडोइएटम) बनाने और डाउनलोड बटन का उपयोग करके एप्लिकेशन डाउनलोड करने के बाद, इसे विज़ुअल स्टूडियो में खोलें।

सबसे पहले, हम दो चीजों में रुचि रखते हैं। App.xaml.cs फ़ाइल में इसके समान एक पंक्ति है:

public static MobileServiceClient MobileService = new MobileServiceClient( "https://mva-test-api.azure-mobile.net/", "___" ); 

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

चलो एप्लिकेशन चलाते हैं और कम से कम यह देखते हैं कि यह कैसा दिखता है:


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

 //   POST var result = await App.MobileService.InvokeApiAsync("CoolAPI", null, HttpMethod.Post, null, null); Debug.WriteLine(result.StatusCode); var stringData = await result.Content.ReadAsStringAsync(); Debug.WriteLine(stringData); //   GET var resultJson = await App.MobileService.InvokeApiAsync("CoolAPI", HttpMethod.Get, null); Debug.WriteLine(resultJson); 

इस कोड में मुख्य विधि को InvokeApiAsync कहा जा सकता है। वह एपीआई पद्धति को कॉल करने के लिए जिम्मेदार है। यह पद्धति ओवरलोडेड है और मापदंडों के एक अलग सेट के साथ संपन्न है। उदाहरण से पता चलता है कि POST के मामले में, हम 5 के रूप में कई मापदंडों से गुजरते हैं, और GET के मामले में, केवल 3. यह इस तथ्य के कारण है कि POST के लिए विधि सामान्य स्ट्रिंग में परिणाम के लिए डिज़ाइन की गई है (बैकएंड पर स्क्रिप्ट के कार्यान्वयन को याद रखें), और GET के साथ विकल्प - JSON ऑब्जेक्ट के साथ काम करने के लिए (परिणाम Newtonsoft.Json होगा)।

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

वे कैसे हैं?

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

 [self.client invokeAPI:@"CoolAPI" data:nil HTTPMethod:"POST" parameters:nil headers:nil completion:^(NSData *result, NSHTTPURLResponse *response, NSError *error) { NSLog(@"%i", response.statusCode); NSString *stringData = [[NSSatring alloc] initWithData:result encoding:NSUTF8StringEncoding]; }]; 

जैसा कि आप देख सकते हैं - एक "साफ" ObjectiveC, धोखाधड़ी के बिना। इसी तरह Android, WinRT, और यहां तक ​​कि वेब संस्करण (HTML और JavaScript में) के लिए भी।

आगे क्या है

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