आइए इस बातचीत को गुनगुनाएं, क्योंकि हमें वास्तव में आपसे, हमारे डेवलपर्स के समुदाय से सुनने की जरूरत है!

सबसे पहले, धन्यवाद @jassmith ने इसे पकड़ने के लिए

मैं अपने कुछ विचार साझा करने जा रहा हूं, कुछ मूर्खतापूर्ण प्रश्न पूछूंगा, और कुछ उम्मीद से नहीं-अति-प्रमुख प्रश्न पूछूंगा। Xamarin.Forms के प्रोग्राम मैनेजर के रूप में मुझे अक्सर इस तरह से प्रश्न पूछने पड़ते हैं कि ऐसा लगता है कि मेरे पास कोई सुराग नहीं है (कभी-कभी मैं नहीं करता), लेकिन वास्तव में मुझे सिर्फ आपसे बातें सुनने की जरूरत है अपने मुंह में शब्द डालना।

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

मुझे भी आरक्षण है।

मैं शैल अवधारणा और डेवलपर अनुभव के बारे में विचार के कुछ सामान्य सूत्र के साथ यहां शुरुआत करूंगा।

ऐप अनुभव

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

यदि मैं शीर्ष स्तर पर अपने आवेदन का वर्णन करने के लिए इस दृष्टिकोण का उपयोग करता हूं, तो मुझे मिलता है:

• हर प्लेटफॉर्म पर समान दिखने के लिए थीम वाला ऐप
• सामग्री डिजाइन (इस मामले में) डिफ़ॉल्ट रूप से पैटर्न
• कॉन्फ़िगरेशन के साथ सक्षम नवीनतम नेविगेशन पैटर्न
• मुझे आईओएस और एंड्रॉइड और यूडब्ल्यूपी पर समान दिखने के लिए एंट्री या बटन को अनुकूलित करने के लिए श्रम करने की आवश्यकता नहीं है?

क्या यह सही है? अन्य लाभ जिन पर मुझे प्रकाश डालना चाहिए?

App बजाय मेरे पास MaterialShell । इसका लाभ उठाने के लिए मुझे एक नया शीर्ष स्तरीय एप्लिकेशन प्रतिमान सीखने/अपनाने की आवश्यकता है?

एक बार जब मैं अपने ऐप में आ जाता हूं, तो मैं ContentPage भूमि में वापस आ जाता हूं, है ना? लेकिन मेरे सभी Button s और Entry s भौतिक और सुंदर हैं। क्या मैं अभी भी OnPlatform और किसी अन्य प्लेटफॉर्म पर अलग दिखने (या व्यवहार) को अलग करना पसंद कर सकता हूं?

इस "खोल" का उपयोग करने के लिए मौजूदा ऐप से मेरा माइग्रेशन पथ कैसा दिखता है? मैं नया MaterialShell करता हूं, वर्णन करता हूं कि मैं कैसे चाहता हूं कि मेरा ऐप संरचना और दिखने वाला हो, और नई अच्छाई देखने के लिए इसे चलाएं?

अनुकूलित

मेरे विकल्प क्या हैं यदि मुझे Flyout या मेनू आइटम दिखने का तरीका पसंद है, लेकिन मुझे अपने डिज़ाइनर कंप्स से मेल खाने के लिए उन्हें ट्विक करने की आवश्यकता है? मैं किस बिंदु पर कह रहा हूं "उह, मुझे यह सब खुद करना चाहिए था" और जो मेरे पास है उसे मानक Xamarin.Forms ऐप संरचना में ले जा रहा है?

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

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

समस्या

मैं इस पहली टिप्पणी को पढ़ने वाले सभी लोगों के लिए कुछ प्रश्नों के साथ समाप्त करूंगा।

• क्या यह समस्या है कि यह प्रस्ताव अच्छी तरह से परिभाषित करने का प्रयास करता है?
• क्या यह एक समस्या है जिसे आप साझा करते हैं?
• जैसा कि आप इस विनिर्देश को पढ़ते हैं, पिछली परियोजनाओं में आपको किन समस्याओं का सामना करना पड़ा है, क्या आपको लगता है कि यह आपके लिए हल करेगा?

यदि संभव हो, तो स्क्रीनशॉट/डिज़ाइन छवियां और भी बेहतर बनाएंगी।

इसे भी देखें:

http://www.noesisengine.com/webgl/Samples.Buttons.html

@jassmith यह बहुत अच्छा होता अगर पूरे विचार को छवियों के रूप में प्रस्तुत किया जाता। विनिर्देशों को ऊपर रखने के प्रयास के लिए यश। मेरे प्रश्न सही नहीं हो सकते हैं।

मेरे प्रश्न हैं

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

क्या इसमें फ़्लोटिंग लेबल/प्लेसहोल्डर के साथ-साथ त्रुटि संदेशों का समर्थन करने के लिए TextInputLayout जैसा कुछ भी शामिल होगा? यदि हां, तो मुझे लगता है कि Binding को wpf के समान 'ValidateOnDataErrors' को शामिल करने के लिए बढ़ाया जाना चाहिए।

इसका मेरा कार्यान्वयन यहां देखें
https://github.com/XamFormsExtended/Xfx.Controls/blob/develop/src/Xfx.Controls/XfxBinding.cs

इसके अलावा, मुझे आश्चर्य है कि क्या मटेरियलशेल को शेल का विस्तार करना चाहिए ताकि कोई आईओएस लुक और फील के लिए ह्यूमनइंटरफेसशेल बना सके।

@ChaseFlorell जो मेरी टिप्पणी भी होने वाली थी। सामग्री बहुत अच्छी है, लेकिन यह एक और बात है अगर हम विशेष UI आवश्यकताओं के अनुरूप अपने स्वयं के गोले लिखना चाहते हैं।

@davidortinau , @jassmith ,

इस युक्ति को एक साथ रखने और हमें प्रतिक्रिया देने की अनुमति देने के लिए धन्यवाद।

क्या यह समस्या है कि यह प्रस्ताव अच्छी तरह से परिभाषित करने का प्रयास करता है?

हां। नेविगेशन सिस्टम पूरी तरह से ज़ामरीन फॉर्म में विकसित नहीं हुआ है, इसलिए इसे कैसे पूरा किया जाए, या इसे पूरी तरह से दरकिनार करने का एक खुला अंत मुद्दा है।

क्या यह एक समस्या है जिसे आप साझा करते हैं?

हां।

जैसा कि आप इस विनिर्देश को पढ़ते हैं, पिछली परियोजनाओं में आपको किन समस्याओं का सामना करना पड़ा है, क्या आपको लगता है कि यह आपके लिए हल करेगा?

मैं इस प्रश्न का उत्तर यह कहकर दे रहा हूं कि मुझे नहीं लगता कि इससे समस्याओं का समाधान होगा। हमारी विशेष समस्या यह है कि वर्तमान नेविगेशन प्रणाली बहुत कठोर है, ऐसा नहीं है कि यह पर्याप्त कठोर नहीं है। हमारे लिए सबसे स्पष्ट उदाहरण TabbedPage है। कोई TabbedView दृश्य नहीं है, इसलिए यदि हम अपने ऐप में टैब चाहते हैं, तो हमें TabbedPage का उपयोग करना चाहिए। इसलिए, पूरी स्क्रीन को TabbedPage द्वारा लिया जाना चाहिए और हम स्वयं के बटन, या अन्य नियंत्रणों के लिए अचल संपत्ति का उपयोग नहीं कर सकते हैं जिन्हें हम स्क्रीन पर रखना चाहते हैं। मेरा सुझाव है कि पेजों में कार्यक्षमता को फिर से उच्च स्तर पर ले जाने के बजाय _आउट ऑफ_ पेज और डाउन टू व्यू में अधिक कार्यक्षमता को स्थानांतरित किया जाए।

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

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

दूसरी बात जो मैं कहूंगा वह यह है कि यह ढांचा अन्य एक्सएएमएल प्लेटफार्मों में अभूतपूर्व दिखता है, और मैं कहूंगा कि प्राथमिकता नए ढांचे को प्रदान करने के बजाय प्लेटफार्मों में मानकीकरण प्रदान करने पर होनी चाहिए जो अन्य प्लेटफॉर्म के अनुकूल नहीं होंगे। हम वर्तमान में तीन प्लेटफार्मों के लिए निर्माण कर रहे हैं: सिल्वरलाइट, Xamarin.Forms, और WPF। हमें कम विचलन पैदा करने के लिए उन प्लेटफार्मों में मानकीकरण की आवश्यकता है, अधिक नहीं।

@ डिलनबेरी ,

यह एक और बात है अगर हम विशेष यूआई जरूरतों के अनुरूप अपने स्वयं के गोले लिखना चाहते हैं।

हां। यह मेरी चिंता है। प्रत्येक ऐप के अपने विशेष उपयोग के मामले होते हैं, और अधिक कठोरता इसे कठिन बना सकती है - इन्हें लागू करना आसान नहीं है।

यह चिंता भी है: https://github.com/xamarin/Xamarin.Forms/issues/2452#issuecomment -380991817

मैं उपरोक्त को प्रतिध्वनित करूंगा, साथ ही यह भी पूछूंगा कि इशारों और संकेत irt आकार के आदिम कैसे कार्य करेंगे?

एक सामान्य टिप्पणी यह ​​​​है कि सिस्टम में जोड़े गए कोड की प्रत्येक पंक्ति के लिए, बग्गी कोड जोड़े जाने की 3+ संभावना है। Xamarin प्रपत्रों में पहले से ही बहुत सारे बग हैं जिन्हें ठीक करने की आवश्यकता है। अधिक कोड का अर्थ है कि बग के जोड़े जाने की संभावना तेजी से बढ़ जाती है। और भी बग होंगे। मुझे लगता है कि एक्सएफ टीम को कोड बेस के आकार को बढ़ाने के बजाय उसे कम करने के लिए काम करना चाहिए। बग होने की संभावना को कम करने का एकमात्र तरीका कोड आधार को कम करना है।

मौजूदा बग्स को ठीक करने के बजाय फिर से एक नई चीज़ का आविष्कार क्यों करें और पहले सुनिश्चित करें कि सब कुछ रॉक सॉलिड है?

मेरे लिए, इसे छुआ गया है, लेकिन नेविगेशन Xamarin रूपों में सबसे बड़ी बाधा है और इसने मुझे पिछले तीन वर्षों में सबसे अधिक दिल का दर्द दिया है।

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

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

• पेज पॉप्ड एनिमेशन जैसे ढांचे के सामान को ओवरराइड करने की क्षमता

जो कुछ प्रस्तावित है वह बहुत उपयोगी लगता है, जब तक आप केवल विशिष्ट पृष्ठों में सामग्री खोल का उपयोग कर सकते हैं और यह ऐप चौड़ा नहीं है, यह कोड वास्तव में उपयोगी हो सकता है। यह निश्चित रूप से कुछ ऐसा है जिसका हम उपयोग करेंगे क्योंकि वर्तमान में मैं अपने UX लड़के के लिए "यह Xamarin रूपों की एक सीमा है" कहता रहता है (जैसा कि मैंने अपनी पिछली भूमिका में किया था)। हिम्मत करें कि मैं यह कहूं, हमें यूएक्स परिप्रेक्ष्य से फीडबैक प्राप्त करना चाहिए, जिन्होंने पहले फॉर्म ऐप्स को स्टाइल किया है। यह XamlC की तरह ऑप्ट-इन होना चाहिए।

हालांकि नाम के बारे में निश्चित नहीं है, फ्लेक्सशेल अधिक समझ में आता है ... लेकिन अब हमारे पास फ्लेक्सबॉक्स है (भले ही हमने इसके लिए कभी नहीं पूछा ... क्षमा करें डेविड, खुद की मदद नहीं कर सका 😄)

इसके अलावा, क्या इसका मतलब यह होगा कि विषय एक तरह से मृत हैं? वैसे भी कभी उनका इस्तेमाल नहीं किया।

@मैकायन

यह निश्चित रूप से कुछ ऐसा है जिसका हम उपयोग करेंगे क्योंकि वर्तमान में मैं अपने UX लड़के के लिए "यह Xamarin रूपों की एक सीमा है" कहता रहता है (जैसा कि मैंने अपनी पिछली भूमिका में किया था)।

ठीक है, लेकिन, पूरी तरह से नया बनाने के बजाय वर्तमान कार्यान्वयन को ठीक करने या सुधारने के लिए और अधिक समझ में नहीं आएगा, जो बग और सीमाओं के साथ भी आएगा? यह वहीं कहता है कि:

मटीरियलशेल पॉइंट्स पर एक ओपिनेटेड एपीआई है"

गंभीरता से, ज़ामरीन फॉर्म कितने अलग-अलग दिशाओं में जा सकते हैं? एक्सएफ टीम कम से कम एंड्रॉइड और आईओएस के लिए मौजूदा एक्सएफ कार्यान्वयन को ठीक करने में मुश्किल से सक्षम है, और अब यह? बग फिक्सिंग के बारे में क्या, XAML पूर्वावलोकन को ठीक करना, प्रदर्शन के बारे में क्या?

क्रॉस प्लेटफ़ॉर्म सॉलिड और ग्रेडिएंट ब्रश के लिए सरल लेकिन बहुत उपयोगी समर्थन जोड़ने के प्रस्ताव के साथ किसी के द्वारा एक टिकट खोला गया था, लेकिन @jassmith की प्रतिक्रिया थी कि यह समस्याग्रस्त होगा। लेकिन अब यह टिकट एक ही बात का प्रस्ताव करता है .... वह अब समस्याग्रस्त कैसे नहीं है? जाओ पता लगाओ

@opcodewriter

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

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

@jassmith इसका मतलब यह है कि XF शेल के लिए स्पंदन दृष्टिकोण (मूल नियंत्रण के बजाय एक रेंडरिंग इंजन का उपयोग करके) लेगा?

दोस्तों, कल जेसन और मेरे बीच इस बात पर चर्चा हुई कि इस युक्ति को कैसे बेहतर बनाया जाए और हम एक बड़ा अपडेट करेंगे, हम इसे अलग-अलग मुद्दों में विभाजित कर रहे हैं।

मैं उपरोक्त कुछ भावनाओं को प्रतिध्वनित करना चाहता हूं: कृपया हमारे पास जो कुछ भी है उसमें सुधार करें, जब तक कि आपके पास असीमित संसाधन न हों, तो इसके लिए जाएं

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

आप एक नया काम क्यों शुरू करना चाहेंगे??????

@ टोनी हेनरिक हाँ तस्वीरें बहुत अच्छी होंगी। दुर्भाग्य से मैं एक कलाकार नहीं हूं और मेरे पास उन छवियों के अधिकार नहीं हैं जिनका मैं अपने संदर्भ के लिए उपयोग कर रहा हूं। मुझे उम्मीद है कि कुछ डिज़ाइन टीम के सदस्य के पास कल्पना के लिए उचित चित्र बनाने में मेरी मदद करने का समय होगा।

@muhaym

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

@ChaseFlorell नहीं, लेकिन मैं सुझावों के लिए खुला हूं यदि आप कल्पना में संशोधन संलग्न करना चाहते हैं। शेल बनाम मटेरियलशेल चीज़ के लिए, मैंने इसे ऊपर संबोधित किया। चरण 1 सुनिश्चित कर रहा था कि मटेरियलशेल समझ में आता है, फिर इसे बेस क्लास में तोड़ना चरण 2 है।

@dylanberry बेस क्लास वास्तव में इतना आसान नहीं

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

@makayn एक संक्रमण/

