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

बिल्ली के पीछे बहुत सारे पाठ और आँकड़े हैं।

Apps4All फोरम पर मेरी बात। पहले प्रदर्शन, सामग्री की आपूर्ति में सभी त्रुटियां पहले ही मूंछों के आसपास घाव कर चुकी हैं।

समस्याओं का हल

समस्याओं का पहला समूह उत्पाद समस्याएं हैं।

लोग आम तौर पर क्रॉस-प्लेटफॉर्म विकास पर क्यों जाते हैं? वह किस लिए है? आइए समस्याओं की एक सूची एकत्र करने का प्रयास करें जो प्रत्येक प्लेटफ़ॉर्म के लिए अलग से लिखने पर उत्पन्न होती हैं।

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

प्रबंधन की कोई समस्या नहीं है:

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

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

समस्याओं का दूसरा समूह विकास उपकरण है।

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

समस्याओं का तीसरा समूह - जीयूआई प्लेटफार्मों में अंतर

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

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

हालांकि, चलो दोनों तरीकों के पेशेवरों और विपक्षों पर प्रकाश डालने की कोशिश करते हैं:

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

यहाँ से क्या निष्कर्ष निकाला जा सकता है? हमें अपने लिए उत्पाद जारी करने के लिए नहीं, बल्कि उपयोगकर्ता के लिए, हमारे पास एक टूलबॉक्स होना चाहिए जो हमें प्रत्येक प्लेटफ़ॉर्म के लिए अलग से UI लिखने की अनुमति देता है।

एक विकास उपकरण चुनने की कोशिश कर रहा है

इसलिए, धमनियों का चयन किया जाता है:

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

प्लेटफ़ॉर्म टूल श्रेणियाँ पार करें

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

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

आइए, विचार करें, शायद, सभी आंकड़े नहीं, लेकिन केवल एक है जो ज़ामरीन कंपनी के बारे में बात करता है, क्योंकि पूर्ण आँकड़े 40 पृष्ठ लगते हैं और पढ़ने और समझने के लिए दोनों व्यापक हैं। सभी लोग पूर्ण आंकड़े पढ़ सकते हैं, लेकिन व्यक्तिगत रूप से, मेरे निष्कर्ष नीचे और संक्षेप में हैं।

मान्यता

डेवलपर और ग्राहक दोनों के लिए पर्याप्त रूप से महत्वपूर्ण कारक यह मान्यता है कि इसका क्या उपयोग किया जाएगा। डेवलपर के लिए मान्यता महत्वपूर्ण है क्योंकि काम की तलाश में नियोक्ता के साथ एक चर्चा में प्रवेश करना आसान है, और वे अक्सर फिर से शुरू में देखेंगे। और ग्राहक के लिए, टूलबॉक्स की मान्यता महत्वपूर्ण है, क्योंकि जब एक ठेकेदार चुनते हैं, तो सावधानीपूर्वक ग्राहक कंपनी की सेवाओं में परिचित अक्षरों की तलाश करेगा। यदि एक ही समय में वह इंटरनेट पर खोज करने के लिए बहुत आलसी नहीं था, जिसका अब उपयोग किया जा रहा है, तो यदि आप उपयोग किए गए उपकरण के रूप में बाईं ओर कॉलम के सेट से कुछ का नाम लेते हैं, तो इससे सहयोग शुरू करने की संभावना बढ़ जाएगी। जैसा कि आप देख सकते हैं, अभी सबसे पहचानने योग्य हैं Adobe Air, Phone Gap, Xamarin, jQuery Mobile, Unity और Titanium। इन प्लेटफार्मों में, Adobe बाहर खड़ा है। शायद यह मुख्य रूप से कंपनी एडोब की प्रसिद्धि के कारण है। हालाँकि, प्लेटफ़ॉर्म की पूरी श्रृंखला केवल उसके, ज़मीरिन और यूनिटी 3 डी द्वारा कवर की गई है। इसके अलावा, एकता एक गेमिंग प्लेटफॉर्म है और सामान्य अनुप्रयोगों के लिए तेज नहीं है। और खेल के लिए - वह नंबर एक है। हालांकि, व्यावसायिक अनुप्रयोगों के लिए, विकल्प इस तरह से जाता है: यदि हम वेब फ्रेमवर्क चुनते हैं, तो आपको अधिक विस्तार से देखने की आवश्यकता है। यदि क्रॉस-प्लेटफॉर्म आईडीई है, तो इस श्रेणी में केसमरिन जीतता है।

