कई प्लेटफार्मों को लक्षित करने वाले अनुप्रयोगों के विकास के लिए कौन सा दृष्टिकोण अपनाएं?


9

कई प्लेटफार्मों को लक्षित करने वाले अनुप्रयोगों के लिए, मुझे मुख्य रूप से दो विकास दृष्टिकोण दिखाई देते हैं-

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

  • कोर लॉजिक और यूआई को अलग करते हुए मॉड्यूलर कोड बनाएं। संबंधित प्लेटफार्मों के लिए अलग-अलग यूआई विकसित करें जो समान कोर लाइब्रेरी कह रहे होंगे। लक्ष्य प्लेटफार्मों में से प्रत्येक के लिए अलग से आवेदन बनाएँ।

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


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

@ गुलशन क्षमा करें, स्पष्ट प्रश्न - क्या कोई कारण है कि यह वेब एप्लिकेशन नहीं हो सकता है और / या एडोब एयर की तरह कुछ भी किया है?
जेलीफ़िशट्री

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

जवाबों:


3

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

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


2

HTML5 के लिए जाएं। HTML5 ब्राउज़र वाला कोई भी प्लेटफ़ॉर्म आपके एप्लिकेशन को चला सकता है। हालांकि HTML5 अभी बड़े समय के लिए तैयार नहीं है, लेकिन वेब एप्लिकेशन दृष्टिकोण है।


2
एचटीएमएल 5 ब्राउज़रों की कोई विशेषता नहीं है।
क्रेग

2

ऑडेसिटी साउंड एडिटर में हम अपने क्रॉस प्लेटफॉर्म लाइब्रेरी के रूप में wxWidgets का उपयोग करते हैं। चूँकि हमें C पुस्तकालयों से लिंक करने की आवश्यकता है, और हमें एक JVM दृष्टिकोण की गति और निम्न स्तर तक पहुँचने की आवश्यकता नहीं है। GUI कोड सभी प्लेटफार्मों पर 95% समान है। हम छोटे बदलावों के लिए #ifdefs का उपयोग करते हैं। हालाँकि, हमें प्रत्येक तीन प्लेटफार्मों (मैक, विंडोज लिनक्स) पर एक डेवलपर का काम करना आवश्यक लगता है, क्योंकि क्रॉस प्लेटफ़ॉर्म लाइब्रेरी का उपयोग करने पर भी एक मशीन पर बदलाव के लिए दूसरे पर चीजों को तोड़ना बहुत आसान है।

यदि आपको अपनी ज़रूरत का प्रदर्शन मिल सकता है, तो जेवीएम के लिए जाएं। यदि आप नहीं कर सकते हैं, तो qt या wxWidgets का उपयोग करें, और मैं सुझाव दूंगा कि wxWidgets पर क्यूटी है क्योंकि यह कम काम करने के लिए इसे अच्छा लग रहा है।


1
+1 "प्रत्येक प्लेटफॉर्म पर काम करने वाले डेवलपर के लिए आवश्यक है"। यदि आप केवल एक ही समय में एक प्लेटफ़ॉर्म के लिए विकसित होते हैं, तो क्रॉस-प्लेटफ़ॉर्म प्रोजेक्ट जल्दी ही एकल प्लेटफ़ॉर्म बन जाते हैं।
एशेल्ली

2

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

मैंने इसे कई कारणों से इस तरह किया है:

1) प्रत्येक मंच पर इष्टतम प्रदर्शन प्राप्त करने के लिए

2) केवल 1 प्लेटफॉर्म पर दी जाने वाली सुविधाओं का लाभ उठाने के लिए

3) (जे) वीएम कुछ प्लेटफार्मों (एम्बेडेड सिस्टम, गेम कंसोल ...) के लिए मौजूद नहीं था।


2

यह इस बात पर निर्भर करता है कि आपके लिए क्या महत्वपूर्ण है :)

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

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

यदि यूआई वास्तव में आपके लिए महत्वपूर्ण है, तो मुझे संदेह है कि आपको प्रत्येक प्लेटफ़ॉर्म पर सही दिखने वाली चीज़ों का निवेश करने में बहुत समय लगाना होगा, चाहे आप क्यूटी का उपयोग करें या अपना खुद का रोल करें। एक आंतरिक या विशेषज्ञ ऐप के लिए जहां उपयोगकर्ता कम पॉलिश वाले UI को अधिक स्वीकार कर सकते हैं, यह ठीक हो सकता है!


1