@ Encrypt0r बिल्कुल नहीं। इसे एक संकर के रूप में सोचें। यह प्रतिपादन के लिए अनुमति देगा लेकिन तह हुड के तहत इसके सभी प्लेटफ़ॉर्म विशिष्ट नियंत्रण केवल ड्राइंग कोड के साथ थीम पर आधारित होंगे। हालाँकि, स्कीया के लिए एक एस्केप हैच है जिसे आसानी से जोड़ा जा सकता है (हालाँकि मुझे संदेह है कि यह इसे v1 के पास कहीं भी बनाता है)।

@opcodewriter ListView2 (जाहिर है कि इसका वास्तव में नाम नहीं होगा) इस साल लंबे समय तक रोडमैप पर है। एक नया सूची दृश्य क्यों? वैसे मूल एपीआई लगभग असीमित संख्या में बग और मुद्दों की ओर जाता है जिन्हें हम पूरी तरह से पिछली संगतता को तोड़ने के बिना वास्तव में प्रभावी ढंग से ठीक नहीं कर सकते हैं। सेल/व्यूसेल और आइटम्स व्यू जैसी चीजेंऔर TemplatedItemsList जबकि वे 1.0 के लिए जो थे उसके लिए अच्छी तरह से काम करते थे, वे एपीआई के आधुनिक उपयोग के लिए आवश्यक होने के लिए कहीं भी सक्षम नहीं हैं।

दुर्भाग्य से मैं इसे ListView प्रकार के भीतर हल करने के किसी भी तरीके के बारे में नहीं सोच सकता, और मुझे नहीं लगता कि समुदाय दुर्भाग्य से सक्षम है। अभी सबसे अच्छा विकल्प यह है कि ListView को वैसे ही रखा जाए, और फिर कम ओवरहेड, कम बहीखाता पद्धति, कम विषम प्रकारों के साथ कुछ अधिक चिकना बनाया जाए, जिन्हें मौजूद होने की आवश्यकता नहीं है और लक्ष्य ढांचे पर भरोसा करते हैं जो वे सबसे अच्छा करते हैं।

बस पुरानी पुनर्चक्रण रणनीति को हटा देना, जो कि एक बड़ा बैककंपैट ब्रेकिंग परिवर्तन होगा जो हम नहीं कर सकते, Xamarin.Forms कोडबेस के एक बड़े हिस्से को हटा देगा। ListView2 आपको इन वस्तुओं को हटाकर धातु के बहुत करीब लाएगा, जिनका उद्देश्य गार्ड रेल (या सेल के मामले में, 2 अलग-अलग आंतरिक परियोजनाओं का अपवित्र विलय) था और अब सभी को चोट पहुंचा रहे हैं।

पुरानी कैशिंग रणनीति आज अस्तित्व में मौजूद प्रत्येक रेंडरर को प्रभावित करती है। यही कारण है कि हर रेंडरर अपने एलिमेंट को बदलने का समर्थन करता है। अगर वह मेरे सबसे अच्छे अनुमान से दूर हो गया तो परियोजना में सभी कोड का लगभग 10% चला जाएगा। यह वास्तव में परियोजना का सबसे बड़ा कैंसर है।

@davidortinau आपको अपनी टिप्पणी सिर्फ इसलिए मिलती है क्योंकि आपकी इतनी प्यारी स्वरूपण है!

यदि मैं शीर्ष स्तर पर अपने आवेदन का वर्णन करने के लिए इस दृष्टिकोण का उपयोग करता हूं, तो मुझे मिलता है:

• हर प्लेटफॉर्म पर समान दिखने के लिए थीम वाला ऐप
• सामग्री डिजाइन (इस मामले में) डिफ़ॉल्ट रूप से पैटर्न
• कॉन्फ़िगरेशन के साथ सक्षम नवीनतम नेविगेशन पैटर्न
• मुझे आईओएस और एंड्रॉइड और यूडब्ल्यूपी पर समान दिखने के लिए एंट्री या बटन को अनुकूलित करने के लिए श्रम करने की आवश्यकता नहीं है?

क्या यह सही है? अन्य लाभ जिन पर मुझे प्रकाश डालना चाहिए?

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

ऐप के बजाय मेरे पास मटेरियलशेल है। इसका लाभ उठाने के लिए मुझे एक नया शीर्ष स्तरीय एप्लिकेशन प्रतिमान सीखने/अपनाने की आवश्यकता है?

गलत। आपके ऐप्स मेनपेज मटेरियलशेल है। एप्लिकेशन अभी भी आपका ऐप रूट है।

एक बार जब मैं अपने ऐप में आ जाता हूं, तो मैं कंटेंटपेज लैंड में वापस आ जाता हूं, है ना? लेकिन मेरे सभी बटन और प्रविष्टियां भौतिक और सुंदर हैं।

अपवाद के साथ जहाँ आप ऊपर गलत थे, हाँ यह सही है।

क्या मैं अभी भी ऑनप्लेटफॉर्म और किसी अन्य प्लेटफॉर्म पर अलग दिखने के लिए लुक (या व्यवहार) को अलग करना पसंद कर सकता हूं?

हां।

इस "खोल" का उपयोग करने के लिए मौजूदा ऐप से मेरा माइग्रेशन पथ कैसा दिखता है?

Google Play Store रेप्रो केस देखें, कल्पना करें कि आपके सभी ऐप्स वर्तमान पेज वहां हैं। यह केवल आपके ऐप में उन क्षेत्रों को बदल देता है जहां आप सीधे एनएवी/टैब/एमडी पेजों का उपयोग कर रहे हैं। इसका आपके ContentPages पर कोई प्रभाव नहीं पड़ता है।

मैं नया मटेरियलशेल पेश करता हूं, वर्णन करता हूं कि मैं कैसे चाहता हूं कि मेरा ऐप संरचना और दिखने वाला हो, और नई अच्छाई देखने के लिए इसे चलाएं?

बिंगो

अगर मुझे फ़्लायआउट या मेनू आइटम दिखने का तरीका पसंद है, तो मेरे पास क्या विकल्प हैं, लेकिन मुझे अपने डिज़ाइनर कंप्स से मेल खाने के लिए उन्हें ट्वीक करने की ज़रूरत है?

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

मैं किस बिंदु पर कह रहा हूं "उह, मुझे यह सब खुद करना चाहिए था" और जो मेरे पास है उसे मानक Xamarin.Forms ऐप संरचना में ले जा रहा है?

यदि Google Play Store भौतिक लेआउट फ़्लाईआउट आप जो चाहते हैं उससे बिल्कुल अलग दिखता है। थोड़ा अलग नहीं, बिल्कुल अलग।

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

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

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

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

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

हमने पहले ऐसा क्यों नहीं किया? शुरुआती दिनों में यह एक डिज़ाइन लक्ष्य नहीं था और फिर हमने बस उसी से शादी कर ली ... यह काफी बड़ा और इतना नया है कि हमें उस गलती को अपने साथ नहीं रखना है।

@opcodewriter

गंभीरता से, ज़ामरीन फॉर्म कितने अलग-अलग दिशाओं में जा सकते हैं? एक्सएफ टीम कम से कम एंड्रॉइड और आईओएस के लिए मौजूदा एक्सएफ कार्यान्वयन को ठीक करने में मुश्किल से सक्षम है, और अब यह?

बग फिक्सिंग के बारे में क्या, XAML पूर्वावलोकन को ठीक करना, प्रदर्शन के बारे में क्या?

^^ यह

@migueldeicaza

दोस्तों, कल जेसन और मेरे बीच इस बात पर चर्चा हुई कि इस युक्ति को कैसे बेहतर बनाया जाए और हम एक बड़ा अपडेट करेंगे, हम इसे अलग-अलग मुद्दों में विभाजित कर रहे हैं।

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

क्या यह xamarin रूपों में विकसित करने का नया डिफ़ॉल्ट व्यवहार/तरीका होगा? या क्या हमारे पास अभी भी प्रत्येक प्लेटफ़ॉर्म विशिष्ट रूप और अनुभव के साथ अपने ऐप्स बनाने का विकल्प होगा?

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

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

@ जसस्मिथ

1. 500 से अधिक खुले मुद्दे हैं।
2. ज़ामरीन फॉर्म 3 साल पुराना है और बुनियादी नियंत्रण और कार्यक्षमता में अभी भी बग हैं, महत्वपूर्ण सुविधाओं की अभी भी कमी है और प्रदर्शन को अभी तक पूरी तरह से कम नहीं किया गया है (मुझे पता है कि कुछ सुधार किए गए थे, लेकिन एंड्रॉइड पर प्रदर्शन ध्यान देने योग्य सबपर है)।
3. Xamarin Forms देव टीम अभी भी कम आकार की है।

आप इस पूरी नई सुविधा पर अभी काम क्यों शुरू करना चाहते हैं? पहले उपरोक्त पर ध्यान केंद्रित करने का कोई मतलब नहीं है?

ListView से संबंधित आपकी उपरोक्त टिप्पणी के बारे में: मैं इस पर किसी भी तरह के बोल्ड टेक की सराहना करता हूं, जिसमें इसे पूरी तरह से नया स्वरूप देना शामिल है। ऐसा नहीं है कि ज़ामरीन फॉर्म में सब कुछ इतना बढ़िया है कि चीजों को छुआ नहीं जाना चाहिए।

@opcodewriter

1) हाँ वहाँ हैं। मैं सहमत हूं कि यह एक समस्या है और मैं व्यक्तिगत रूप से प्राथमिकता वाले कार्य आइटम के रूप में काम करता रहूंगा।

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

3) यहां कोई तर्क नहीं।

आप इस पूरी नई सुविधा पर अभी काम क्यों शुरू करना चाहते हैं? पहले उपरोक्त पर ध्यान केंद्रित करने का कोई मतलब नहीं है?

यह कार्य निर्धारित नहीं है, हम यहाँ केवल एक युक्ति की चर्चा कर रहे हैं। जब वे मेरी सलाह के साथ उचित महसूस करेंगे तो मेरा प्रबंधन इसे शेड्यूल करेगा।

ListView से संबंधित आपकी उपरोक्त टिप्पणी के बारे में: मैं इस पर किसी भी तरह के बोल्ड टेक की सराहना करता हूं, जिसमें इसे पूरी तरह से नया स्वरूप देना शामिल है। ऐसा नहीं है कि ज़ामरीन फॉर्म में सब कुछ इतना बढ़िया है कि चीजों को छुआ नहीं जाना चाहिए।

ListView वास्तव में Xamarin.Forms का बग भालू है। उन 500 मुद्दों में से, जिनमें से 220 को बग के रूप में चिह्नित किया गया है (बहुत सारे हाउसकीपिंग या एन्हांसमेंट मुद्दे भी हैं), 25% का उत्तर सिर्फ लिस्ट व्यू के साथ करना है। तुलना के लिए यह लगभग उसी प्रतिशत के बारे में है जो पूरे यूडब्ल्यूपी प्लेटफॉर्म के साथ करना है। एंड्रॉइड में क्रैशर्स की एक उचित संख्या जिसे मूल रूप से रेंडरर के रूप में वर्णित किया जाता है, डिस्पोजल के बाद उपयोग किया जाता है, लिस्ट व्यू बग भी हैं, हालांकि वे मेरी खोज में दिखने की संभावना नहीं रखते हैं क्योंकि लिस्ट व्यू खोज क्वेरी में कहीं भी दिखाई नहीं देगा।

@jassmith मौजूदा मुद्दों को ठीक करने के अलावा (ListView के बगल में, ऐसी अन्य चीजें हैं जो अभी भी हमेशा सही काम नहीं करती हैं), ऐसी महत्वपूर्ण विशेषताएं भी हैं जिन्हें छोड़ दिया गया था (यादृच्छिक क्रम):
- ट्रू पॉपअप सपोर्ट (बुनियादी और सामान्य सुविधा अभी भी गायब है)
- वापस नेविगेट करते समय पृष्ठ नेविगेशन रद्द करें (लंबी बकाया समस्या)
- मूल नियंत्रण गायब है (कोई चेकबॉक्स, रेडियोबटन, और अधिक नहीं)
- क्रॉस प्लेटफॉर्म ड्राइंग (कैनवास नियंत्रण या किसी अन्य तरीके से)
- सॉलिड \ ग्रेडिएंट ब्रश (सॉलिडकोलरब्रश, ग्रेडिएंटब्रश) के क्रॉस प्लेटफॉर्म ड्राइंग के लिए समर्थन

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

@opcodewriter

ट्रू पॉपअप सपोर्ट (बुनियादी और सामान्य सुविधा अभी भी गायब है)

निष्पक्ष, ऐसा लगता है कि वास्तविक बनने के लिए पर्याप्त प्राथमिकता प्राप्त नहीं हुई है। यह वास्तव में एक बिंदु पर बहुत दूर हो गया।

वापस नेविगेट करते समय पृष्ठ नेविगेशन रद्द करें (लंबी बकाया समस्या)

यह वास्तव में कुछ ऐसा है जिसे मटेरियलशेल संबोधित करने के लिए है। नेविगेशनपेज में ऐसा नहीं करने के बहुत ठोस कारण हैं।

बुनियादी नियंत्रण गायब हैं (कोई चेकबॉक्स, रेडियोबटन, और बहुत कुछ नहीं)

इनमें से कुछ अभी चल रही F100 पहल का हिस्सा हैं।

क्रॉस प्लेटफॉर्म ड्राइंग (कैनवास नियंत्रण या किसी अन्य तरीके से)

#2452 . में निर्दिष्ट के अनुसार यह इसके लिए बहन API होगा

सॉलिड\ग्रेडिएंट ब्रश (सॉलिडकलरब्रश, ग्रेडिएंटब्रश) के क्रॉस प्लेटफॉर्म ड्राइंग के लिए समर्थन

ऊपर जैसा ही जवाब।

@ जसस्मिथ

निष्पक्ष, ऐसा लगता है कि वास्तविक बनने के लिए पर्याप्त प्राथमिकता प्राप्त नहीं हुई है। यह वास्तव में एक बिंदु पर बहुत दूर हो गया।

ठीक है, 2018 के अंत तक इसे प्राथमिकता देने की उम्मीद है :)

यह वास्तव में कुछ ऐसा है जिसे मटेरियलशेल संबोधित करने के लिए है। नेविगेशनपेज में ऐसा नहीं करने के बहुत ठोस कारण हैं।

क्या आप कृपया अधिक विवरण दे सकते हैं कि वर्तमान कार्यान्वयन में ऐसा क्यों नहीं किया जा सकता है?

इनमें से कुछ अभी चल रही F100 पहल का हिस्सा हैं।

अच्छा ऐसा है। उंगलियों को पार कर..

क्या आप कृपया अधिक विवरण दे सकते हैं कि वर्तमान कार्यान्वयन में ऐसा क्यों नहीं किया जा सकता है?

मैं यहाँ इस पर अधिक ध्यान नहीं दूंगा क्योंकि हम बड़े पैमाने पर ट्रैक से बाहर हो रहे हैं लेकिन इसका सार इस प्रकार है:

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

वहाँ कुछ अन्य छोटी-छोटी चिंताएँ भी हैं कि यह स्टाइल को कैसे प्रभावित करता है। हालांकि यह लंबी कहानी छोटी है। यदि आप अभी भी इस विशेष सुविधा पर चर्चा करना चाहते हैं तो मैं एक नया मुद्दा खोलने का सुझाव देता हूं :)

@ जसस्मिथ
मैंने सोचा कि बस gestureRecognizerShouldBegin संभालना और OnBackButtonPressed जैसे कुछ कॉल करना पर्याप्त होना चाहिए।