पहले से ही विकास में उपयोग किया जाता है

दूसरा महत्वपूर्ण आँकड़ा: कितने लोग पहले से ही विकास में टूलसेट का उपयोग करते हैं।

© research2guidance

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

फोनगैप - २००५ (~ ३१%)
एडोब एयर - 2008 (~ 17%)
एकता 3 डी - 2008 (iPhone / iPad) - (~ 13%)
टाइटेनियम - 2008 (~ 13%)
jQuery मोबाइल - 2010 (~ 28%)
सेन्चा - 2010 (~ 12%)
मार्मेलेड - 2011 (~ 12%)
ज़ामरीन - 2011 (~ 12%)
क्यूटी निर्माता - 2012 (मोबाइल नहीं) (~ 14%)

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

jQuery (8 वर्षों में PhoneGap के रूप में लगभग 3 वर्षों में)
मरमेलडे और ज़ामरीन (2 वर्षों में मजबूत वृद्धि)

लेकिन हमारी धमनियों को याद करते हुए, हमें एहसास होता है कि न तो jQuery और न ही Marmelade हमें सूट करता है। न तो पहला और न ही दूसरा प्लेटफॉर्म सुविधाओं तक पहुंच प्रदान करता है, जो हमारे लिए महत्वपूर्ण है। और इस श्रेणी में ज़मारिन है।

विकास प्रदर्शन

© research2guidance

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

खैर, अंतिम आरेख: यदि मैंने अभी भी क्रॉस-प्लेटफ़ॉर्म टूल का उपयोग करने के लिए आंदोलन नहीं किया है

© द्वारा अनुसंधान 2guidance

ऊर्ध्वाधर अक्ष सर्वेक्षण में शामिल लोगों के प्रतिशत को दर्शाता है, और क्षैतिज अक्ष प्रश्न के उनके उत्तर को दर्शाता है: क्रॉस-प्लेटफॉर्म विकास कितनी तेजी से / धीमा हुआ, आपका समय था? तदनुसार, बहुमत ने जवाब दिया कि वे त्वरित हो गए थे और एक छोटा - कि वे धीमा हो गए थे।

ज़मारिन प्लेटफार्म के बारे में

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

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

मुख्य समस्या प्रत्येक प्लेटफ़ॉर्म के लिए प्लेटफ़ॉर्म एपीआई को अग्रेषित करना है।

जावा की अपनी आभासी मशीन है, क्योंकि जेवोस्का कई मापदंडों से संतुष्ट नहीं है, जिनके बीच ईमानदार जेनरिक (जिस पर बाद में चर्चा नहीं की जाएगी), और आईओएस C # से ओब्ज-सी को प्राप्त तैयार असेंबलियों के अनुवाद का उपयोग करता है। हमारे पास आउटपुट में क्या है?

प्रोग्रामिंग भाषाओं की एक बड़ी संख्या जिसमें आप क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन लिख सकते हैं। इनमें C #, VB.NET, Boo, Nemerle, JavaScript शामिल हैं।
रिच इन्फ्रास्ट्रक्चर। नेट फ्रेमवर्क, और पहले से ही लिखे गए पुस्तकालयों की एक अविश्वसनीय संख्या। नेट और जीथब, कोडप्लेक्स, और अन्य, आदि के रिपॉजिटरी में आपके लिए इंतजार कर रहा है।
Android और ios के साथ किसी भी मौजूदा पुस्तकालयों का उपयोग करने की क्षमता;
इस समय सबसे लोकप्रिय प्रोग्रामिंग भाषा का व्यापक समुदाय - C # आपके प्रश्नों को अनुत्तरित नहीं छोड़ेगा।
एक स्थिर विकास टीम, उनके उत्पाद के साथ प्यार में, और एक तेजी से बढ़ते समुदाय (वर्तमान में लगभग 500,000 पंजीकरण हैं और यह संख्या रुकने के लिए नहीं सोचती है)
प्रोग्रामर के कर्मचारियों को कम करना और प्रोग्रामर को अन्य प्लेटफार्मों से किराए पर लेने की क्षमता। उदाहरण के लिए, विंडोज प्रोग्रामर C # से परिचित हैं।
अंतिम उत्पाद को विकसित करने की लागत को कम करना और, तदनुसार, अधिक इच्छुक ग्राहक।

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

यह C # सीखने लायक क्यों है?

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