हर कोई जावा जैसे भाषाओं के बारे में एक बड़ा उपद्रव करता है जैसे कि "क्रॉस प्लेटफॉर्म", लेकिन जो वे वास्तव में बात कर रहे हैं वह यह है कि आप एक बार संकलन कर सकते हैं और हर जगह चला सकते हैं । यहां तक ​​कि जावा (या सी # / मोनो) जैसी भाषा में भी आपको कुछ क्षेत्रों में ओएस विशिष्ट विवरण से निपटने के लिए अमूर्त परतों की आवश्यकता होगी।

सी ++, और वास्तव में अधिकांश भाषाएं, क्रॉस प्लेटफॉर्म हैं, आपको बस प्रत्येक प्लेटफॉर्म को लक्षित करने के लिए संकलन करना होगा।

वे उपकरण / भाषाओं के बजाय प्रक्रिया महत्वपूर्ण है:

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

ये चरण वही हैं जो आपके द्वारा उपयोग की जाने वाली भाषा / टूलसेट / फ्रेमवर्क के समान नहीं हैं।


1

वेब का लाभ!

गंभीरता से, यदि आप अपने हिरन के लिए सबसे धमाकेदार चाहते हैं, तो एक वेब एप्लिकेशन लिखें।

क्यों?

  • वेब क्लाइंट को आमतौर पर ज्यादा पीसी पावर की आवश्यकता नहीं होती है।
  • वेब क्लाइंट हर व्यक्ति हैं। न केवल पीसी / मैक / लिनक्स, बल्कि फोन, मोबाइल उपकरणों, और अधिक पर।
  • उपयोगकर्ताओं के लिए डाउनलोड करने के लिए कुछ भी अतिरिक्त नहीं! (आमतौर पर, जब तक आप कुछ फैंसी और फ़्लैश, या सिल्वरलाइट का उपयोग नहीं करते हैं)
  • सभी सामान्य घटक सर्वर की तरफ हैं, और आपके पास मौजूद घटकों में से एक जावा, .NET, PHP, या मौजूदा घटकों के समूह का एक हॉज हो सकता है। ग्राहक की परवाह नहीं करनी चाहिए!

यहां तक ​​कि आपके द्वारा बताए गए दो दृष्टिकोण बहुत समान हैं। वेब ब्राउज़र कई अंतर्निहित आर्किटेक्चर के लिए HTML का प्रतिपादन करता है। इसी तरह, जेवीएम जावा कोड की व्याख्या इस तरह करता है जो अंतर्निहित हार्डवेयर के लिए समझ में आता है। वेब, हालांकि, बस एक व्यापक ग्राहक आधार है!


0

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


आप यूआई क्या उपयोग करते हैं, या क्या आप सर्वर-आधारित ऐप्स के लिए हैं? मैं उत्सुक हूं क्योंकि मेरे पास Winforms का उपयोग करके एक काम करने वाला ऐप है, और मैंने मोनो को पोर्ट किया है और यह अच्छा है, लेकिन "वास्तविक" winforms की तरह काम करने के लिए एक बड़ी मात्रा में ले जाएगा। शायद GTK # बेहतर है? मोनोडेवलप अच्छा है, लेकिन शायद थोड़ा क्लंकी है।
5:30 बजे डैन रोसेनस्टार्क

मोनो के साथ दोनों दृष्टिकोणों का पालन किया जा सकता है। यार की तरह, आप किसका अनुसरण कर रहे हैं और क्यों? यह सवाल है।
गुलशन

हाँ, मुझे नहीं पता था कि आप प्लेटफ़ॉर्म के बीच सही रूप निष्ठा की तलाश कर रहे थे। आपको यह GTK # के साथ मिल सकता है, लेकिन आप इसे "सुंदर," की कीमत पर प्राप्त करेंगे, क्योंकि इस तरह के एक सामान्य टूलकिट को "सबसे कम आम भाजक" के लिए जाना होगा। मैं StartClass0830 के साथ सहमत होने के लिए इच्छुक हूं: एचटीएमएल 5 बहुत काम होगा, लेकिन आप इसके साथ कुछ बहुत अच्छा क्रॉस-प्लेटफ़ॉर्म चीजें कर सकते हैं।
रॉबर्ट हार्वे

0

पहले अवधारणा का प्रमाण दें।

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

आपको जिस भाषा की ज़रूरत है, उसकी भाषा सुविधाएँ और लाइब्रेरी यह निर्धारित करने जा रही हैं कि आप किस भाषा को चुनेंगे (और इस तरह, आप क्रॉस-प्लेटफ़ॉर्म के पास कैसे जाएँगे)


0

मैंने एक सिस्टम बनाया, जिसकी शुरुआत 15 साल पहले एक डेस्कटॉप ऐप से हुई थी, जब जावा अभी भी अपनी शैशवावस्था में था और इस तरह के ऐप बनाने में इस्तेमाल के लिए तैयार नहीं था। मुझे पता था कि मुझे C ++ में एक कोर की आवश्यकता है और इसे शुरू से क्रॉस प्लेटफॉर्म पर डिज़ाइन किया गया है, जिसमें आकार प्रकार (जैसे int32 या int के बजाय int32) का उपयोग करना शामिल है, इसलिए यह Mac, Windows और UNIX (प्री-लिनक्स) पर चल सकता है दिन)।

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

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

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

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

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

- एलेक्स


JVM रनटाइम लाइब्रेरी बैकवर्ड कॉम्पिटिबिलिटी के मामले में बहुत स्थिर साबित हुई है। इस परिदृश्य के लिए यह बहुत अच्छी तरह से फिट होता ...

0

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

अन्यथा, जावा या क्यूटी + सी ++ या सी + डब्ल्यूएक्स सभी के लिए एक स्रोत के लिए संभावित विकल्प हैं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.