कुल मिलाकर मुझे वास्तव में बहुत कुछ पसंद है जो मैं पढ़ रहा हूं, हालांकि ऐसा कुछ ऐसा नहीं लगता है जो कोर ज़ामरीन फॉर्म नगेट/रेपो में किया जाना चाहिए।

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

ठीक उसी तरह जैसे जब डेवलपर्स Xamarin Classic/Native या Xamarin प्रपत्रों के साथ जाने का निर्णय लेते हैं, तो मैं एक शेल के साथ Xamarin प्रपत्र या Xamarin प्रपत्रों के साथ जाने का एक समान निर्णय देख सकता हूं।

Xamarin प्रपत्रों को एक दूसरे की तरह दिखने के लिए प्लेटफ़ॉर्म को अनुरूप बनाने की कोशिश किए बिना सर्वोत्तम क्रॉस प्लेटफ़ॉर्म UI फ्रेमवर्क बनाने पर ध्यान केंद्रित करना चाहिए। आज Xamarin Forms यह सुनिश्चित करने का एक बड़ा काम करता है कि प्लेटफ़ॉर्म फील का सम्मान किया जाए।

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

@MisterJimson
आपकी प्रतिक्रिया के लिए आपका धन्यवाद। सार्वजनिक एपीआई सतह क्षेत्र का सटीक स्थान अभी तय नहीं किया गया है। दोनों दृष्टिकोणों के पक्ष और विपक्ष हैं।

शेल और मटेरियलशेल वर्ग दोनों के लिए कल्पना को अपडेट किया जाएगा (उम्मीद है कि बहुत जल्द)। मटेरियलशेल क्लास वह हिस्सा होगा जिसे हम कोर से बाहर जाने पर विचार करते हैं। आपने जो वर्णन किया है वह शैल होगा।

शेल ब्रेकआउट और नेविगेशन स्पेक अपडेट के साथ अपडेट किया गया

मैं वास्तव में इसे पसंद करूंगा यदि मौजूदा एक्सएफ कार्यान्वयन किया जाता है ... मजबूत और बेहतर ऐसा कुछ सक्षम करने के लिए जो बीसीएल के हिस्से के रूप में नहीं, एक एडन के रूप में मौजूद है। इसलिए मजबूत अंतर्निहित प्लेटफॉर्म जो सही और स्थिर है, मौजूदा ऐप्स और इस तरह की किसी भी नई परत को लाभान्वित करेगा।

इस बात के विकास के लिए तत्पर हैं।

@jassmith @brianlagunas

बस कुछ अवलोकन।

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

मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि मौजूदा दर्द बिंदुओं और सीमाओं को संबोधित किया जाए और साथ ही नई क्षमताओं के साथ।

बहुत अच्छा लगता है।

मैं एक्सएफ के लिए बहुत नया हूं लेकिन ढांचे में कुछ हद तक नाजुक होने की प्रतिष्ठा है, हालांकि निश्चित रूप से यह आपके प्रयासों के लिए तेजी से सुधार कर रहा है।

तो इसके लायक क्या है, यह मेरी राय है :-)

यह बहुत अच्छा है कि ज़ामरीन को इस समय बहुत प्यार मिल रहा है, लेकिन मैं हूं , टूलिंग और फ्रेमवर्क दोनों कुछ तकनीकी ऋण चुकाने के साथ कर सकते हैं।

मुझे @MisterJimson के विचार भी पसंद हैं कि यह एक अलग परत होनी चाहिए - लेकिन आपको अपनी क्षमता के बारे में अपने आप से ईमानदार होना चाहिए और आप कितने ढांचे का समर्थन कर सकते हैं। हम सभी रोमांचक नई चमकदार चीजों को कोड करने और कठिन निर्णयों से बचने के लिए प्रवृत्त हैं, लेकिन हम अपने कोड के लिए एक ठोस आधार विकसित करने के लिए आप पर भरोसा करते हैं।

मुझे किसी और के बारे में चिंता किए बिना अपना कोड काम करने में पर्याप्त समस्याएं हैं :-)

एक्सएफ इस समय एक अच्छी जगह पर है, इसमें वास्तव में एक ठोस टूलसेट बनने की क्षमता है।

इस पर आपकी कड़ी मेहनत के लिए धन्यवाद, यह दिखाता है।

@मैकायन

बैकबटन व्यवहार, निश्चित रूप से एक दृश्यता संपत्ति होनी चाहिए यदि आप इसे बिल्कुल नहीं चाहते हैं?

CanExecute झूठी वापसी के साथ कमांड सेट करें। मैंने फिलहाल कोई द्वितीयक तरीका नहीं जोड़ने का विकल्प चुना है।

मटेरियलशेल नेविगेशन योजना प्रिज्म की तरह है, क्या यह इन मौजूदा ढांचे के साथ काम करेगी? (प्रिज्म, फ्रेशएमवीवीएम, एमवीवीएमक्रॉस)

मुझे यकीन है आशा है! मुझे यकीन नहीं हो रहा है लेकिन मैं उनके और उनकी सारी परेशानियों के बारे में सोच रहा था। यही कारण है कि सभी नेविगेशन उदाहरण के लिए एक ही घटना के माध्यम से होता है।

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

यह हिस्सा कठिन है। मैं यहां जितना संभव हो उतना विस्तार करने की अनुमति देना चाहता हूं लेकिन मैं वास्तव में सुझावों के लिए खुला हूं कि इसे एक समझदार और उचित तरीके से कैसे सुधारें।

MasterDetail को ज्यादा छुआ नहीं गया है, क्या आप फ्लाईआउट मेनू को अनुकूलित कर पाएंगे?

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

हैमबर्गर पर हमारा क्या नियंत्रण होगा?

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

@stevehurcombe तकनीकी पेबैक जारी है और जारी है। यह टीम के बहुत छोटे दल द्वारा समानांतर में चलाया जाएगा। दुर्भाग्य से वास्तविकता यह है कि इस युक्ति का एक अजीब तरीके से तकनीकी भुगतान के बारे में है। Xamarin.Forms ने अपनी 1.0 रिलीज़ के साथ API ऋण की एक बड़ी राशि खर्च की, और तब से उस ऋण को वहन कर रहा है। एक्सएफ में कुछ चीजें काम को सही बनाने के लिए बहुत मुश्किल हैं, या काम को सही करना असंभव भी है, बस जिस तरह से एपीआई उन्हें व्यक्त करता है।

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

जहां तक ​​टूलींग का संबंध है, इसके लिए समर्पित एक पूरी तरह से अलग टीम है और वे बड़ी प्रगति कर रहे हैं। पिछले 6 महीनों में आंतरिक टूलिंग में बड़े पैमाने पर सुधार हुआ है और मैं वास्तव में आपके द्वारा इसे आज़माने की आशा करता हूँ!

@मैकायन

मटेरियलशेल नेविगेशन योजना प्रिज्म की तरह है, क्या यह इन मौजूदा ढांचे के साथ काम करेगी? (प्रिज्म, फ्रेशएमवीवीएम, एमवीवीएमक्रॉस)

डरो मत, @jassmith ने इसे मेरे ध्यान में लाया, इससे पहले कि समुदाय को एहसास हो कि यह मुद्दा यहाँ था ... आप सुनिश्चित हो सकते हैं कि यह कुछ ऐसा होगा जिसका हम समर्थन करना चाहते हैं। इस परिमाण में से कुछ को निश्चित रूप से बहुत सारे क्रॉस टीम संवादों की आवश्यकता होगी ताकि यह सुनिश्चित हो सके कि यह बड़े पैमाने पर फॉर्म डेवलपर की जरूरतों को पूरा करता है, साथ ही साथ प्रिज्म जैसे एमवीवीएम ढांचे की जरूरतों को पूरा करता है।

@dansiegel

यह जानकर अच्छा लगा कि दोनों टीमें बातचीत में हैं, मुझे बस इतना ही जानना है 👍

@jassmith अब तक यह स्पष्ट है कि जिस तरह से कुछ चीजें चल रही हैं या XF में आर्किटेक्चर की गई हैं, वह सबसे अच्छी नहीं है। तो सुअर पर लिपस्टिक लगाने के बजाय (यहाँ असभ्य नहीं होना चाहते), क्यों न या तो खरोंच से एक नया ढांचा फिर से बनाया जाए या मौजूदा एक को बड़े पैमाने पर रिफैक्टर किया जाए। मुझे पता है, यह बहुत डरावना लगता है, लेकिन मुझे पूरा यकीन है कि ज़ामरीन फॉर्म डेवलपर्स के बड़े हिस्से को कोई आपत्ति नहीं होगी, हम सभी अपने ऐप को रिफैक्टर करने के लिए उत्साहित होंगे या जो कुछ भी हमारे पास ऐसे ऐप हैं जो बहुत बेहतर तरीके से चलते हैं।
मैंने पीआर को अच्छे रिफैक्टरिंग के साथ खारिज कर दिया है क्योंकि "हम इस तरह के बदलाव नहीं चाहते हैं"। मुझे यकीन नहीं है कि यह नियम किसने बनाया है, लेकिन उसे एक गहरी सांस लेनी चाहिए, आराम करना चाहिए और शायद "नियम" पर पुनर्विचार करना चाहिए।
सबसे अच्छा क्या है: निराश देवों को ऐसे ढांचे का उपयोग करते रहें जो इसे बनाए नहीं रख सकते हैं या निराश देव हैं जिन्हें कुछ रिफैक्टरिंग कार्य करने की आवश्यकता है? बस मेरे 2 सेंट...

@opcodewriter आप और मैं सहमत हैं लेकिन यह इस युक्ति के लिए

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

विडंबना यह है कि यूआरआई नेविगेशन योजना कुछ ऐसी थी जिसे हम दिन में वापस करना चाहते थे और प्रिज्म को लागू करने के लिए धक्का देना शुरू कर दिया क्योंकि हम इसे ढांचे में उचित रूप से प्राप्त नहीं कर सके। उनका कोई श्रेय नहीं लेने के लिए, वे उस के 100% के लायक हैं :)

आशुलिपि के सटीक शब्दार्थ अभी भी पकड़ में हैं।

मुझे लगता है कि यह संभवतः और अधिक खत्म हो जाएगा:

<Button Command="{segue:Uri}" CommandParameter="app://Foo/Bar/Baz" />

या

<Button Command="{segue:Push}" CommandParameter="{DataTemplate local:MyPage}" />

इसलिए एक्सटेंशन अधिक सटीक हो सकते हैं कि वे कौन से पैरामीटर लेते हैं। नेमस्पेस का उपयोग ज्यादातर चीजों को इंटेलिजेंस के साथ खोजने में आसान रखने के लिए किया जाता है।

@jassmith मुझे वास्तव में यह पसंद है कि यह सामान है। क्या मैं पूछ सकता हूं कि आप पुश मोडल का समर्थन कैसे करना चाहते हैं?

मेरे पास सभी विवरण नहीं हैं, लेकिन मैं मार्कअप एक्सटेंशन में लिपटे हुए प्रिज्म की तरह url एनएवी की कल्पना कर सकता था।

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="path/to/page" />

<!-- push modal -->
<Button Command="{segue:Uri Modal='true'}" CommandParameter="path/to/page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://root/path/to/page" />

ध्यान देने वाली पहली बात यह है कि URI नेविगेशन केवल शेल के साथ काम करेगा। यह एकमात्र ऐसा स्थान है जहां हम लगातार अजीब किनारे के मामलों के बिना स्टैक की समझ बना सकते हैं और हम अवधारणा का समर्थन करने के लिए नेविगेशन इंटरैक्शन को डिज़ाइन कर सकते हैं।

अभी के लिए हम केवल पूर्ण URI का समर्थन कर रहे हैं। आंशिक रूप से निपटने के लिए बहुत कठिन हैं क्योंकि वे प्रासंगिक हैं।

आपके 3 उदाहरण तब होंगे, मान लीजिए कि वर्तमान स्थान है: ऐप: // शैल/ऐप्स/गेम्स/विवरण

विशेष रूप से इसका मतलब है कि आप एक शेल में हैं, जिसका वर्तमान शेलइटम में एप्स रूट है, जिसका वर्तमान शेलटैबइटम में गेम रूट है, जिसके पास कंटेंटपेज है जो इसके स्टैक पर धकेल दिया गया है जिसमें रूट विवरण है।

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games/Details/page" />

<!-- push modal -->
<Button Command="{segue:Uri}" CommandParameter="app://page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games" />

एक शेल उरी में पहला स्थान हमेशा एक शेल होता है। यदि ऐसा नहीं है तो इसे एक मोडल पुश माना जाता है। अगला शेलटैब है, फिर शेलटैबआइटम। उसके बाद ShellTabItem के नेविगेशन स्टैक का अनुसरण करता है। मेरा इस समय सभी संभावित पृष्ठ नियंत्रणों के लिए URI एनएवी को बैकपोर्ट करने का कोई इरादा नहीं है। यह उन लोगों के साथ वास्तव में बालों वाला हो जाता है जो MasterDetailPage का उपयोग करते हैं ...

रूट पंजीकरण और रूट गुणों के साथ टाइप आधारित रूटिंग की कोई आवश्यकता नहीं है। मैं इसे युक्ति के रूप में हटाने जा रहा हूं।

@jassmith इस नेविगेशन सामग्री पर अधिक विचार कर रहा है, और मेरे कुछ प्रश्न हैं

1. आप CanExecute को कैसे संभाल सकते हैं
2. आप उपयोगकर्ता को एकाधिक टैप पर नियंत्रण (रोकें पढ़ें) कैसे दे सकते हैं?
3. आप सापेक्ष नेविगेशन को कैसे संभालते हैं? आईई आप 3 पेज गहरे हैं और आगे जाने की जरूरत है, लेकिन ढेर पूरी तरह गतिशील है?
4. प्रिज्म में NavigationParameters की यह शानदार धारणा है जिससे हम न केवल बुनियादी मूल्यों को क्वेरीस्ट्रिंग /Navigation/MyPage/MyPageDetails?id=33 माध्यम से पारित कर सकते हैं, बल्कि जटिल वस्तुओं new NavigationParameters {{nameof(MyObject), MyObject}} भी पारित कर सकते हैं। क्या आप कुछ इसी तरह का समर्थन करने की योजना बना रहे हैं?

@ चेसफ्लोरेल

1) सेग्स के साथ? आप वर्तमान में नहीं कर सकते। निश्चित रूप से और अधिक सोचने की जरूरत है। एक सेग्यू कमांड बनाने का एक तरीका है लेकिन यह ... बेकार है। यह आपको इसे संभालने देगा लेकिन उस समय यह वास्तव में इसके लायक नहीं है।

2) पुश पूरा होने तक एक सेग्यू खुद को निष्क्रिय कर देगा। पिछला नेविगेशन कार्य पूरा होने तक नो-ऑप कमांड को सक्रिय करने का और प्रयास।

3) आप सेगमेंट के साथ पुश/पॉप जैसे पारंपरिक नेविगेशन का उपयोग कर सकते हैं। ये सापेक्ष क्रियाएं हैं।

4) [QueryParameterAttribute] पहले से मौजूद हो भी सकता है और नहीं भी, मैं न तो पुष्टि कर सकता हूं और न ही इनकार कर सकता हूं। ;)

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

पिछले अनुभव के निर्माण से यूआरआई-आधारित ऐप नेविगेशन (पी एंड पी के लिए सीएबी-कंपोजिट यूआई एप्लीकेशन ब्लॉक में वापस), मैं दृढ़ता से सुझाव दूंगा कि आप System.Uri प्रकार का उपयोग न करें और इसके बजाय सब कुछ यूआरआई की तरह दिखें, लेकिन यूआरआई कार्यान्वयन का ही उपयोग न करें। @pprovost जीवन भर के निशानों की गवाही इंटरनेट यूआरआई प्रतिबंधों और त्रुटियों (यानी होस्ट नामों पर) का सामना कर रहे थे, तो अनगिनत मुद्दों का सामना करना पड़ा कि हम इन-ऐप सामान की कम परवाह नहीं कर सकते।