समानांतर कोड के निष्पादन के लिए प्रथम श्रेणी की भाषा का समर्थन सब कुछ बदल देता है, जो पहले कार्यान्वयन में उबाऊ और बुरा था, जिसने बड़ी संख्या में संभावित त्रुटियों को जन्म दिया, आसान-कोड बनाए रखने में स्थान। और अगर आप इसे स्वचालित प्रकार के आक्षेप, लैम्ब्डा अभिव्यक्तियों, LINQ भाषा और भाषा की अन्य अच्छाइयों से जोड़ते हैं, तो प्रोग्रामिंग एक बहुत ही सुखद प्रक्रिया में बदल जाती है, जिसके लिए आप नोटिस नहीं करते कि समय कैसे उड़ता है;
समृद्ध विशेषताएं - ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग और इनकैप्सुलेशन, कोड को अधिकतम पुन: उपयोग के लिए संरचना करना बहुत आसान बनाते हैं। और निर्भरता के परावर्तन और इंजेक्शन जैसी विशेषताएं अनुप्रयोगों की व्यापकता और लचीलेपन के लिए वास्तव में समृद्ध अवसर प्रदान करती हैं;
उन्नत रनटाइम । डेवलपर के कंधों से एप्लिकेशन मेमोरी के प्रबंधन के बोझ को हटाकर कचरा संग्रह विकास को बहुत सरल करता है। डेवलपर्स पॉइंटर्स के साथ संघर्ष करने और मेमोरी लीक को नियंत्रित करने के बजाय एल्गोरिथम और अन्य समस्याओं को हल करने पर ध्यान केंद्रित कर सकते हैं;
एक जोरदार टाइप की गई भाषा के रूप में , C # अधिकांश संकलन प्रकार की जाँच करता है, जो कष्टप्रद त्रुटियों की संख्या को कम करता है और इस प्रकार विकास को गति देता है।
अनुकूल करने के लिए आसान है । C # एक बहुत ही सरल भाषा है और इसकी आदत डालना बहुत आसान है। लेकिन अगर आप के लिए उपयोग किया जाता है, तो इससे बाहर निकलना बहुत मुश्किल होगा, मेरा विश्वास करो। और अगर आप इस सामग्री की एक पागल राशि को जोड़ते हैं, जो हर जगह बस अच्छी तरह से झूठ बोलती है, तो यह किसी भी नौसिखिया डेवलपर को गारंटी देता है कि वह कभी भी एक जगह फंस नहीं जाएगा।
तेजी से निष्पादन । IOS पर C # अनुकूलन करने वाले LLVM कंपाइलर का उपयोग करता है, जिसका उपयोग C और C ++ भाषाओं द्वारा किया जाता है, जिस पर ऑपरेटिंग सिस्टम आधारित है, जो आपको दोनों दुनिया का सर्वश्रेष्ठ देता है: C # प्रोग्रामिंग की उच्च उत्पादकता और निम्न-स्तरीय प्रोग्रामिंग भाषाओं की उच्च दक्षता। एंड्रॉइड पर, चीजें बदतर नहीं हैं: सी # जावा की तुलना में भी बेहतर काम करता है। इसे कई तरीकों से समझाया जा सकता है: C #, जावा द्वारा, जेनेरिक के विपरीत मान प्रकार, वास्तविक तरीकों का समर्थन करता है, और डिफ़ॉल्ट रूप से आभासी नहीं। , , Dalvik — Mono Runtime.
, , , , .
: . mono, , 2,2 . . .

, , , … . . . , . . . - , iOS, Windows Phone. , UI . , . , , .

विपक्ष

. , , , . -, , . , , , .

Xamarin Studio — IDE, . , , , ,
bindings . , , , binding. , :
. , Java/Obj-C, Java, , Garbage Collector'a. ! ! , . , — . - C++. . .

, , , MVVM, - UI . 80%. .

, , , iOS . , , Windows. . Visual Studio, , JetBrains, ReSharper Windows, -, Visual Studio.
Visual Studio , Xamarin . IDE Xamarin Studio, MonoDevelop 4.0 , .
आप Xamarin Studio का उपयोग करके मैक के तहत भी विकास कर सकते हैं। हमारी पूरी कंपनी बस यही करती है। हम विंडोज का उपयोग केवल WinPhone कनेक्शन के लिए करते हैं।

Xamarin पर क्रॉस-प्लेटफॉर्म विकास