मुझे लगता है कि यह समुदाय के लोगों के लिए मददगार है यदि Xamarin.Forms टीम Xamarin.Forms आर्किटेक्चर, डिज़ाइन सिद्धांत और इसके वर्कफ़्लो के बारे में Github या MS डॉक्स में अधिक दस्तावेज़ लिखती है।
मेरे दृष्टिकोण से, मैं अपने उत्पादों को बनाने के लिए Xamarin.Forms का उपयोग करता हूं, जब मैं बग्स को पूरा करता हूं तो मेरे पास 2 विकल्प होंगे, एक जीथब को जारी करना है और प्रतीक्षा करना किसी दिन के लिए तय किया जाएगा और दूसरा जीथब को जारी करना है और इसे अपने आप से ठीक किया।
क्लोन सोर्स कोड और इसे डीबग करने के बाद, यह समझना मुश्किल है कि सुविधाएँ कैसे काम करती हैं। उदाहरण के लिए https://github.com/xamarin/Xamarin.Forms/issues/8521
एक अन्य उदाहरण एंड्रॉइड साइड पर Xamarin.Forms का पेज नेविगेशन फीचर है। नेटिव एंड्रॉइड पर गतिविधियों के बीच नेविगेशन सुविधा को समझना आसान है। लेकिन Xamarin.Forms पर ऐसा लगता है कि यह सभी पेज (शायद) (मूल रूपों और मूल दृश्य को छोड़कर) को संभालने के लिए एक मुख्य गतिविधि का उपयोग करता है।

मुझे लगता है कि यह बहुत अच्छा है।

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

उन सबसे समस्याग्रस्त चीजों में से एक में कई अलग-अलग संस्करण हैं जहां बग्स को ठीक किया गया है या सुविधाओं को पेश किया जा रहा है और फिर जब सुधार किया जा रहा है।
कई छोटे उदाहरण होने से इससे बहुत मदद मिलती है।

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

सबसे अच्छा होगा यदि छोटे नियंत्रण-गैलरी-पुर्ज़े उन परियोजनाओं के रूप में उपलब्ध हो सकते हैं जो अलग से उपलब्ध हैं और केवल कोडस्पेस में खोले जा सकते हैं। मैं छोटे नियंत्रण-ऐप्स और कोडस्पेस के संयोजन में बहुत लाभ देख सकता हूं।

मुझे लगता है कि मैं जो कहने की कोशिश कर रहा हूं वह है:

• मल्टीपार्ट-कंट्रोल-गैलरी
• कोडस्पेस समर्थन
• डॉटफाइल्स इन इश्यू

संपादित करें: तीसरा बिंदु जोड़ा गया।

मैं सहमत हूं कि मेरे पास कुछ मुद्दे महीनों से खुले हुए हैं। मैंने एक्सएफ क्लोन किया है लेकिन इसमें खो गया है।
तो वीडियो के लिए एक डॉक्टर सिर्फ यह दिखा रहा है कि समाधान कैसे काम करता है, यह बहुत अच्छा होगा।

अधिक .Netty यह बेहतर हो सकता है।

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

एक बिंदु पर हम एक सरलीकृत SLN उपयोगकर्ता होने की दिशा का परीक्षण कर रहे थे जो इसे पसंद करने में योगदान कर सकते हैं

https://github.com/PureWeen/Xamarin.Forms.Sandbox

बस एक बहुत ही लक्षित "Contributor.sln" प्रदान करें जहां योगदानकर्ता एक फिक्स या एक एपीआई प्रदर्शित कर सकते हैं

सभी मौजूदा दीर्घाओं को हटा दें और इसे केवल प्लेटफॉर्म और एक मुख्य पृष्ठ पर केंद्रित करें

क्या सॉल्यूशन फ़िल्टर बेहतर होगा? आपको दो समाधान बनाए रखने की आवश्यकता नहीं है।

हम देखेंगे कि समाधान फ़िल्टर के साथ क्या विकसित होता है

AFAIK वर्तमान में वे vsmac पर काम नहीं करते हैं और जब आपके पास बहु लक्षित परियोजनाएं होती हैं तो वे थोड़ा अजीब होते हैं। एक बार जब हम बहु लक्ष्यीकरण के लिए प्रथम श्रेणी का समर्थन प्राप्त कर सकते हैं और मुख्य परियोजनाएं केवल एसडीके शैली हो सकती हैं तो मुझे लगता है कि समाधान फ़िल्टर की आवश्यकता उतनी अधिक नहीं है।

दूसरी कष्टप्रद बात यह है कि विंडोज़ के लिए वीएस वर्तमान में सभी लक्ष्य बनाता है जब आपके पास बहु लक्ष्यीकरण होता है जबकि बनाम मैक आपके द्वारा चलाए जा रहे प्लेटफ़ॉर्म हेड के लिए केवल एक बनाता है।

दूसरी कष्टप्रद बात यह है कि विंडोज़ के लिए वीएस वर्तमान में सभी लक्ष्य बनाता है जब आपके पास बहु लक्ष्यीकरण होता है जबकि बनाम मैक आपके द्वारा चलाए जा रहे प्लेटफ़ॉर्म हेड के लिए केवल एक बनाता है।

विंडोज़ के लिए वीएस में इसके लिए समर्थन प्राप्त करना बहुत अच्छा होगा! मैं इन सभी अतिरिक्त कॉन्फिग से छुटकारा पा सकता था जो मैंने केवल उस प्लेटफॉर्म को बनाने के लिए किया था जिसके साथ मैं इस समय काम कर रहा हूं।

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