पहले ही किए गए नुकसान का एक हिस्सा, मुझे लगता है।

यूआरआई आधारित नेविगेशन योजना का समर्थन करते समय वास्तव में System.Uri सबसे अच्छा विकल्प है। जबकि सीएबी ने यूआरआई नेविगेशन का उपयोग किया था, आपने जैसा कहा था वैसा ही किया और आपको सिस्टम.उरी ऑब्जेक्ट के बजाय स्ट्रिंग्स का उपयोग करने की अनुमति देकर इसे यूआरआई की तरह "दिखना" बना दिया। मेजबान नामों की कभी आवश्यकता नहीं थी।

आप जो मांग रहे हैं वह एक बहुत ही ढीला स्ट्रिंग आधारित एपीआई है जो आपके द्वारा डाले गए किसी भी स्ट्रिंग सिंटैक्स को स्वीकार कर सकता है, जो ऐसा कुछ नहीं है जो अनुमानित परिणाम उत्पन्न करने वाला है। यूआरआई/स्ट्रिंग आधारित नेविगेशन योजना के काम करने के लिए नियम होने चाहिए।

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

यदि आप अधिक प्रतिबंधात्मक (या बेहतर शब्दार्थ/पार्सिंग/सत्यापन?) चाहते हैं, तो आप अपना स्वयं का अमूर्तन बना सकते हैं, लेकिन IMHO, System.Uri बहुत सारे इंटरनेट सामान लाता है जो मुफ्त में नहीं है। यह उसी तरह है जैसे मोनो/मोनो डेवलपमेंट ने पथों का प्रतिनिधित्व करने के लिए अपना स्वयं का फाइलपाथ बनाया, जो आम तौर पर केवल तार होते हैं।

कम से कम, ऐसा लगता है कि सभी यूआरआई को सापेक्ष माना जाता है, जो चीजों को सरल करता है। सीएबी में हमने योजना और होस्टनाम भागों के साथ पूर्ण यूरिस का इस्तेमाल किया, जो समस्याग्रस्त था।

मैं ResoucePath तुलना में Uri जैसे कुछ पसंद करूंगा। लेकिन इस खेल में देर हो चुकी है, मुझे पूरा यकीन है कि यह वैसे भी सौदा हो गया है।

मुझे यकीन नहीं है कि आपको क्या लगता है कि फाइल सिस्टम पथों का किसी भी चीज से क्या लेना-देना है ...

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

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

समझ में आता है। प्रिज्म @brianlagunas पर पृष्ठभूमि की जानकारी के लिए धन्यवाद! अब मुझे कल्पना को ध्यान से पढ़ना चाहिए और वास्तव में कुछ उपयोगी प्रतिक्रिया प्रदान करनी चाहिए;)

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

उदाहरण के लिए यह संभव होगा/कैसे करें:

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

एक तकनीकी नोट पर: क्या शैल पृष्ठों को रीसायकल करेगा ताकि एक बार पृष्ठ पर दो बार नेविगेट करने के बाद, मूल तत्वों को इसके तहत एक अलग वीएम के साथ फिर से उपयोग किया जा सके?

हाय @ रोगी

मैं कार्यान्वयन पर आपकी प्रतिक्रिया का स्वागत करता हूं। मुझे लगता है कि यह पागल एक्स्टेंसिबल है: https://github.com/xamarin/Xamarin.Forms/blob/9558f2837280e02b41848d3a3c3213d49a664751/Xamarin.Forms.Platform.iOS/Renderers/ShellRenderer.cs

एंड्रॉइड अभी भी भारी विकास के अधीन है, हालांकि यह एक समान दृष्टिकोण का उपयोग करता है।

@rogihee पृष्ठों के पुनर्चक्रण के लिए, मैं इसे व्यवहार्य बनाने की एक समझदार विधि का पता लगाने की कोशिश कर रहा हूं। आम तौर पर यह वर्तमान में नहीं है क्योंकि इसे स्पष्ट रूप से ऑप्ट इन करने की आवश्यकता होगी।

ये "बनाएँ*" विकल्प अच्छे लगते हैं। इस पर तेजी से प्रगति देखकर अच्छा लगा!

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

शैल बहुत अधिक तरलता की धारणा पर केंद्रित है। इसकी जगह अभी हर जगह नहीं है लेकिन यह एक साथ आ रहा है।

मुझे वास्तव में कुछ शुरुआती उपयोगकर्ताओं को जगह में लाने की ज़रूरत है जो यह सुनिश्चित करने के लिए खोल के साथ पागल चीजें करने की कोशिश करते हैं कि यह उस भार को संभाल सकता है जिसके लिए इसे डिज़ाइन किया गया है।

@jassmith mig ने बिल्ड में 3 मिनट के लिए सिर्फ शेल का उल्लेख किया .....

मैं उसके पिता नहीं हूँ

+1

दुनिया की वर्तमान स्थिति से मेल खाने के लिए अपडेट किया गया एपीआई, अभी भी नमूनों को अपडेट करने की जरूरत है।

कुछ अद्यतन नमूने जोड़े गए, अभी भी अन्य नमूनों को ठीक करने और शॉर्टहैंड सिंटैक्स का उपयोग करते समय मार्गों के विवरण को अपडेट करने के लिए बहुत सारे काम करने की आवश्यकता है (जैसा कि आपको शॉर्टहैंड मार्ग मिलते हैं!)

भगवान, मुझे पार्टी के लिए बहुत देर हो चुकी है। बढ़िया लेखन और चर्चा। मैंने इस सब के माध्यम से स्किम किया (हवाई अड्डे पर खेद है) और मेरा अपना एक सुझाव है। क्षमा करें यदि इसका उल्लेख कहीं और किया गया था।

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

एक और यह है कि आप एक्सएएमएल टैग का नाम क्यों नहीं बदलते हैं ताकि उन्हें समझना आसान हो? शायद शेलसेक्शन के बजाय टैब का उपयोग करें? अब बहुत सारे शेलएक्स टैग हैं।

आईओएस के लिए, मेरा मानना ​​​​है कि नेविगेशन बार पर स्क्रॉल मोड को सक्षम करने के लिए चालू/बंद करने के लिए एक संपत्ति है। Android के लिए, आपको नए लेआउट (CoordinatorLayout, AppBarLayout, आदि) का उपयोग शुरू करना होगा। इस संबंध में एक्सएफ का एंड्रॉइड कार्यान्वयन काफी पुराना है क्योंकि यह अभी भी मुख्य कंटेनर के रूप में रिलेटिवलाउट का उपयोग कर रहा है। मुझे लगता है कि इस विशिष्ट मुद्दे के बारे में कहीं न कहीं एक एन्हांसमेंट टिकट है। मुझे शैल को विभिन्न स्क्रॉल मोड का समर्थन करना अच्छा लगेगा।

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

@adrianknight89

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

ऐसा कुछ है जो मैं वास्तव में करने का सही तरीका जानने की कोशिश कर रहा हूं। दुर्भाग्य से सभी प्लेटफ़ॉर्म इस सुविधा का समर्थन नहीं करते हैं, इसलिए संभवतः यह एक प्लेटफ़ॉर्म विशिष्ट सौदा होगा। इसका समर्थन करने के लिए कम से कम एंड्रॉइड का निर्माण किया गया था, मैं इसे कभी-कभी चालू करता हूं ताकि यह सुनिश्चित हो सके कि यह अभी भी काम करता है।

एक और यह है कि आप एक्सएएमएल टैग का नाम क्यों नहीं बदलते हैं ताकि उन्हें समझना आसान हो? शायद शेलसेक्शन के बजाय टैब का उपयोग करें? अब बहुत सारे शेलएक्स टैग हैं।

यहां नामकरण वास्तव में कठिन है। शेलटैब ऊपर बनाम नीचे के लिए थोड़ा भ्रमित करने वाला है। मैंने इसके बजाय अधिक सामान्य पदानुक्रमित नामों का विकल्प चुना, हालांकि मुझे यह स्वीकार करना होगा कि मैं नामकरण से खुश नहीं हूं। सुझावों का 100% स्वागत है ... उनके नामों को फिर से रिफैक्टर करने के लिए पूरी तरह से उत्सुक नहीं हैं, लेकिन आप क्या कर सकते हैं ...

आईओएस के लिए, मेरा मानना ​​​​है कि नेविगेशन बार पर स्क्रॉल मोड को सक्षम करने के लिए चालू/बंद करने के लिए एक संपत्ति है। Android के लिए, आपको नए लेआउट (CoordinatorLayout, AppBarLayout, आदि) का उपयोग शुरू करना होगा। इस संबंध में एक्सएफ का एंड्रॉइड कार्यान्वयन काफी पुराना है क्योंकि यह अभी भी मुख्य कंटेनर के रूप में रिलेटिवलाउट का उपयोग कर रहा है। मुझे लगता है कि इस विशिष्ट मुद्दे के बारे में कहीं न कहीं एक एन्हांसमेंट टिकट है। मुझे शैल को विभिन्न स्क्रॉल मोड का समर्थन करना अच्छा लगेगा।

शेल CoordinatorLayout + AppBarLayout का उपयोग करता है और मूल रूप से इस समय स्क्रॉल दूर समर्थन को "अक्षम" करता है, हालांकि यह काम करता है। आईओएस स्क्रॉल ऑफ को लागू करना भी आसान है। दुर्भाग्य से UWP के नेविगेशन व्यू के पास इस सुविधा के लिए कोई समर्थन नहीं है।

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

उदाहरण, मुझे उदाहरण चाहिए :)

@ जसस्मिथ

मैं डेटा कनेक्शन स्थिति में परिवर्तन सुनने के लिए James Montemagno's Connectivity प्लगइन का उपयोग कर रहा हूं। जब इंटरनेट कनेक्शन गिर जाता है, तो एक अधिसूचना प्रदर्शित करना अच्छा होता है जो इंटरनेट के ऑनलाइन वापस आने तक स्लाइड/फीकी या स्थिर रहती है।

इंस्टाग्राम पर इस नोटिफिकेशन को नेविगेशन बार के ठीक नीचे रखा गया है। Tumblr पर, यह नीचे नेविगेशन बार के ठीक ऊपर है। YouTube पर, अजीब तरह से यह नीचे नेविगेशन बार के नीचे है। शायद ऐसा कुछ शेल का हिस्सा हो सकता है?

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

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

जहाँ तक स्थिरता, लचीलेपन आदि के बारे में तर्क दिए जा रहे हैं, 1.0 से आने वाली पुरानी वास्तुकला से छुटकारा पाए बिना, मुझे नहीं लगता कि उन चीजों को हासिल करना संभव है। मैं ListView2 के बहुत पक्ष में हूं।

@ जसस्मिथ

• क्या आपके पास अभी तक नए ListView के लिए एन्हांसमेंट टिकट है?
• आपको क्या लगता है कि v1.0 कब बाहर होगा? क्या कोई मौका है कि हम इसे ईओवाई द्वारा देख सकते हैं?

साथ ही, मुझे टीम के अंडरसाइज़ होने की भी यही चिंता है। वास्तव में, मैं इसे पहले भी उठा चुका हूं। मुझे उम्मीद है कि टीम भविष्य में बहुत बड़ी हो सकती है। 🙏 @davidortinau @migueldeicaza

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

मैं शेल में इस प्रकार के टोस्ट नोटिफिकेशन जोड़ने के लिए तैयार हूं, बस यह पता लगाने की कोशिश कर रहा हूं कि इसे कैसे किया जाना चाहिए।

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

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

किसी एप्लिकेशन के अंदर कहीं भी सामग्री (पृष्ठों सहित) डालना संभव होना चाहिए।

क्या आप कृपया ऐसा कर सकते हैं ताकि आप किसी एप्लिकेशन के अंदर जहां चाहें मनमाने ढंग से पेज डाल सकें?

मैं @jsiemens को लेकर थोड़ा उत्सुक

@dansiegel कम से कम व्यक्तिगत रूप से, मैं शायद एक निश्चित व्यूपोर्ट थ्रेसहोल्ड (जैसे GMaps वर्तमान में करता है) के नीचे स्क्रॉल व्यू को स्थानांतरित करने और कॉम्पैक्ट करने के लिए वीएसएम या कुछ समकक्ष का उपयोग करता हूं। यह देखने के लिए उत्सुक होगा कि नेविगेशन और राज्य प्रबंधन इसके लिए कैसे काम करेगा।

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

उपयोगकर्ता एकल नेविगेशन मील के पत्थर के रूप में टैबलेट और छोटे दृश्य को 'देखेगा'। छोटे पर्दे पर दो मील के पत्थर हो सकते हैं। नेविगेशन, किसी भी तरह, उत्तरदायी होना होगा।

डेवलपर्स के रूप में हमें निश्चित रूप से उस उत्तरदायी प्रकृति को संभालना होगा क्योंकि यह एक प्रासंगिक चीज है। हम इसे संभालने के लिए ढांचे पर भरोसा नहीं कर सकते हैं, लेकिन ढांचे को इसका समर्थन करने की जरूरत है।

@jsiemens @dansiegel जिस तरह से मैं इसे वर्तमान में संभालता हूं वह ControlTemplate s का उपयोग कर रहा है। मैं अपना "पृष्ठ" - प्रकार की सामग्री ContentView s के रूप में बनाता हूं और उन्हें ContentPage ( NavigationPage ) में होस्ट करता हूं जो मंच के लिए उपयुक्त है। ControlTemplates का उपयोग करने का अर्थ है कि मेरे पास एकाधिक बाध्य ContentViews (आमतौर पर Grid ताकि मैं सामान ओवरले कर सकूं) जो ControlTemplate में बाध्यकारी गुणों के आधार पर चालू/बंद हो जाते हैं DynamicResource s का भी उपयोग कर सकते हैं)। अंतिम परिणाम एक वेब साइट पर सीएसएस पैनल की तरह थोड़ा सा काम करता है, जहां सभी सामग्री पृष्ठ में होती है लेकिन यह सभी समय पर दिखाई नहीं देती है। ControlTemplate s इसके लिए जादुई हैं और मैं चाहूंगा कि उनकी क्षमताओं को शेल में संरक्षित रखा जाए।

@dansiegel मैं बस एक अलग शेल को लोड करने के लिए इसे कोड करूंगा, यह इस बात पर निर्भर करता है कि ऐप फोन पर टैबलेट/लैपटॉप/डेस्कटॉप पर चल रहा था या नहीं।

@jsiemens यह ठीक है, मेरी टिप्पणी केवल आपके विचार को और परिशोधित करने के लिए आगे की बातचीत और महत्वपूर्ण सोच को बढ़ावा देने के लिए है। कुछ मायनों में मैं लगभग आपकी अवधारणा को यहां बताऊंगा, कि प्रत्येक पृष्ठ अनिवार्य रूप से एक मल्टीपेज हो सकता है जहां एक पृष्ठ को किसी दिए गए नियंत्रण से जोड़ा जा सकता है और सामान्य नेविगेशन बनाम एक और दृश्य के रूप में अधिक व्यवहार किया जा सकता है।

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

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

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

क्या आप मूल दृश्य प्रति xamarin दृश्य बनाने से अलग कर सकते हैं यदि किसी लेआउट के भीतर सभी सबव्यू को मूल विजेट का उपयोग किए बिना प्रस्तुत किया जा सकता है? एक स्वचालित हाइब्रिड स्पंदन/ज़ामरिन दृष्टिकोण की तरह जहां एक्सएफ दृश्यों के समूह एक ही सतह पर प्रस्तुत किए जाते हैं और केवल एक मूल दृश्य पर ब्लिट आउट होते हैं। एंड्रॉइड व्यू निर्माण/लेआउट से बचना सी # -> जावा इंटरऑप लागत उपयोगी होगी।

चालू!!

@jassmith शेल समाप्त होने के बाद, क्या ड्रा एक साथ मान्य होगा?

शेल मैकोज़ और डब्ल्यूपीएफ का समर्थन करने जा रहा है?

@juepiezhongren प्रारंभिक लक्ष्य आईओएस और एंड्रॉइड हैं। उसके बाद अन्य प्लेटफॉर्म को प्राथमिकता दी जाएगी।

आरेखण वर्तमान में विकसित नहीं किया जा रहा है। अपने वर्तमान विनिर्देश में, यह शेल के साथ मान्य होगा। जैसे आज आप Xamarin.Forms के भीतर SkiaSharp और Skia आधारित नियंत्रणों का उपयोग कर सकते हैं।

हम सामग्री और अन्य डिजाइन शैलियों के लिए सुसंगत डिजाइन का समर्थन करने के लिए अन्य मूल रणनीतियों पर काम कर रहे हैं।

@davidortinau क्या शेल RTL सपोर्ट को बेहतर बनाता है?

किस तरह से बेहतर? आज आप RTL समर्थन से क्या खो रहे हैं? हमें इसे हर जगह संबोधित करना चाहिए।

ईमानदार होने के लिए, मैंने कुछ समय में एक्सएफ विकास नहीं किया है, लेकिन अधिकांश सीमाएं ज्ञात हैं: #1222 और #2448 पर एक नज़र डालें

शायद शेल इन सामान्य सीमाओं में मदद कर सकता है:

• नेविगेशनपेज बटन स्थान, टूलबार आइटम स्थान, और ट्रांज़िशन एनीमेशन वर्तमान में डिवाइस लोकेल द्वारा नियंत्रित किया जाता है, फ़्लोडायरेक्शन सेटिंग नहीं।
• फ़्लोडायरेक्शन के लिए वैश्विक ऐप सेटिंग

और कुछ अन्य प्लेटफ़ॉर्म-विशिष्ट सीमाएँ

Xamarin.Forms की सबसे महत्वपूर्ण विशेषता। इसे पहले इस तरह बनाया जाना चाहिए था।

ड्राइंग के बिना, xf में अभी भी काफी कमी है

@juepiezhongren

बस स्कीशर्प का प्रयोग करें

@makayn मैंने इसे बहुत इस्तेमाल किया
https://github.com/xamarin/Xamarin.Forms/issues/1789
यूनिवर्सल लुकिंग है जरूरी

एडम फड़फड़ाने लगा, यह वास्तव में एक्सएफ के लिए एक दुखद संकेत है, जहां ज़ामरीन मूल रूप से आसानी से बेहतर प्रतिष्ठा प्राप्त कर सकता था

xamarin.native किसी भी अन्य क्रॉस-प्लेटफ़ॉर्म समाधान की तुलना में xf के लिए बहुत अधिक ठोस है, जो भी देशी या स्पंदन प्रतिक्रिया करता है। डॉटनेट प्रेमी के रूप में, xf की वर्तमान स्थिति हमेशा मेरे लिए थोड़ी निराशाजनक होती है।

@juepiezhongren

यह चर्चा व्यर्थ है, यदि यह फ़्लटर का उपयोग करके आपकी आवश्यकताओं को पूरा नहीं करती है, तो यह हमें कई प्लेटफ़ॉर्म (iOS और Android केवल फ़्लटर आदि के साथ) पर ऐप्स वितरित करने की अनुमति देती है, ये परिवर्तन एक सुसंगत रूप देंगे और अधिक प्राप्त करने योग्य महसूस करेंगे।

साधारण छोटी सी शिकायत, बस इतना ही। खोल के लिए अभी भी हुर्रे!

मैं सहमत हूं कि स्कीया को फॉर्म एपीआई (जैसे टेलीरिक ने किया है) में अधिक बेक किया जाना अच्छा होगा। मै अवश्य ही सहमत हूं।

मुझे खुशी है कि वे हालांकि शेल और कलेक्शन व्यू में प्रयास कर रहे हैं।

हाय, कृपया सभी कहें, मैं कैसे उपयोग कर सकता हूं, दाएं से बाएं भाषा के लिए दाएं से फ़्लायआउट करें।

नमस्ते,

मुझे यह विचार पसंद है, लेकिन मेरे पास कुछ छोटे इनपुट हैं।
मुझे लगता है कि मुझे थोड़ी देर हो गई है, लेकिन नामकरण थोड़ा भ्रमित करने वाला है, मुझे लगता है।

1. आइटम, अनुभाग और सामग्री सभी, वास्तव में सामान्य नाम हैं। यह अभी स्पष्ट नहीं है कि वे किस संबंध में हैं। क्या यह कंटेंट => सेक्शन => आइटम या सेक्शन => कंटेंट => आइटम, या आइटम => सेक्शन => कंटेंट है।
   तो हम एक और विशिष्ट नाम ढूंढकर, कुछ और निर्दिष्ट कर सकते हैं कि अलग-अलग "चीजें" क्या हैं।

2. यह मुझे अगले इनपुट की ओर ले जाता है। हमारे पास सभी आंतरिक वस्तुओं के लिए कंटेनर के रूप में एक शेल है। तो क्या हम अंदर "ShellItem" के बजाय "आइटम" जैसे सीधे आगे के नामों का उपयोग नहीं कर सकते। शेल्टेम, शेलसेक्शन आदि सभी "चीजों" को कॉल करना मेरे लिए थोड़ा अनावश्यक लगता है, लेकिन ठीक है। यह बहस योग्य है।

आहा

क्या यह अभी भी 2018 में रिलीज़ होगी?

हमारे पास अभी एक पूर्वावलोकन रिलीज़ उपलब्ध है! कुछ बेहतरीन नमूनों के लिए https://blog.xamarin.com/connect-2018-xamarin-announcements/ पर एक नज़र डालें।

क्या हमें वास्तव में Android 9 की आवश्यकता है? ऐसा लगता है कि यह एक सीमा है।

यह सब बहुत अच्छा लगता है, लेकिन यह पूरी तरह से UI इंटरैक्शन पर आधारित प्रतीत होता है।
मुझे लगता है कि जब मैं इसे आजमाऊंगा तो मुझे पता चल जाएगा, लेकिन मेरी प्रारंभिक चिंता यह है कि मैं व्यावसायिक तर्क या कोड से नेविगेशन कैसे चला सकता हूं जैसे मैसेजिंग एक ब्लूटूथ कनेक्टेड डिवाइस से पृष्ठ परिवर्तन को ट्रिगर करता है, जबकि चिंताओं का एक अच्छा अलगाव बनाए रखता है?

@hassanrahimi

हाय, कृपया सभी कहें, मैं कैसे उपयोग कर सकता हूं, दाएं से बाएं भाषा के लिए दाएं से फ़्लायआउट करें।

जबकि RTL समर्थित है, फ़्लायआउट मेनू अभी भी बाईं ओर दिखाई देता है। यह एक वर्तमान सीमा है।

क्या नीचे के टैबबार यूआई को कस्टमाइज़ करना संभव है?

क्या खोल में नियंत्रण जोड़ना संभव है जो खोल के अंदर नेविगेट करते समय पुनः लोड नहीं होता है? उदाहरण के लिए एक FAB..

@stfnilsson निचला

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

पहला: मैंने पहले अपने स्वयं के खोल का उपयोग किया है, अब मैं बहुत आसानी से अपने स्वयं के खोल को अपने साथ बदल सकता हूं और यह बहुत बेहतर है। मुझे वास्तव में यह पसंद है।

शायद मेरे मामले कस्टम के लिए हैं और खोल से संबंधित नहीं हैं लेकिन:

मामला एक:
अगर मैं एक बहुत ही कस्टम मेनू के साथ एक ऐप बनाना चाहता हूं, ऐप के प्रत्येक कोने में एक मेनू बटन, मैं बटन कैसे जोड़ूं ताकि यह खोल का हिस्सा हो (जैसे ओवरले या बिलबोर्ड)। हर बार जब मैं नेविगेट करता हूं तो इसे फिर से प्रस्तुत नहीं करना चाहता।

मामला दो:
मैं खोल का उपयोग करना चाहता हूं लेकिन नीचे के टैबबार को कस्टमाइज़ करना चाहता हूं ताकि मध्य बटन ऊंचा हो (जिसे केंद्र उठाया गया बटन कहा जाता है)। क्या मुझे रेंडरर का उपयोग करना चाहिए और बॉटम नेविगेशन व्यू को कस्टमाइज़ करना चाहिए?

क्या आपको लगता है कि मुझे इस तरह के विशेष मामलों के लिए खोल का उपयोग करना चाहिए?

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

यहाँ मेरी प्रतिक्रिया है। मैं यह परीक्षण करता हूं ( Xamarin.Forms 4.0.0.8055-pre1 ):

   <Shell.FlyoutHeader>
        <local:FlyoutHeader />
    </Shell.FlyoutHeader>

    <ShellItem Title="Home" Icon="home.png">
        <ShellSection>
            <ShellContent>
                <local:MainPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

    <ShellItem Title="Notifications" Icon="notification.png">
        <ShellSection>
            <ShellContent Title="Recent">
                <local:NotificationPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

    <ShellItem Title="Test" Icon="icon.png">
        <ShellSection Title="Home" Icon="home.png">
            <ShellContent>
                <local:MainPage />
            </ShellContent>
        </ShellSection>

        <ShellSection Title="Notifications" Icon="notification.png">
            <ShellContent Title="Recent">
                <local:NotificationPage />
            </ShellContent>

            <ShellContent Title="Settings">
                <local:SettingsPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

जब हम हैमबर्गर मेनू पर टैप करते हैं तो सभी काम करते हैं। हालांकि, अगर हम Test मेनू पर जाते हैं और Home और Notifications आगे पीछे टैप करते हैं और Recent या Settings बीच चयन करते हैं, तो पेज क्रमशः खुलेंगे। लेकिन फिर, जब हम फिर से हैमबर्गर मेनू पर टैप करते हैं, तो ऐप क्रैश हो जाता है।

ShellItem में ShellContent के समूह के लिए शीर्षक दिखाने के लिए हम GroupHeaderTemplate का उपयोग कैसे कर सकते हैं?

कई उपयोगकर्ताओं के लिए यह स्पष्ट है कि Xamarin प्रपत्र अपने वर्तमान आकार और जटिलता पर बनाए रखने योग्य नहीं है, इसलिए कुछ भी नया करने से जटिलता को बढ़ाने के बजाय कम करना चाहिए।

@jassmith का इरादा यह है कि आप गैर-शैल जाने से बेहतर नहीं हैं। ... इरादा यह सुनिश्चित करना है कि शेल रेंडरर्स वास्तव में आसानी से कॉन्फ़िगर और समझदार हैं।

यदि शेल पूरा हो जाता है, तो भविष्य में क्या मूल्यह्रास किया जा सकता है, और जब ऐसा किया जाता है तो क्या ज़ामरीन फॉर्म की समग्र जटिलता कम हो जाती है? क्या कंटेंटपेज को छोड़कर अन्य सभी पेजों का मूल्यह्रास हो जाएगा?

रेपो से ज्यादा से ज्यादा फायदा उठाने की रणनीति होनी चाहिए। कोर रेपो की स्थिरता और रखरखाव सबसे महत्वपूर्ण चीज है।

इसके अलावा यदि कोई कारण है कि शेल को शेलपेज नहीं कहा जाता है? अन्य पेज वर्गों के नाम "पेज" में समाप्त होते हैं।

शेल के लिए वर्तमान विज्ञापन (https://blog.xamarin.com/xamarin-forms-4-0-preview/ में) आशाजनक नहीं है।

1. आपके एप्लिकेशन आर्किटेक्चर के उच्च स्तर को व्यक्त करने का एक सरल तरीका

यह Xamarin को इसके वास्तविक उद्देश्य से परे ले जाता है। एप्लिकेशन आर्किटेक्चर के लिए ज़ामरीन की आवश्यकता नहीं है। यह केवल लेआउट के बारे में होना चाहिए।

1. सामान्य UI नेविगेशन पैटर्न का एक पदानुक्रम जो आपके लक्षित मोबाइल प्लेटफ़ॉर्म के अनुकूल है

मुझे उम्मीद है कि "मोबाइल" यहां गलत प्रिंट है क्योंकि Xamarin.Forms डेस्कटॉप को भी कवर करता है।

1. एक मजबूत नेविगेशन सेवा

Xamarin.Forms को नेविगेशन की आवश्यकता नहीं है। यदि वर्तमान नेविगेशन काम नहीं कर रहा है तो इसे केवल मूल्यह्रास किया जा सकता है क्योंकि नेविगेशन के कई अच्छे दृष्टिकोण हैं जिनमें कुछ भी बनाने की आवश्यकता नहीं है।

हाय @charlesroddie , प्रतिक्रिया के लिए धन्यवाद।

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

Xamarin.Forms में आज आप टैब और मेनू आइटम और विभिन्न संयोजनों के साथ TabbedPage, MasterDetailPage का उपयोग करके अपने एप्लिकेशन आर्किटेक्चर, सामग्री के पदानुक्रम का पहले ही वर्णन कर चुके हैं। यहाँ मेरा मतलब "वास्तुकला" से है। शेल उन पैटर्न को सरल और प्रतिस्थापित करता है (यदि आप शेल का उपयोग करना चुनते हैं)।

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

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

यदि आप डेस्कटॉप को लक्षित कर रहे हैं, तो आप शेल का उपयोग नहीं करेंगे... मेरा मानना ​​है कि शेल ऐप्स को किसी भी प्लेटफ़ॉर्म पर ले जाने के लिए बहुत अच्छी स्थिति में है

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

Xamarin बहुत सी फीचर रेंगना दिखा रहा है, जैसे css। इससे पूरी परियोजना को खतरा हो सकता है और मुझे आशा है कि संगठन के कुछ निर्णयकर्ता इसे समझेंगे।

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

Xamarin बहुत सी फीचर रेंगना दिखा रहा है, जैसे css। इससे पूरी परियोजना को खतरा हो सकता है और मुझे आशा है कि संगठन के कुछ निर्णयकर्ता इसे समझेंगे।

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

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

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

मेरे पास कुछ भविष्य की परियोजनाएं भी हैं जहां मुझे यूडब्ल्यूपी की आवश्यकता नहीं है और मैं उन पर शैल का उपयोग करने की उम्मीद कर रहा हूं क्योंकि मुझे लगता है कि इससे मेरे लिए उन्हें उत्पादन करने में काफी तेजी आएगी।

मैं केवल 2.3 रिलीज के बाद से एक्सएफ का उपयोग कर रहा हूं और निश्चित रूप से और अधिक काम करने के लिए ... मंच के रूप में अब मौजूद है, बहुत स्थिर हो गया है ... कम से कम मेरे लिए ... इसलिए मुझे इससे कोई सरोकार नहीं है अतिरिक्त रखरखाव और ऐतिहासिक रूप से मुझे ऐसा लगता है कि XF टीम रखरखाव के बोझ के प्रति बहुत सचेत है ... इसलिए मुझे विश्वास है कि उनके पास यह नियंत्रण में है।

मंच के लिए महान जोड़ के लिए धन्यवाद!

चीजों को करने के नए तरीके जोड़ने से नए देव भ्रमित होंगे जब तक कि पुराने तरीकों का मूल्यह्रास न हो जाए और पुराने दस्तावेज़ों को हटा न दिया जाए।

स्पंदन बहुत आसान है। कोई मार्कअप भाषा नहीं, कोड में सब कुछ। Xamarin अधिक जटिल और छोटी गाड़ी बनकर प्रतिस्पर्धा करने वाला नहीं है। यह समान फ़ोकस के साथ फ़्लटर (अधिक प्लेटफ़ॉर्म) से अधिक करके प्रतिस्पर्धा करेगा।

यह इस बिंदु पर पहुंच रहा है कि हमें Xamarin.Core की आवश्यकता है, जिसमें XAML या CSS या प्रॉपर्टी बाइंडिंग शामिल नहीं है, जिसमें बेस क्लास से परे पेज या शेल शामिल नहीं हैं, इस कोर के प्रदर्शन और स्थिरता पर ध्यान देने के साथ। यदि कुछ देव बग की वर्तमान दर को स्वीकार करने की कीमत पर इन सुविधाओं को चाहते हैं तो वे Xamarin.Extensions का उपयोग कर सकते हैं जहां वे सभी चीजें रहती हैं।

चीजों को करने के नए तरीके जोड़ने से नए देव भ्रमित होंगे जब तक कि पुराने तरीकों का मूल्यह्रास न हो जाए और पुराने दस्तावेज़ों को हटा न दिया जाए।

स्पंदन बहुत आसान है। कोई मार्कअप भाषा नहीं, कोड में सब कुछ। Xamarin अधिक जटिल और छोटी गाड़ी बनकर प्रतिस्पर्धा करने वाला नहीं है। यह समान फ़ोकस के साथ फ़्लटर (अधिक प्लेटफ़ॉर्म) से अधिक करके प्रतिस्पर्धा करेगा।

यह इस बिंदु पर पहुंच रहा है कि हमें Xamarin.Core की आवश्यकता है, जिसमें XAML या CSS या प्रॉपर्टी बाइंडिंग शामिल नहीं है, जिसमें बेस क्लास से परे पेज या शेल शामिल नहीं हैं, इस कोर के प्रदर्शन और स्थिरता पर ध्यान देने के साथ। यदि कुछ देव बग की वर्तमान दर को स्वीकार करने की कीमत पर इन सुविधाओं को चाहते हैं तो वे Xamarin.Extensions का उपयोग कर सकते हैं जहां वे सभी चीजें रहती हैं।

@charlesroddie उन्होंने ऊपर कुछ भी नहीं किया है, क्या आप XAML का उपयोग करने के लिए मजबूर हैं। Xamarin.Forms में XAML वैकल्पिक है - यह हमेशा से रहा है। मैं हमेशा अपना Xamarin.Forms ऐप्स UI केवल कोड का उपयोग करता हूं - प्रत्येक "टैग" जो आप ऊपर देखते हैं वह एक वर्ग है जिसे संबंधित माता-पिता में स्थापित और जोड़ा जा सकता है।
यदि कोडित UI Xamarin.Forms के साथ संभव नहीं होते तो मैं इसका उपयोग नहीं करता - पूर्ण विराम!

सामान्य रूप से पुन: स्पंदन - यह बहुत अच्छा है, लेकिन मुद्दा इसका एकमात्र आईओएस और एंड्रॉइड है - जो मेरे लिए काम नहीं करता है क्योंकि मुझे मैकोज़, विंडोज 7/8.1 और लिनक्स को लक्षित करने की आवश्यकता है। ज़ामरीन से बेहतर कुछ नहीं।इस पर फॉर्म!

क्या मैं कस्टम व्यू को मास्टर पेज के रूप में सेट कर सकता हूं, इसमें शामिल करना बहुत महत्वपूर्ण बात है, हम केवल मेनूइटम या पेजों को पसंद नहीं करेंगे

Xamarin मैक और uwp सपोर्ट?

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

आप व्यू मॉडल के लिए INavigatedAware भी लागू कर सकते हैं और डेटा लोड करने, सेवाओं को सक्षम/अक्षम करने आदि जैसे विशिष्ट उपयोग मामलों को संभाल सकते हैं।

मैं कुछ इसी तरह जोड़ना चाहता था इसलिए मेरा पहला अनुमान OnNavigating और OnNavigated शैल घटना था लेकिन Current और Target एक ShellItem को उजागर नहीं करते हैं, इसलिए यह संभव नहीं है बाइंडिंग कॉन्टेक्स्ट को सम्मेलन द्वारा सेट करने के लिए या दृश्य मॉडल ईवेंट ट्रिगर करने के लिए?

इसके लिए कोई सुझाव?

संपादित करें: #5166 द्वारा ट्रैक किया गया।

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

@vincentwx मैं सहमत हूँ। आइकन फोंट का उपयोग करना बहुत आसान है और परिचित भी हैं।

@vincentwx बिल्कुल @stevehurcombe। मैं इसे अभी एक ऐप में कर रहा हूं:

<ShellItem>
    <ShellContent Title="Upcoming" 
                      ContentTemplate="{DataTemplate pages:UpcomingPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Rocket}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>

        <ShellContent Title="Latest" 
                      ContentTemplate="{DataTemplate pages:LatestPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Book}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>

        <ShellContent Title="Company" 
                      ContentTemplate="{DataTemplate pages:CompanyPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Building}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>
    </ShellItem>

मैंने इसका उपयोग सभी ग्लिफ़ का एक स्थिर वर्ग बनाने के लिए किया: https://andreinitescu.github.io/IconFont2Code/

IOS रंग के साथ एक बग है जिसे ठीक करने की आवश्यकता है। #5071

Xamarin मैक और uwp सपोर्ट?

इस समय नहीं @mdonogma। हम अतिरिक्त प्लेटफार्मों का समर्थन करने के लिए रुचि/मांग एकत्र कर रहे हैं, लेकिन इस समय यह हमारे रोडमैप पर नहीं है।

@davidortinau कोड और लिंक के लिए धन्यवाद।

एंड्रॉइड 8.0 में, मैं शेल सामग्री में होस्ट किए गए WebView तत्व में वेबपृष्ठ स्क्रॉल नहीं कर सकता। लेकिन यह ज़ामरीन शेल के बिना ठीक काम करता है।

ज़ामरीन फॉर्म 4.0.0.135214-pre4

क्या नीचे के टैब और शीर्षक दृश्य के FontFamily को बदलने का कोई आसान तरीका है?

@varyamereon मैंने कल ऐसा किया था। FontFamily सेट करने में सक्षम होने के लिए शेल का विस्तार करें।
मैं जल्द ही अपने विस्तारित शेल को GitHub पर प्रकाशित करूंगा लेकिन:

एक कस्टम शेल बनाएं:

<Shell
    x:Class="X.Mobile.App.Features.AppShell.AppShell"

फिर एक शेल कस्टम रेंडरर बनाएं:

[assembly: ExportRenderer(typeof(AppShell), typeof(AppShellRenderer))]

namespace X.Mobile.App.iOS.Renderers
{
    [Preserve(AllMembers = true)]
    public class AppShellRenderer : ShellRenderer
    {
        protected override IShellItemRenderer CreateShellItemRenderer(ShellItem item)
        {
            return new CustomMenuRenderer(this)
            {
                ShellItem = item
            };
        }

फिर:

 namespace X.Mobile.App.iOS.Renderers
 {
     [Preserve(AllMembers = true)]
     public class CustomMenuRenderer : ShellItemRenderer
     {
         private SKCanvasView _skiaSharpPaintView;
         public CustomMenuRenderer(IShellContext context) : base(context)
         {
         }

public override void ViewDidLoad()
{
}           
public override void ViewWillLayoutSubviews()
{
{

फिर फॉन्ट फ़ैमिली सेट करने के लिए: _(इसे अक्सर न करें)_

var txtAttributes = new UITextAttributes
            {
                Font = UIFont.FromName("MyriadPro-Semibold", 12.0F)
            };
            foreach (var uiTabBarItem in TabBar.Items)
            {
                uiTabBarItem.SetTitleTextAttributes(txtAttributes, UIControlState.Normal);
            }

कोई भी जिसने नीचे से पॉपअप के समर्थन के साथ शैल को बढ़ाया है (बॉटमशीट)?

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

क्या किसी सूची को Shell.MenuItems से बाइंड करने का समर्थन है? या मुझे BindableLayout का उपयोग करना चाहिए? कभी-कभी मुझे डेटाबेस से एक सूची लोड करने और मेनू के रूप में इनका उपयोग करने की आवश्यकता होती है। उनका दृश्य समान है, लेकिन चयनित मेनू के आधार पर भिन्न डेटा लोड करते हैं।

शेल का उपयोग करते समय एंड्रॉइड में ऑफस्क्रीनपेज लिमिट को बदलने का कोई तरीका है? यह दुर्भाग्यपूर्ण है जो मेरे ऐप के लिए बहुत महत्वपूर्ण है और मुझे शेल के साथ आगे बढ़ने से रोक रहा है।

धन्यवाद!

कुछ सुविधा अनुरोध:

1. शेल स्तर पर, सभी पृष्ठ शीर्षकों के लिए FontFamily सेट करें।
   जैसे

2. शेल स्तर पर, सभी पृष्ठ शीर्षकों/एनएवी बार आदि के लिए शीर्षक/एनएवी पृष्ठभूमि छवि सेट करें।
   जैसे

समूह व्यवहार मेरे लिए pre4 में काम नहीं करता है:

<ShellItem GroupBehavior="ShowTabs" FlyoutIcon="stuff.png" Title="Discussion">...
का परिणाम:

xxx/शैल/शैल.xaml(14,14): त्रुटि: स्थिति 108:14। 'ग्रुपबिहेवियर' के लिए कोई प्रॉपर्टी, बाइंडेबल प्रॉपर्टी या इवेंट नहीं मिला, या वैल्यू और प्रॉपर्टी के बीच बेमेल टाइप नहीं मिला।

और GroupHeaderTemplate कुछ भी नहीं करता है, लेकिन यह सुनिश्चित नहीं है कि इसका उपयोग कैसे किया जाता है, या सक्षम किया जाता है।

मैं MenuItems को जोड़ने/निकालने का प्रयास कर रहा हूं, जो सफलतापूर्वक MenuItems.Add(item) के माध्यम से आइटम जोड़ता है, लेकिन, जब फ्लाईआउट फिर से प्रदर्शित होता है तो कोई परिणाम नहीं दिखाया जाता है। क्या ऐसा करने का यह सही तरीका है?

मुझे MenuItems में हेरफेर करने का कोई उल्लेख नहीं दिख रहा है, लेकिन, शैल मेरे लिए काफी बेकार है (और मैं ऊपर @puppetSpace सहित कई अन्य लोगों को सोच रहा हूं) जब तक कि इन वस्तुओं को आपके व्यावसायिक तर्क के आधार पर गतिशील रूप से बनाए रखा जा सके।

मैं dbwelch से सहमत हूं कि सीएस फ़ाइल में प्रोग्रामिक रूप से खोल बदलने में सक्षम होना बहुत महत्वपूर्ण है। न केवल मेनू आइटम के लिए, बल्कि ShellItems और ShellSections के लिए भी।

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

@KyleTraynor इसके लिए कहीं न कहीं एक खुला मुद्दा है। आपको अपने आईओएस संसाधन फ़ोल्डर में 3bar.png और [email protected] छवियों को मैन्युअल रूप से कॉपी करना होगा और सुनिश्चित करना होगा कि वे प्रोजेक्ट में बंडल आइटम के रूप में शामिल हैं।

स्रोत में मुझे मिली छवियां संलग्न हैं:

@melucas मदद के लिए धन्यवाद! मैं इसे ठीक करने की कोशिश में पागल हो रहा था। बहुत अच्छा काम करता है।

क्या आपको पता है कि शेल का उपयोग करते समय मैं Android के लिए OffscreenPageLimit कैसे सेट कर सकता हूं?

मेरे पास 1 शैलसेक्शन के अंदर 4 शैल सामग्री के द्वारा बनाए गए शीर्ष टैब पृष्ठ हैं, और यह आईओएस पर बहुत अच्छा काम करता है, लेकिन एंड्रॉइड पर पेज उनके बीच स्वैप करते समय पुनः लोड होते हैं जो मुझे नहीं चाहिए। आम तौर पर अपने टैबबेडपेज के साथ, मैं इस समस्या को ठीक करने के लिए ऑफस्क्रीनपेज लिमिट सेट कर सकता था, लेकिन मुझे शैल के साथ ऐसा करने का कोई तरीका नहीं मिल रहा है।

@davidortinau क्या हमारे पास पृष्ठ शीर्षक, नीचे और शीर्ष टैब पर फ़ॉन्ट परिवार सेट करने का विकल्प हो सकता है? प्रत्येक प्रोजेक्ट में मुझे फोंट बदलने के लिए आईओएस और एंड्रॉइड के लिए कस्टम रेंडरर्स बनाना होगा।

इसलिए, चूंकि फ्लाईआउट शेल में आइटम को वास्तव में बदलने की क्षमता होने पर मेरी पोस्ट पर कोई प्रतिक्रिया नहीं हुई है, शायद यह कार्यक्षमता दायरे में नहीं है, या शायद, उम्मीद है कि एक बग माना जा रहा है?

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

बस जिज्ञासु @jassmith , क्या वे लोग हैं जिन्होंने इस मंच में विशिष्ट कुंजी बनाई है या यह सिर्फ डेवलपर प्रतिक्रिया के लिए है?

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

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

निचली पंक्ति, समस्या दर्ज करें

@dbwelch @ChaseFlorell मैंने यहां एक मुद्दा खोला: https://github.com/xamarin/Xamarin.Forms/issues/5428

@davidortinau क्या हमारे पास पृष्ठ शीर्षक, नीचे और शीर्ष टैब पर फ़ॉन्ट परिवार सेट करने का विकल्प हो सकता है? प्रत्येक प्रोजेक्ट में मुझे फोंट बदलने के लिए आईओएस और एंड्रॉइड के लिए कस्टम रेंडरर्स बनाना होगा।

@jamiewest सुविधा अनुरोध सबमिट करें! धन्यवाद! https://github.com/xamarin/Xamarin.Forms/issues/new?assignees=&labels=t%2Fenhancement+%E2%9E%95&template=feature_request.md&title=%5Benhancement%5D+Your+IDEA%21

क्या UseSwipeGesture सुविधा लागू हो सकती है?
ऐसा लगता है कि अब ShellItem क्लास में ओपेरा के लिए ShellAppearance प्रॉपर्टी नहीं है।
लेकिन अब Android में, The Shell's Tabs TabPage की तरह नहीं हैं (TabPage डिफ़ॉल्ट रूप से स्वाइप कर सकता है।)

    <ShellItem.ShellAppearance>
      <MaterialShellAppearance NavBarCollapseStyle="Full" TabBarCollapseStyle="Full" UseSwipeGesture="false">
    </ShellItem.ShellAppearance>

@jingliancui , भाई कुई, क्या कोई qq या WeChat है?

@juepiezhongren नमस्ते, आप मेरे साथ चैट करने के लिए इस qq समूह में शामिल हो सकते हैं 313308215

क्या हम RTM पर UWP के लिए शेल और विजुअल सपोर्ट आते देखेंगे?

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

मुझे लगता है कि मैं जो अनुरोध कर रहा हूं वह यह है कि नई सुविधाएं, जैसे * शैल, को अनुकूलन और विस्तारशीलता को ध्यान में रखकर भेज दिया गया है। ऐसी बहुत कम स्थितियाँ हैं जहाँ हमें सरल लगने वाली चीजों को करने के लिए रेंडरर्स, व्यवहार, ट्रिगर आदि की एक श्रृंखला बनाने की आवश्यकता नहीं थी।

आप लोग जो कुछ भी लेकर आएं, कृपया वह सब कुछ करें जो आप कर सकते हैं ताकि हमारे लिए हमारे Xamarin.Forms ऐप्स को अन्य देशी ऐप्स की तरह ही अच्छा बनाना आसान हो सके! ऐसा लगता है कि यह सुविधा हमें आधुनिक दिखने वाले XForms ऐप्स के लिए एक बेहतर लॉन्चपैड देगी!

क्या कोई स्रोत कोड है जो यह देखने के लिए उपलब्ध है कि यह शेल कैसे काम करता है, बजाय इसके कि कल्पना के आसपास अनुमान लगाया जाए? उदाहरण के लिए, हैमबर्गर आइकन को रंगने के लिए किस शैली का उपयोग किया जाता है, यदि वह उपलब्ध है। क्षमा करें, C#/Xamarin पर नया है, लेकिन, यदि कोड कहीं देखने योग्य होता, तो बहुत मदद करता।

@dbwelch आप यहीं GitHub पर स्रोत कोड ब्राउज़ कर सकते हैं। संबंधित कक्षाओं को देखने के लिए "टी" दबाएं और शैल टाइप करें। यह सबसे अच्छा प्रारंभिक बिंदु नहीं हो सकता है, हालांकि यदि आप सी #/ज़ामरिन के लिए नए हैं। मैं अनुशंसा करता हूं कि जब तक हम अधिक दस्तावेज प्राप्त न करें तब तक मेरे कुछ नमूने देखें:

https://github.com/davidortinau/Gastropods
https://github.com/davidortinau/ShellGallery
https://github.com/davidortinau/TheLittleThingsPlayground

दस्तावेज़: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell?tabs=android
एमएसडीएन लेख: https://msdn.microsoft.com/en-us/magazine/mt848639
ब्लॉग: https://blog.xamarin.com/xamarin-forms-4-0-preview/

@davidortinau धन्यवाद, लेकिन, मैंने सोचा कि यह अभी जारी किया गया कोड था जो उपलब्ध था, शैल कोड कहां है? मैंने 4.0, शैल, अन्य के लिए शाखाओं के नीचे देखा है, लेकिन, यह मुझसे छुपा रहा है! धन्यवाद!

@dbwelch https://github.com/xamarin/Xamarin.Forms/search?q=shell&unscoped_q=shell

उदाहरण के लिए Shell.cs यहाँ है

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

अद्यतन: मुझे अभी समस्या मिली है, और, ज़ाहिर है, यह कुछ भाग्यशाली कोड है जो टिंटकोलर जोड़ने के लिए समाप्त लॉन्चिंग में मौजूद है। दोह!

धन्यवाद सज्जनों, सहायता की सराहना करें!

मेरे पास फ्लाईआउट पैनल में कुछ आइटम दिख रहे हैं जो ठीक है। हालांकि, वर्तमान में पहले से ही शेल आइटम को छिपाने/दिखाने का एक तरीका नहीं है (आइटम सामग्री नहीं)। उदाहरण, मेरे पास एक कंटेंटपेज है और मैं सिर्फ शेल के अंदर नेविगेशन रखना चाहता हूं।

<local:DetailPage />

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

प्रस्तावना: मैं एक नया एटीएम हूँ। नहीं होने की कोशिश कर रहा है।

@davidortinau तो, मैं अपनी पहली Xamarin.Forms परियोजना में नेविगेशन, आदि जोड़ने के लिए इस शेल सुविधा को सीखने की कोशिश कर रहा हूं (वूट!) या नई रूटिंग कार्यक्षमता के माध्यम से एक ShellItem से अनुप्रयोग के अन्य भागों में अधिक पैरा। क्या यह बिल्कुल बात है? या हमें इसके बजाय MenuItem संग्रह के भीतर MenuItems का उपयोग करके कमांडिंग के साथ रहना चाहिए? यदि हमें फ्लाईआउट स्तर से 1 या अधिक मानों को पारित करने के लिए मेनूइटम का उपयोग करना चाहिए, तो ऐसा लगता है कि हम अब शेल पदानुक्रम के साथ अपने ऐप की संरचना नहीं कर सकते हैं क्योंकि हम इसके बजाय मेनूइटम का उपयोग कर रहे हैं? क्या हम कमांड पैरा के साथ MenuItems का उपयोग करने में इसे नहीं खोते हैं?

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

साथ ही, अगर यह इसके लिए गलत जगह है तो मैं माफी मांगता हूं। यदि ऐसा है तो कृपया मुझे सही जगह पर इंगित करें। धन्यवाद!

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

मैं यह भी सोच रहा था कि क्या हम यह परिभाषित कर सकते हैं कि फ़्लायआउट के भीतर MenuItems कहाँ स्थित हैं ताकि ShellItems शीर्ष पर पॉप न हों; और अगर एक दिन हमें अपने मेनू आइटम को एक संग्रह के हिस्से के रूप में परिभाषित करने की आवश्यकता नहीं है, ताकि वे ShellItems के साथ मिल सकें जैसे:
MenuItem
ShellItem
ShellItem
MenuItem
ShellItem
MenuItem
...
वह, या केवल ShellItems को किसी बिंदु पर पैरा पास करने में सक्षम बनाते हैं यदि वे पहले से नहीं कर सकते हैं।

मैं @anthcool के साथ

@anthcool बस मदद करने और यहाँ कुछ सुझाव देने की कोशिश कर रहा है जैसा कि मैंने इस समय किया था। एक नेविगेशन पैरामीटर वर्ग बनाएं जिसमें स्टैक सूची के रूप में readonly Stack<NavigationParameter> , अर्थात

public class Navigation
{
    readonly Stack<NavigationParameter> _stack = new Stack<NavigationParameter>();
...
    public Stack<NavigationParameter> Parameters => _stack;
}

नेविगेशन पैरामीटर है:

public class NavigationParameter : NameValueCollection { }

नेविगेट करते समय आप पुश से पहले पैरामीटर जोड़ सकते हैं, उदा:

    var p = new NavigationParameter { { nameof(SomePage), SomeObject } };
    Navigation.Parameters.Push(p);

एक बार जब आप दूसरे पृष्ठ पर पहुंच जाते हैं , तो बस मूल्य को पॉप करें और कुंजी की जांच करें।
ऊपर जैसा कुछ। उम्मीद है की वो मदद करदे।

@anthcool बस मदद करने और यहाँ कुछ सुझाव देने की कोशिश कर रहा है जैसा कि मैंने इस समय किया था। एक नेविगेशन पैरामीटर वर्ग बनाएं जिसमें स्टैक सूची के रूप में readonly Stack<NavigationParameter> , अर्थात

public class Navigation
{
    readonly Stack<NavigationParameter> _stack = new Stack<NavigationParameter>();
...
    public Stack<NavigationParameter> Parameters => _stack;
}

नेविगेशन पैरामीटर है:

public class NavigationParameter : NameValueCollection { }

नेविगेट करते समय आप पुश से पहले पैरामीटर जोड़ सकते हैं, उदा:

    var p = new NavigationParameter { { nameof(SomePage), SomeObject } };
    Navigation.Parameters.Push(p);

एक बार जब आप दूसरे पृष्ठ पर पहुंच जाते हैं , तो बस मूल्य को पॉप करें और कुंजी की जांच करें।
ऊपर जैसा कुछ। उम्मीद है की वो मदद करदे।

@rizamarhaban विचार के लिए धन्यवाद! वास्तव में आप इस पर ध्यान देने की सराहना करते हैं। शुक्रिया! मैं इसे जल्द ही यहां देखूंगा। फिर से, इसकी सराहना करें!

शैल और विजुअल यूडब्ल्यूपी का समर्थन नहीं करते सीखने से बहुत निराश हैं।

क्या यह युक्ति वास्तव में की गई है?
इसे बंद क्यों करें क्योंकि अब Tizen कार्यान्वयन है?
मैं इस धारणा के तहत था कि नेविगेशन कार्यक्षमता अभी भी समीक्षा के अधीन थी।

अभी भी कोई UWP समर्थन नहीं है। मुझे ज़ामरीन से अब तक की सबसे बड़ी निराशा हुई है।

@weitzhandler कृपया मुझे पॉल पर ईमेल करें। [email protected] यदि आप इस पर और सामान्य रूप से UWP पर चर्चा करना चाहते हैं। हम सक्रिय रूप से मंच की अनदेखी नहीं कर रहे हैं, लेकिन एंड्रॉइड और आईओएस प्रारंभिक कार्यान्वयन प्राप्त कर रहे हैं और यूडब्ल्यूपी के लिए शैल समर्थन की जांच सक्रिय रूप से चल रही है।

@mrlacey नाह, यह कहीं भी नहीं हुआ है! यह सिर्फ संबंधित मुद्दों से बंद होता रहता है। मैं

उन सभी के लिए जो यूडब्ल्यूपी समर्थन मांग रहे हैं, मैंने इस पर ध्यान दिया: https://github.com/xamarin/Xamarin.Forms/pull/6015

क्या सामग्री पृष्ठ पर नेविगेशन बार टेम्पलेट को लागू करने का कोई तरीका है?
नेविगेशनपेज निर्दिष्ट करना। टाइटल व्यू पहले की तरह लागू नहीं होता है।
संदर्भ के लिए रेपो:
https://github.com/InquiretorJax/Xamarin-Forms-Shell

संपादित करें:
मर्फी ने फिर से हमला किया - नेविगेशनपेज के बजाय बस शेल का उपयोग करें। टाइटल व्यू :)

नमस्ते,
मेरी नई परियोजना में मैं शैल और संग्रह दृश्य का उपयोग कर रहा हूं, और मुझे यह कहना है कि यह बहुत अच्छा है!
शेल के बारे में एक प्रश्न

• एक निश्चित नीचे की वस्तु को जोड़ने का एक तरीका है (लोमड़ी उदाहरण उपयोगकर्ता लॉगआउट के लिए एक बटन)

मैं देखता हूं कि एक निश्चित शीर्षलेख (FlyoutHeader और FlyoutHeaderBehavior) जोड़ना संभव है, लेकिन मुझे नीचे पाद लेख के बारे में कोई जानकारी नहीं मिल रही है
धन्यवाद!

नमस्ते,
मेरे पास RegisterRoute के बारे में एक और प्रश्न है।
मेरा ऐप काफी बड़ा है, जिसमें काफी संख्या में पेज हैं, लगभग 30...
क्या वास्तव में उनमें से प्रत्येक के लिए RegisterRoute जोड़ने का सही तरीका है?
Routing.RegisterRoute("blabla", typeof(BlaBlaPage)); ... ...
या पुराने तरीके का उपयोग करना बेहतर है?
var blaPage = new BlaBlaPage (); await Navigation.PushAsync (blaPage);

@matteopiccioni मैं इसे इस तरह करने की सलाह

Routing.RegisterRoute("blabla", typeof(BlaBlaPage));

और उपयोग कर रहे हैं
gotoasync("blabla")

मुझे अभी एहसास हुआ है कि यह वही लगता है लेकिन जैसे-जैसे सुविधाएँ बढ़ती हैं, उन सभी चीजों को शेल सिस्टम के माध्यम से संचालित करना अधिक प्रासंगिक होता जा रहा है

क्या वास्तव में उनमें से प्रत्येक के लिए RegisterRoute जोड़ने का सही तरीका है?

अगर यह एक दर्द बिंदु बन जाता है तो हम कुछ ऐसी सुविधाओं को जोड़ने पर विचार कर रहे हैं जो केवल पृष्ठों के लिए असेंबली स्कैन करेंगे या यहां तक ​​​​कि कुछ संकलित समय सुविधाएं भी जो उन मार्गों को उत्पन्न करेंगी।

यहां मुख्य मुद्दा यह है कि किसी भी प्रकार का प्रतिबिंब आपके ऐप को धीमा कर देगा, इसलिए स्टार्टअप पर ऐसा करने पर लागत आएगी

@PureWeen उत्तर के लिए धन्यवाद
धीमा स्टार्टअप समय xf (Android के लिए) में सबसे कष्टप्रद समस्या में से एक है
स्टार्टअप पर क्या मैं केवल पहले स्तर के पृष्ठों (शेलिटम्स पेज) को रूट करने के लिए जोड़ सकता हूं और ऐप शुरू होने के बाद ही दूसरों को जोड़ सकता हूं (RegisterRoute की आलसी लोडिंग का एक प्रकार)?

@matteopiccioni

तो अगर आप इसे एक ही बार में ऐसा ही करते हैं

Routing.RegisterRoute("blabla", typeof(BlaBlaPage));

यह ठीक है। मैं केवल इस बारे में बात कर रहा था कि अगर हम कुछ ऐसा बनाते हैं जो इसे बनाता है तो उपयोगकर्ताओं को ऐसा करने की ज़रूरत नहीं है, हमें इसे प्रदर्शन के खिलाफ तौलना होगा। अभी Routing.RegisterRoute("blabla", typeof(BlaBlaPage)); कोई प्रतिबिंब नहीं करता है इसलिए इसे एक ही बार में करना ठीक है।

यह केवल एक स्ट्रिंग जोड़ता है और एक शब्दकोश में टाइप करता है

@jassmith @jamesmontemagno @pierceboggan वाह बहुत अच्छा लग रहा है। क्या आपने Google पिक्सेल पर पाई एसडीके का उपयोग करते हुए Google संपर्क एप्लिकेशन देखा है? मुझे यूआई/यूएक्स पसंद है, जिसमें कोई टाइटल बार नहीं है और हैमबर्गर ऐप के शीर्ष के साथ एकीकृत है।

क्या आपके शेल के लिए इस सुझाव पर विचार किया जा सकता है क्योंकि यह एक पैटर्न है जिसका Google उपयोग कर रहा है, संपर्क और मानचित्र, और शायद अन्य के साथ?

आपके समय और ध्यान देने के लिए शुक्रिया,

कार्ल

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

मेरे लिए ऐसा लगता है कि आपको कभी भी सीधे सामग्री का उपयोग नहीं करना चाहिए बल्कि टेम्प्लेट का उपयोग करना चाहिए। यह मेरे लिए समझ में आता है, तो प्रत्यक्ष सामग्री दृष्टिकोण का समर्थन क्यों करें? (सरलता के अलावा, लेकिन यह लोगों को खुद को पैर में गोली मारने दे रहा है)। ऐसा लगता है कि प्रत्यक्ष सामग्री का उपयोग करने में सक्षम होना "डेमो करते समय बहुत अच्छा है - अन्यथा भयानक" सुविधा है।

नमस्ते,
मैं यहाँ नया हूँ। मुझे यकीन नहीं है कि यह सवाल पूछने के लिए सही जगह है, अन्यथा कृपया मुझे निर्देश दें कि मुझे कहां पूछना है:
मैंने ऊपर निर्दिष्ट नमूने के समान कुछ करने की कोशिश की:

  <ShellItem Title="My music" ItemsSource="{x:Bind MyMusicModels}" TabLocation="Bottom">
    <ShellItem.ItemTemplate>
      <local:MyMusicItemTemplateSelection />
    </ShellItem.ItemTemplate>
  </ShellItem>

लेकिन मुझे निम्नलिखित त्रुटियां मिलीं:

त्रुटि XLS0413 संपत्ति 'ItemsSource' प्रकार 'ShellItem' में नहीं मिली थी।
त्रुटि XLS0415 अनुलग्नक गुण 'ItemTemplate' प्रकार 'ShellItem' में नहीं मिला था।

@ इलाशी तो क्या आप इस विचार को यहाँ करने की उम्मीद कर रहे हैं?
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/bindable-layouts

शेलआइटम के साथ?

@PureWeen मैं इस विचार का उपयोग करने की उम्मीद कर रहा था :)।
क्या आप सुझाव दे रहे हैं कि यह विचार अभी तक लागू नहीं हुआ है?
अगर इसे अभी तक लागू नहीं किया गया है, तो मुझे इस पर काम करने में दिलचस्पी हो सकती है।

इसे लागू नहीं किया गया है, काश ऐसा होता!

मेरे आईफोन से भेजा गया

मई 5, 2019, 11:59 AM पर, Elashi < [email protected] [email protected] > ने लिखा:

@PureWeen https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPureWeen&data=02%7C01%7C%7C5a4c31a04c6541d6080608d6d172b36a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636926687892526088&sdata=Y3%2Fxx %2BGt13FFjR5BCwdMg0UouarnTxI0%2FawrXtVEURM%3D&reserved=0 मैं इस विचार का उपयोग करने की उम्मीद कर रहा था :)।
क्या आप सुझाव दे रहे हैं कि यह विचार अभी तक लागू नहीं हुआ है?
अगर इसे अभी तक लागू नहीं किया गया है, तो मुझे इस पर काम करने में दिलचस्पी हो सकती है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fxamarin%2FXamarin.Forms%2Fissues%2F2415%23issuecomment-48943976&data = 02% 7C01% 7C% 7C5a4c31a04c6541d6080608d6d172b36a% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636926687892536099 और sdata = RdPBMt9fPqsPC1x0FlJ1MQzn8BK6m9lfg7nsT09YIN8% 3 डी और सुरक्षित = 0 , या धागे मूक https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe लेखन% 2FAABUHE2I4F33TX2SZJE2RVDPT377JANCNFSM4EZ4GB5Q और डेटा = 02% 7C01% 7C% 7C5a4c31a04c6541d6080608d6d172b36a% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C636926687892546103 और sdata = UXiXgRiTo4pAjJVraUqmJmYZibiWMdh9htX2SeFG4JM% 3 डी और = 0 आरक्षित ।

@ इलाशी ऐसा नहीं है, लेकिन मैं देख सकता था कि

यदि आप इस पर काम करना चाहते हैं तो क्या आप जो सोच रहे हैं उसकी मूल बातों के साथ कोई समस्या पैदा कर सकते हैं?

तो परीक्षण और त्रुटि से... भले ही इसमें शेल 3.2 में जेस्चर के बारे में टिप्पणियां हैं और इसके TheLittlePlayground में मैं अपने जीवन के लिए जेस्चर को ANDROID पर विज़ुअल पैकेज के साथ काम नहीं कर सकता।

क्या मुझे नोट्स में कुछ याद आ रहा है कि शैल + इशारे केवल आईफोन के साथ काम करते हैं?

@davidortinau मुझे पता है कि यह सिर्फ कुछ चश्मा है, और इसे थोड़ी देर के लिए बंद कर दिया गया है, लेकिन मैं उम्मीद कर रहा था कि आप मुझे सही दिशा में इंगित करने में सक्षम हो सकते हैं क्योंकि चश्मा इंगित करता है कि नीचे का कार्य या तो पूरा हो गया है या डॉक पर है विकास:

• ShellContent के ala GPS के लिए "सबमेनू" आइटम के लिए API जोड़ें -> संगीत -> संगीत ऐप खोलें

वर्तमान में चूंकि मुझे GroupHeaders काम करने के लिए नहीं मिल रहा है, मैं 6 मुख्य समूहों में सॉर्ट करने के लिए अपने FlyoutMenu को फिर से काम करना चाहता हूं, और उसके बाद FlyoutItems से भरा एक सबमेनू दिखाई देता है जो मुझे पूर्व निर्धारित रूटिंग पर नेविगेट करता है।

मेरा उपयोग-मामला यह है कि मेरे पास स्क्रॉलिंग स्थिति में प्रदर्शित करने और डालने के लिए 50+ विकल्प यूआई अनुकूल नहीं हैं, लेकिन प्रदर्शित होने वाला प्रत्येक विकल्प कुछ ऐसा है जिसे मुझे अपने उपयोगकर्ताओं को अंतहीन स्क्रॉल किए बिना कुशलतापूर्वक प्राप्त करने की अनुमति देने की आवश्यकता है। प्रत्येक विकल्प के अति-संग्रह विषय के आधार पर समूहों में छाँटना UI/UX के दृष्टिकोण से सबसे अधिक समझ में आता है।

क्या आप इस पर कुछ प्रकाश डाल सकते हैं कि विकास/उत्पादन के मामले में यह कहां है? - या मुझे एक कोड बेस की दिशा में इंगित करें जो इसे लागू करता है ताकि मैं सीख सकूं? (मैं केवल 1 महीने के लिए ज़ामरीन के साथ रहा हूं, इसलिए मैं अभी भी उपलब्ध कुछ संसाधनों के लिए नया हूं)।

@TheBaileyBrew

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

https://github.com/ishrakland/ListViewWithSubListView/

साथ ही, उन्होंने अभी-अभी अपनी बहुत सी पाठ्यक्रम सामग्री को MSFT लर्न में स्थानांतरित और अद्यतन किया है (जो कि मैं अंतराल को भरने के लिए स्वयं के माध्यम से चल रहा हूं)। वह यहां पाया गया है: https://docs.microsoft.com/en-us/learn/browse/?products=xamarin

मैं उपरोक्त के माध्यम से कोशिश और चलाऊंगा। शुभकामनाएँ और जहाज पर आपका स्वागत है!

हाय दोस्तों मैं गैलरी या बाहरी स्टोरेज से फाइल या फोटो चुनना चाहता हूं
xamarin इसे फाइल करने के लिए कौन बनाता है? फ़ाइल केवल .PDF एक्सटेंशन है। प्रति
दोनों फाइलों का चयन करें मैं एक बटन का उपयोग करता हूं इसलिए कृपया मेरी मदद करें !!!

थू, 23 मई 2019, 19:41 को एंथनी कूल नोटिफिकेशन @github.com ने लिखा:

@TheBaileyBrew https://github.com/TheBaileyBrew

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

https://github.com/ishrakland/ListViewWithSubListView/

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/xamarin/Xamarin.Forms/issues/2415?email_source=notifications&email_token=AK7KSYK4N3XIVP3IHOBE2P3PW3CKJA5CNFSM4EZ4GB52YY3PNVWWK3TUL52HS4DFVREXG43VMVZ479YN
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AK7KSYI5XKMXD7FC7HZH45LPW3CKJANCNFSM4EZ4GB5Q
.

हे दोस्तों, मैं शर्त के आधार पर टैब जोड़ना चाहता हूं, तो मैं सी # का उपयोग करके शैल में टैब कैसे जोड़ सकता हूं, साथ ही साथ मेनू इटम्स को कैसे जोड़ना है।

@TheBaileyBrew

क्या तुम यही खोज रहे हो?
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell/flyout#flyout -display-options

@BeleShow आपका प्रश्न शायद स्टैक ओवरफ्लो या फ़ोरम.xamarin.com पर बेहतर अनुकूल है

@PWaliaDev आप विभिन्न आइटम संग्रह के माध्यम से ऐसा करेंगे जो शेल का हिस्सा हैं

Shell.Items.Add (नया ShellItem ())
नया ShellItem ()। Items.add (नया ShellSection ())
नया शेलसेक्शन ()। आइटम। जोड़ें (नया शेलकंटेंट ())

हालांकि मैं मान रहा हूं कि क्या हमने इस मुद्दे को ठीक कर दिया है
https://github.com/xamarin/Xamarin.Forms/issues/5428

यह आपके परिदृश्य के अनुरूप होगा?

@PureWeen - मेरे पास आपके लिंक के अनुसार डिस्प्ले विकल्प सेट हैं, लेकिन जो मैं संघर्ष कर रहा हूं वह @BeleShew के साथ काम कर रहा है (प्रति उपयोगकर्ता आधार पर

फिक्सिंग #5428 मैं जो हासिल करना चाहता हूं वह फिट होगा।

मेरे ऐप में कई भूमिकाएं/पहुंच वाले उपयोगकर्ता हैं और मुझे केवल उन उपयोगकर्ताओं को प्रोग्राम के रूप में मेनू विकल्प दिखाने की ज़रूरत है जो अधिकृत हैं (मैं नहीं चाहता कि उपयोगकर्ता यह देखें कि वे क्या नहीं कर सकते हैं, केवल वे क्या कर सकते हैं।

हालांकि मैं इसके साथ खेल रहा हूं, यह पता लगाने की कोशिश कर रहा हूं कि मेरे मेनू विकल्पों का निरीक्षण करना और जोड़ना संभव है, फिर इस कोड की तरह छुपाएं (लेकिन मुझे हर संभावित मार्ग और मेनू विकल्प के खिलाफ फिर से शुरू करना होगा जो खाएगा लोड होने का समय:

foreach (var item in this.Items)
        {
            if (item is FlyoutItem)
            {
                var removeSections = new List<ShellSection>();
                var fi = item as FlyoutItem;
                foreach (var child in fi.Items)
                {
                    if (child.Route == "NOT_AUTHORIZED_KEY")
                        removeSections.Add(child);
                }
                foreach (var s in removeSections)
                    fi.Items.Remove(s);
            }
        }

शैल सिद्धांत में महान है लेकिन व्यावहारिक रूप से नहीं इनके बिना विशेषताएं होनी चाहिए।

1. उपयोगकर्ता भूमिका के आधार पर गतिशील रूप से शेल आइटम जोड़ें/निकालें
2. लॉगिन/लॉगआउट परिदृश्य या शर्तों के आधार पर दो अलग नेविगेशन मार्ग।
3. वैकल्पिक रूप से, प्रिज्म जैसे अन्य एमवीवीएम ढांचे के लिए समर्थन

जब तक सुविधा 1 और 2 प्रदान नहीं की जाती, तब तक व्यवसाय उन्मुख ऐप्स में शेल का उपयोग नहीं किया जा सकता।

@ आईएम-पीजे आपको क्यों लगता है कि 1 और 2 संभव नहीं हैं? (निश्चित रूप से वे हैं)

3 प्रगति पर है और यहां ट्रैक किया गया

क्या किसी को पता है कि ऐप शैल टैब से टैप इवेंट प्राप्त करना संभव है या नहीं?
संबंधित फोरम प्रश्न: https://forums.xamarin.com/discussion/159748/app-shell-pop-to-root-on-tab-tap

@Im-PJ से पूरी तरह सहमत हैं, और यह नहीं समझते कि इन सुविधाओं के लिए विशेष रूप से कैसे प्रदान नहीं किया गया है। यह शेल जैसे टूल का मुख्य कारण है। कोई भी स्लाइड आउट मेनू बना सकता है!

@dotMorten शायद आप व्यापक सी # और हैकिंग के माध्यम से 1 या 2 कर सकते हैं, लेकिन रनटाइम पर शैल आइटम को बाध्यकारी/अक्षम/छिपाने/जोड़ने का कोई उदाहरण या उल्लेख नहीं है जो मुझे मिल सकता है। ऐसा लगता है कि गतिशील क्षमताएं इस उपकरण का एक प्रमुख लक्ष्य रही होंगी। कुछ पाथिंग सुविधाओं के साथ एक एक्सएमएल प्रतिनिधित्व बनाना, न्यूनतम है, मार्केटिंग लोगों को देने के लिए पर्याप्त है, लेकिन वास्तविक, पूर्ण विशेषताओं वाले मोबाइल ऐप में वास्तव में उपयोग करने के लिए पर्याप्त नहीं है।

@ आईएम-पीजे

क्या आप थोड़ा विस्तार कर सकते हैं कि ये कैसे भिन्न हैं?

उपयोगकर्ता भूमिका के आधार पर गतिशील रूप से शेल आइटम जोड़ें/निकालें
लॉगिन/लॉगआउट परिदृश्य

यदि आप लॉगिन पेज पर हैं तो वर्तमान में आप TabBar का उपयोग करके या फ्लाईआउट नेविगेशन को छुपाकर लॉगिन/लॉगआउट परिदृश्य कर सकते हैं।

<TabBar Route="LoggedOut">
<LoginPage>
</TabBar>

<FlyoutItem Route="LoggedIn"></FlyoutItem>
<FlyoutItem></FlyoutItem>
<FlyoutItem></FlyoutItem>
<FlyoutItem></FlyoutItem>

यदि आप लॉग इन पेज पर हैं तो कोड के माध्यम से नेविगेट करने का एकमात्र तरीका है।

एक अदृश्य बाध्यकारी संपत्ति का पर्दाफाश करने के लिए यहां काम किया जा रहा है
https://github.com/xamarin/Xamarin.Forms/tree/shell_isvisible

PR . बनाने से पहले इसे बस थोड़ा परिष्कृत करने की आवश्यकता है

शर्तों के आधार पर दो अलग नेविगेशन मार्ग।

क्या आप उदाहरण प्रदान कर सकते हैं कि आप क्या करने की कोशिश कर रहे हैं और वर्तमान में नहीं कर सकते हैं?

मैं Xamarin.Form Shell का उपयोग कर रहा हूं

लिंक नमूना: https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell/flyout

क्रिप्या मेरि सहायता करे। टैबबार को अबाउट पेज में कैसे दिखाना है?

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

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

यदि Tabbedpage का उपयोग कर रहे हैं, तो Flyout नहीं दिखा सकते हैं। मैं इस समय फ्लाईआउट और तब्बार दिखाना चाहता हूं।

में सारे पन्ने डाल देता हूँताकि पेज टैबबार प्रदर्शित करें, लेकिन मैं टैबबार में केवल 4 तत्व रखना चाहता हूं (अधिक टैब नहीं दिखाना चाहता)। कैसे करना है?

<shell>
<flyoutitem route="animals" flyoutdisplayoptions="AsMultipleItems">
<shellcontent route="cats"/>
<shellcontent route="dogs"/>
<shellcontent route="monkeys"/>
<shellcontent route="elephants"/>
<shellcontent route="bears"/>
<shellcontent route="about"/>
</flyoutitem>
</shell>

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

यदि Tabbedpage का उपयोग कर रहे हैं, तो Flyout नहीं दिखा सकते हैं। मैं इस समय फ्लाईआउट और तब्बार दिखाना चाहता हूं।

मैंने सभी पेजों को रखा ताकि पेज टैबबार प्रदर्शित करें, लेकिन मैं टैबबार में केवल 4 तत्व रखना चाहता हूं (अधिक टैब नहीं दिखाना चाहता)। कैसे करना है?

<shell>
<flyoutitem route="animals" flyoutdisplayoptions="AsMultipleItems">
<shellcontent route="cats"/>
<shellcontent route="dogs"/>
<shellcontent route="monkeys"/>
<shellcontent route="elephants"/>
<shellcontent route="bears"/>
<shellcontent route="about"/>
</flyoutitem>
</shell>

दुर्भाग्य से मैं शेल का उपयोग नहीं कर सकता
मेरे पास अभी भी उसी ऐप में MasterDetailPage और TabbedPage है (iOS में मेरे पास Naxam.TopTabbedPage.Forms प्लगइन का उपयोग करके शीर्ष टैब किए गए पृष्ठ हैं)
यह मेरा पुराना टिकट था