Maui: [कल्पना] स्लिम रेंडरर आर्किटेक्चर

को निर्मित 19 मई 2020 · 56टिप्पणियाँ · स्रोत: dotnet/maui

चेतावनी: यह युक्ति अभी भी एक WIP है, हम अभी भी इस अवधारणा के साथ प्रयोग कर रहे हैं

विवरण

स्लिम रेंडरर्स आर्किटेक्चर मल्टी-टारगेटिंग और सिंगल-प्रोजेक्ट सुविधाओं से लाभान्वित होता है।

उदाहरण

entryRenderer.cs

public partial class EntryRenderer {
   public static PropertyMapper<IView> ViewMapper = new PropertyMapper<IView> {

     // Add your own method to map to any property         
     [nameof(IView.BackgroundColor)] = MapBackgroundColor

   };
}

entryRenderer.iOS.cs

// You don’t need to register a new renderer.
public partial class EntryRenderer
{
     // You know what method to call because you named it!
   public static void MapBackgroundColor (IViewRenderer renderer, IView view)
     {
        // You don’t need to call any base methods here or worry about order.

        // Every renderer is consistent; you know where the native view is.
          var nativeView = (NativeView)renderer.NativeView;
          var color = view.BackgroundColor;

          if (color != null) {

            // Phew! That was easy!         
            nativeView.BackgroundColor = UIColor.FromRGB (204, 153, 255);
          }
     }
}

रेंडरर्स का मानकीकरण

सभी प्लेटफ़ॉर्म के लिए सभी डिफ़ॉल्ट रेंडरर्स को इस आर्किटेक्चर में पोर्ट किया जाएगा

रेंडरर्स का पंजीकरण

रेंडरर रजिस्ट्रार निर्भरता सेवा पर मौजूद होगा और serviceCollection.Get<IRendererRegistrar>() द्वारा एक्सेस किया जा सकता है, जिससे नियंत्रण की अनुमति मिलती है कि कौन सा रेंडरर किस नियंत्रण से जुड़ा है

रेंडरर्स पर इंटरफेस

मैपर अवधारणा

प्रॉपर्टी मैपर प्रतिक्रिया संपत्ति परिवर्तनों में क्रियाओं को ट्रिगर करने के लिए ज़िम्मेदार है। एक पतला रेंडरर स्वयं संपत्ति परिवर्तनों की सदस्यता नहीं लेता है, लेकिन कुछ घोषित कार्यों को परिवर्तनों के जवाब में निष्पादित किया जाता है।

एक नियंत्रण की संपत्ति मैपर संपत्ति public static और इसे उपयोगकर्ता कोड द्वारा बढ़ाया जा सकता है।

प्रॉपर्टी मैपर फीडबैक लूप में कोई भूमिका नहीं निभाता (बटन क्लिक किया गया, टेक्स्ट दर्ज किया गया)

TODO: चर्चा करें कि मैपर कुंजी के लिए क्या उपयोग करना है। string या object ? जब हम संदर्भों की तुलना कर सकते हैं तो स्ट्रिंग तुलना से बचना अच्छा होगा (बाइंडेबलप्रॉपर्टीज के मामले में)

लीगेसी कस्टम रेंडरर्स का उपयोग कैसे करें

पुराने रेंडरर्स के आधार पर तृतीय-पक्ष नियंत्रणों का उपयोग कैसे करें

मौजूदा रेंडरर्स को कैसे पूरक करें

इस आर्किटेक्चर के लिए नया एक्स्टेंसिबिलिटी मॉडल प्रॉपर्टी मैपर पर आधारित है। जब आप किसी नई प्रॉपर्टी के लिए समर्थन जोड़ना चाहते हैं, तो उसे केवल नई प्रॉपर्टी की मैपिंग की आवश्यकता होती है। संपत्ति के अस्तित्व के लिए, नियंत्रण को उपवर्गित करना आवश्यक है, लेकिन रेंडरर को उपवर्गित करना नहीं है।

पश्च संगतता

हम मौजूदा कस्टम रेंडरर्स के साथ पश्चगामी संगतता रखना चाहते हैं, या पुराने रेंडरर्स के उपवर्ग इस की वास्तुकला को प्रभावित करेंगे

कठिनाई: बहुत अधिक

proposal-open slim renderer

स्रोत

StephaneDelcroix

👍51 ❤14 🚀6 🎉4 👎3

सबसे उपयोगी टिप्पणी

कृपया हर कीमत पर पीछे की ओर संगत रहने की कोशिश न करें। यह कुछ नया है। इसका एक्सएफ के साथ संगत होना जरूरी नहीं है। आप कुछ बेहतर कर सकते हैं।

MichaelRumpler 19 मई 2020

👍204 ❤47

सभी 56 टिप्पणियाँ

Xamarin wpf रेंडरर्स बनाता है और कुछ एंड्रॉइड रेंडरर्स जैसे कि ButtonRenderer तेज हैं, और हम जानते हैं कि यहां "फास्ट" का क्या अर्थ है।
क्या ये रेंडरर्स तेज होंगे या नहीं?
अग्रिम में धन्यवाद।

ysmoradi 19 मई 2020

👍6

@ysmoradi हाँ! ये नए रेंडरर्स तेजी से रेंडरर पैटर्न का पालन करेंगे (यानी, मुख्य दृश्य के आसपास कोई रैपर दृश्य नहीं)। हम इसे केवल एंड्रॉइड और डब्ल्यूपीएफ ही नहीं, बल्कि सभी प्लेटफॉर्म के लिए करने की योजना बना रहे हैं।

samhouts 19 मई 2020

❤35

MichaelRumpler 19 मई 2020

👍204 ❤47

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

ugnivs 19 मई 2020

👍96 ❤27 👎15 🎉11

इस दृष्टिकोण के साथ, प्लेटफ़ॉर्म-विशिष्ट रेंडरर के बजाय क्रॉस-प्लेटफ़ॉर्म रेंडरर लिखना संभव है? जैसे मानचित्रण बटन नियंत्रण स्की-तेज नियंत्रण के साथ।

pranshu-aggarwal 19 मई 2020

👍14

प्लेटफ़ॉर्म रेंडरर एक खराब डिज़ाइन है। जैसा कि आप देखते हैं, बहुत सारे xamarin नियंत्रण कार्य हैं जो प्लेटफ़ॉर्म सीमा के कारण UWP का समर्थन नहीं करते हैं।
एक उदाहरण लें, UWP में छाया। आपको कोने के बटन से कोने की छाया नहीं मिल सकती है (बेशक, आप ऐसा करने के लिए बटन टेम्पलेट को बदल सकते हैं, लेकिन यह दूसरी बात है)।

मुझे पता है कि क्रॉस प्लेटफॉर्म रेंडर बनाना बहुत मुश्किल है। लेकिन स्पंदन ने हमें बताया कि यह संभव है। लंबी अवधि में, एक क्रॉस-प्लेटफ़ॉर्म रेंडरर सबसे अच्छा समाधान है।

h82258652 20 मई 2020

👍52 ❤7 👎7

मुझे लगता है कि पूरे ऐप को कस्टम 2 डी कैनवास मोबाइल ऐप के लिए मूल रूप से काम कर सकता है।

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

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

Soul-Master 20 मई 2020

👍15 👎6

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

आप इन सभी चीजों के बारे में बिल्कुल सही हैं, लेकिन टीम को केवल एक ही दृष्टिकोण चुनने के लिए मजबूर नहीं किया जाता है। मुझे लगता है कि यह सब समय की कमी के बारे में है। मेरा मतलब है कि उन्हें एक साल में .net 6 के साथ एक "बिल्कुल नया" पूरी तरह से क्रॉसप्लेटफार्म यूआई ढांचा जारी करने की जरूरत है। और यह आधार के रूप में अच्छे पुराने समय-परीक्षण ढांचे को लेने के लिए बहुत कम जोखिम भरा है। यह ठीक है और होना भी चाहिए। लेकिन मेरा मानना है कि लंबे समय तक चलने वाले कस्टम 2d कैनवास रेंडरिंग के बहुत अधिक लाभ हैं और वास्तव में "क्रॉस प्लेटफॉर्म" कहलाने के योग्य हैं। Xamarin रूप वास्तव में अच्छी बात है और आज के लिए इसकी बहुत बड़ी प्रगति है। लेकिन यह आगे बढ़ने का समय है। Microsoft और xamarin टीमों के पास बहुत चतुर इंजीनियर हैं और वे शायद इस तरह के दृष्टिकोण पर विचार कर रहे हैं या शायद ट्रम्प कार्ड के रूप में http://avaloniaui.net/ के साथ कुछ संबंध भी रखते हैं।

ugnivs 20 मई 2020

👍12 👎3

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

यह अच्छा हो सकता है कि स्की डेवलपर्स के लिए 4-वें रेंडर डिफ़ॉल्ट ग्रे एक समृद्ध डिजाइन देने के लिए 100% इसे बदल देगा,
बैक कॉम्बेबिलिटी के लिए उन 3 को वैसे ही छोड़ दिया जाएगा, लेकिन "ड्रा इट योर डियर डेवलपर"_skia_render जोड़ें और इसके लिए 90% जिम्मेदारी लें।

filipoff2 20 मई 2020

यदि रेंडरर्स की अवधारणा को बनाए रखा जाना है, तो क्या साझा यूआई कोड और रेंडरर्स के बीच INotifyPropertyChanged और इवेंट हैंडलर के बीच पुल को खत्म करने के लिए सोचा जा सकता है? अर्थात

साझा नियंत्रण पर _property_ सेट करने और PropertyChanged ईवेंट प्रचारित करने के बजाय, क्या संपत्ति को मैप किया जा सकता है और सीधे प्लेटफ़ॉर्म रेंडरर पर सेट किया जा सकता है?
साझा नियंत्रण पर एक _method_ को कॉल करने के बजाय और एक घटना को रेंडरर द्वारा निकाल दिया और संभाला जा सकता है, क्या विधि को मैप किया जा सकता है और सीधे प्लेटफॉर्म रेंडरर पर शामिल किया जा सकता है?

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

velocitysystems 20 मई 2020

👍13

यह लंबा है लेकिन माउ पर कुछ "बेसबॉल के अंदर" देखने लायक है।
https://www.youtube.com/watch?v=_MGh3xipWm4

ऐसा लगता है कि माउ की वास्तुकला प्लेटफ़ॉर्म-रेंडर किए गए नियंत्रण और कैनवास द्वारा बनाए गए नियंत्रण दोनों का समर्थन करेगी, और इसके अलावा, महान @Clancey माउ के लिए स्की-आधारित रेंडर सेट पर काम करना जारी

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

freever 20 मई 2020

👍17

यह विषय से थोड़ा हटकर है, लेकिन ऐसा कुछ है जिसे मैं इस सटीक चीज़ की प्रासंगिकता के कारण पूछना चाहता हूं:

स्मृति SKCanvasView (या सामान्य रूप से स्की) के साथ कैसे काम करती है? क्या हर कोई हमेशा अपने आकार के अनुपात में मेमोरी लेता है? क्या यह बदलता है अगर यह दूसरों को ओवरलैप करता है?

यदि, उदाहरण के लिए, मेरे पास एक ढाल नियंत्रण (स्किया में लिखा गया रेंडरर) था और उसके शीर्ष पर मेरे पास एक अर्ध पारदर्शी बटन (स्किया में लिखा गया रेंडरर) था, जो कि दो बार अधिक मेमोरी लेगा, या ग्राफिक्स संदर्भ किसी तरह साझा किया गया है? कैसे के बारे में अगर स्कीया गैर-स्किया नियंत्रणों को ओवरलैप करता है?

मैंने पहले स्कीया का उपयोग करके फॉर्म में कुछ फैंसी ग्राफिक्स नियंत्रण लागू करने पर विचार किया है, लेकिन यह समझ में नहीं आता कि स्मृति कैसे काम करती है हमेशा पर्याप्त चिंता का कारण बनती है जो मैंने नहीं की है।

GalaxiaGuy 20 मई 2020

👍2

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

h82258652 20 मई 2020

👍1

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

legistek 20 मई 2020

👍28 ❤1 😕1

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

danielkatz 20 मई 2020

👍25 ❤1

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

माना! और आपको वास्तव में बहुत कम संख्या में रेंडरिंग प्राइमेटिव्स की आवश्यकता होती है, जो किसी ऐप की ज़रूरत की हर चीज़ का 99% हिस्सा पूरा करने के लिए होता है:

बॉर्डर (ड्रॉप शैडो और गोल किनारों के लिए विकल्प सहित)
रेखाएं/दीर्घवृत्त/आयत
सादा पाठ प्रतिपादन
सादा पाठ इनपुट
रिच टेक्स्ट रेंडरिंग
रिच टेक्स्ट इनपुट
एचटीएमएल प्रतिपादन
छवि प्रस्तुतकर्ता
ऑडियो/वीडियो प्रस्तुतकर्ता
ठोस और रैखिक / रेडियल ग्रेडिएंट ब्रश

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

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

legistek 20 मई 2020

👍9

ऐप की जरूरत की हर चीज का 99% पूरा करने के लिए आपको वास्तव में बहुत कम संख्या में रेंडरिंग प्राइमेटिव की आवश्यकता होती है।

Uno प्लेटफॉर्म इस दृष्टिकोण का उपयोग कर रहा है।

ysmoradi 20 मई 2020

👍3 👀1

@velocitysystems

साझा नियंत्रण पर एक संपत्ति स्थापित करने और एक संपत्ति परिवर्तन घटना को प्रचारित करने के बजाय, क्या संपत्ति को मैप किया जा सकता है और सीधे प्लेटफॉर्म रेंडरर पर सेट किया जा सकता है?

यही इस बदलाव का एक बड़ा लक्ष्य भी है। एक बार जब हम इन परिवर्तनों के दूसरी तरफ होते हैं तो रेंडरर्स को पता नहीं चलेगा कि बाइंडेबलऑब्जेक्ट या आईएनपीसी का क्या अर्थ है

PureWeen 20 मई 2020

👍6

यही इस बदलाव का एक बड़ा लक्ष्य भी है। एक बार जब हम इन परिवर्तनों के दूसरी तरफ होते हैं तो रेंडरर्स को पता नहीं चलेगा कि बाइंडेबलऑब्जेक्ट या आईएनपीसी का क्या अर्थ है

तो रेंडरर पर एक विधि ढांचे जब भी कोई द्वारा लाया जाएगा BindableProperty मूल्य रेंडरर की सदस्यता के लिए होने के बजाय बदलता है PropertyChanged ?

legistek 20 मई 2020

@legistek सही

यह मूल रूप से निर्भरताओं को बदल देता है

तो रेंडरर्स सिर्फ IButton के खिलाफ काम करेंगे।

और फिर System.Maui रेंडरर्स प्रोजेक्ट के लिए एक संदर्भ जोड़ देगा जो अभी विरोध करता है कि कैसे रेंडरर्स के पास Xamarin.Forms.Core का संदर्भ है।

मैंने यहां एक स्पाइक में चेक किया है
https://github.com/dotnet/maui/pull/66

तो आप देख सकते हैं कि यह कैसा दिख सकता है

PureWeen 20 मई 2020

👍2

मैं आज 3:30 पीडीटी समय पर @davidortinau के साथ एक स्ट्रीम कर रहा हूँ और हम स्लिम

https://www.twitch.tv/microsoftdeveloper

हमसे जुड़ें! इसकी जांच - पड़ताल करें! और सवाल पूछो!

PureWeen 20 मई 2020

👍6

@PureWeen दुर्भाग्य से मैंने इसे याद किया। क्या YouTube पर कोई रिकॉर्डिंग उपलब्ध होगी?

velocitysystems 21 मई 2020

यही इस बदलाव का एक बड़ा लक्ष्य भी है। एक बार जब हम इन परिवर्तनों के दूसरी तरफ होते हैं तो रेंडरर्स को पता नहीं चलेगा कि बाइंडेबलऑब्जेक्ट या आईएनपीसी का क्या अर्थ है।

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

आज #66 की समीक्षा करने जा रहे हैं।

velocitysystems 21 मई 2020

#66 को देखते हुए, यह देखना अच्छा लगता है कि पतले रेंडरर्स प्रतिबिंब का उपयोग करने के बजाय 'चारा-और-स्विच' के साथ बनाए और लागू किए गए हैं। बस कुछ विचार:

क्या स्लिम रेंडरर्स जीसी मुद्दों को संबोधित करेंगे, खासकर एंड्रॉइड पर जहां प्रबंधित और देशी नियंत्रण जीवनचक्र के बीच एक बेमेल है? वर्चुअलाइज्ड लेआउट में चाइल्ड व्यू में यह विशेष रूप से ध्यान देने योग्य है जो खतरनाक ObjectDisposedException ।
क्या स्लिम रेंडरर्स Effect के बहिष्करण की ओर ले जाएंगे? प्रभाव उपयोगी हो सकते हैं, लेकिन अंततः वे जटिलता जोड़ते हैं और फिर भी लेआउट जीवनचक्र में विलंबता के लिए एक और क्षमता जोड़ते हैं।
नए रेंडरर डिज़ाइन के साथ 'टू-वे' प्रॉपर्टी कैसे काम करेगी? उदाहरण के लिए आइए कहते हैं कि मैं एक है MediaElement एक स्थिति के साथ ( TimeSpan ) संपत्ति। सेटर वर्तमान स्थिति को अपडेट करता है, और गेट्टर नेटिव मीडिया प्लेयर यानी AVPlayer , MediaPlayer से वर्तमान स्थिति को पुनः प्राप्त करता है। क्या स्लिम रेंडरर्स के साथ _getter_ को मैप करने के लिए कोई डिज़ाइन है?

velocitysystems 21 मई 2020

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

हमारे यहाँ कुछ विचार हैं !! हम सभी ODE अपवादों को नहीं तो अधिकांश को हल करने के लिए निपटान रणनीतियों को थोड़ा सा फिर से काम करना चाहते हैं। अभी हम एंड्रॉइड/आईओएस में हर चीज का अत्यधिक आक्रामक तरीके से निपटान करते हैं लेकिन मुझे पूरा यकीन है कि हम जीसी पर भरोसा कर सकते हैं कि जीसी क्या करता है। अगर हम सब कुछ हटाना सुनिश्चित करते हैं और जीसी को वह काम करने देते हैं जिससे इन मामलों में बहुत मदद मिलनी चाहिए

क्या स्लिम रेंडरर्स प्रभाव के बहिष्करण की ओर ले जाएंगे? प्रभाव उपयोगी हो सकते हैं, लेकिन अंततः वे जटिलता जोड़ते हैं और फिर भी लेआउट जीवनचक्र में विलंबता के लिए एक और क्षमता जोड़ते हैं।

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

नए रेंडरर डिज़ाइन के साथ 'टू-वे' प्रॉपर्टी कैसे काम करेगी? उदाहरण के लिए मान लें कि मेरे पास एक स्थिति (टाइमस्पैन) संपत्ति वाला मीडिया एलिमेंट है। सेटर वर्तमान स्थिति को अपडेट करता है, और गेटर नेटिव मीडिया प्लेयर यानी एवीप्लेयर, मीडियाप्लेयर से वर्तमान स्थिति को पुनः प्राप्त करता है। क्या स्लिम रेंडरर्स के साथ गेटर मैप करने के लिए कोई डिज़ाइन है?

हम अभी भी इस पर थोड़ा काम कर रहे हैं। अगर मैं गलत हूं तो मुझे सुधारें @Clancey लेकिन https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

PureWeen 21 मई 2020

👍5

नए रेंडरर डिज़ाइन के साथ 'टू-वे' प्रॉपर्टी कैसे काम करेगी? उदाहरण के लिए मान लें कि मेरे पास एक स्थिति (टाइमस्पैन) संपत्ति वाला मीडिया एलिमेंट है। सेटर वर्तमान स्थिति को अपडेट करता है, और गेटर नेटिव मीडिया प्लेयर यानी एवीप्लेयर, मीडियाप्लेयर से वर्तमान स्थिति को पुनः प्राप्त करता है। क्या स्लिम रेंडरर्स के साथ गेटर मैप करने के लिए कोई डिज़ाइन है?
हम अभी भी इस पर थोड़ा काम कर रहे हैं। अगर मैं गलत हूं तो मुझे सुधारें @Clancey लेकिन https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91

बिल्कुल नहीं। तो एक्शनमैपर अपवाद के साथ प्रॉपर्टीमैपर जैसा ही है, उन्हें सेटलेमेंट चरण के दौरान नहीं कहा जाता है। तो, WebView, GoBack जैसी चीज़ों के लिए। आप इसे इनिशियलाइज़ेशन के दौरान कॉल नहीं करना चाहते हैं, लेकिन यह अभी भी कुछ ऐसा है जिसे आपको रेंडरर के साथ संवाद करने की आवश्यकता है।

हम पहले से ही टू वे मैपिंग का समर्थन करते हैं। यानी प्रवेश। जब टेक्स्ट वैल्यू एंट्री पर चांस होता है। IEntry में string Text {get;set;} और हम केवल मान सेट करते हैं। तो मीडिया तत्वों के लिए आपके पास 2 विकल्प हैं। जब यह बदलता है तो बस स्थिति/समय को वापस सेट कर दिया जाता है। यदि आप इसे कुछ बनाना चाहते हैं तो आप इसके बजाय पूछें। तुम यह कर सकते हो। xplat दृश्यों के पास रेंडरर तक पहुंच है। view.Renderer.NativeView as NativeMediaView अब आप अपनी पसंद की कोई भी संपत्ति निकाल सकते हैं!

Clancey 21 मई 2020

👍2

Build . के दौरान हमारी स्ट्रीम के कुछ वीडियो यहां दिए गए हैं

@Clancey यहाँ और अधिक गहराई में होगा
https://www.youtube.com/watch?v=_MGh3xipWm4

मैं यहां डेविड के साथ उन पर थोड़ा सा स्पर्श करता हूं
https://www.youtube.com/watch?v=lAmwjfZY1IM

PureWeen 22 मई 2020

नए रेंडरर डिज़ाइन के साथ 'टू-वे' प्रॉपर्टी कैसे काम करेगी? उदाहरण के लिए मान लें कि मेरे पास एक स्थिति (टाइमस्पैन) संपत्ति वाला मीडिया एलिमेंट है। सेटर वर्तमान स्थिति को अपडेट करता है, और गेटर नेटिव मीडिया प्लेयर यानी एवीप्लेयर, मीडियाप्लेयर से वर्तमान स्थिति को पुनः प्राप्त करता है। क्या स्लिम रेंडरर्स के साथ गेटर मैप करने के लिए कोई डिज़ाइन है?
हम अभी भी इस पर थोड़ा काम कर रहे हैं। अगर मैं गलत हूं तो मुझे सुधारें @Clancey लेकिन https://github.com/dotnet/maui/blob/slim-renderers/Maui.Core/PropertyMapper.cs#L91
बिल्कुल नहीं। तो एक्शनमैपर अपवाद के साथ प्रॉपर्टीमैपर जैसा ही है, उन्हें सेटलेमेंट चरण के दौरान नहीं कहा जाता है। तो, WebView, GoBack जैसी चीज़ों के लिए। आप इसे इनिशियलाइज़ेशन के दौरान कॉल नहीं करना चाहते हैं, लेकिन यह अभी भी कुछ ऐसा है जिसे आपको रेंडरर के साथ संवाद करने की आवश्यकता है।
हम पहले से ही टू वे मैपिंग का समर्थन करते हैं। यानी प्रवेश। जब टेक्स्ट वैल्यू एंट्री पर चांस होता है। IEntry में string Text {get;set;} और हम केवल मान सेट करते हैं। तो मीडिया तत्वों के लिए आपके पास 2 विकल्प हैं। जब यह बदलता है तो बस स्थिति/समय को वापस सेट कर दिया जाता है। यदि आप इसे कुछ बनाना चाहते हैं तो आप इसके बजाय पूछें। तुम यह कर सकते हो। xplat दृश्यों के पास रेंडरर तक पहुंच है। view.Renderer.NativeView as NativeMediaView अब आप अपनी पसंद की कोई भी संपत्ति निकाल सकते हैं!

यहां पर विचार करने वाली एक और बात रिकॉर्ड्स हैं जो सी # 9 में आ रहे हैं। विशेषता यह है कि वे अपरिवर्तनीय हैं और उनके पास init संपत्ति एक्सेसर है। इसलिए उन्हें दो-तरफा बाध्यकारी में उपयोग करने योग्य बनाने के लिए मैपर को with ऑपरेटर का उपयोग करके एक नया उदाहरण वापस करने में सक्षम होना चाहिए।

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

dersia 22 मई 2020

👍2

प्रश्न: आपके द्वारा पोस्ट किए गए आरेख में विंडोज नियंत्रण Windows.UI.* द्वारा प्रदान किया जा रहा है, लेकिन जैसा कि मैं इसे समझता हूं, यह अब बहिष्कृत होने की प्रक्रिया में है और कोई अपडेट नहीं देखेगा: धाराप्रवाह डिज़ाइन रेंडरर्स में सभी सुधार हैं WinUI प्रोजेक्ट के हिस्से के रूप में Microsoft.UI.* में हो रहा है। क्या आप कृपया इस पर टिप्पणी कर सकते हैं?

mqudsi 23 मई 2020

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

insinfo 26 मई 2020

👍16 👎4 ❤1

यह मुद्दा यहां नए आर्किटेक्चर/प्रॉपर्टी मैपर्स के बारे में बात करने के लिए है। वह नहीं जिसके खिलाफ वे मैप करते हैं। बस फिर से दोहराने के लिए। देशी के लिए स्लिम रेंडर आर्किटेक्चर का मतलब यह नहीं है कि हम कभी नहीं करेंगे, और कभी भी एक तैयार नियंत्रण दृष्टिकोण नहीं कर सकते हैं। लेकिन यह हमें देशी बनाम गैर-देशी नियंत्रणों को मिलाने और मिलाने की अनुमति देता है, जहां यदि आप विशुद्ध रूप से तैयार होते हैं, तो यह अधिक कठिन होता है। मैं स्कीआ आधारित नियंत्रणों पर काम करना जारी रखने की योजना बना रहा हूं जो ड्राइंग परत सहित समान स्लिम रेंडरर आर्किटेक्चर का पालन करते हैं। https://github.com/Clancey/Comet/tree/dev/src/Comet.Skia/Handlers।

Clancey 27 मई 2020

👍18

इस रेंडरर चीज़ पर मेरा 2¢ (जो मैं मानता हूं कि मैं पूरी तरह से समझ नहीं पा रहा हूं, टीबीएच):

मुझे इस बारे में एक विचार था कि हम एक ही नियंत्रण वर्ग का उपयोग करके प्लेटफ़ॉर्म-रेंडर किए गए नियंत्रण (उदाहरण के लिए UIButton लपेटना) _and_ लुकलेस कंट्रोल (एक ला डब्ल्यूपीएफ) दोनों को कैसे कार्यान्वित कर सकते हैं। यह काफी सरल है, ईमानदारी से: क्या माउ बटन वर्ग एक नियंत्रण टेम्पलेट का उपयोग करता है, और इसमें से सभी प्लेटफ़ॉर्म-विशिष्ट रेंडरर कोड हटा दें। फिर, बटन के लिए एक इन-बॉक्स टेम्पलेट प्रदान करें जिसमें एक ButtonRenderer है। ButtonRenderer वह है जो Cocoa/UIKit/UWP/etc से बात करता है, प्रत्येक UI टूलकिट के लिए प्लेटफ़ॉर्म-विशिष्ट कोड के साथ, और ऐप डेवलपर द्वारा उपयोग किया जाने वाला बटन वर्ग बस इसके गुणों को अग्रेषित करता है। यदि उपयोगकर्ता एक कस्टम-ड्रा बटन का उपयोग करना चाहता है, तो वे बस टेम्पलेट को ओवरराइड कर सकते हैं और ButtonRenderer के बजाय ड्राइंग क्लासेस (जो कुछ भी दिखने में समाप्त होता है) का उपयोग कर सकते हैं, जैसा कि हम wpf में करते हैं। मैं ईमानदारी से नहीं जानता कि आज माउ में यह पहले से ही संभव है (या यहां तक कि पहले से ही इस्तेमाल किया जा चुका है), क्योंकि मैंने Xamarin को समझने के लिए कभी समय नहीं लिया। मैं डब्ल्यूपीएफ को जितना गहराई से समझता हूं।

मुझे बताओ तुम क्या सोचते हो!

wjk 31 मई 2020

👍3

मैं यह समझने की कोशिश कर रहा हूं कि विभिन्न ऐप मॉडल (एमवीवीएम, एमवीयू, ...) के लिए स्लिम रेंडरर्स का क्या मतलब होगा।

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

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

एक अन्य बिंदु यह है: नियंत्रण इंटरफेस ( IButton ) को केवल रेंडरर्स द्वारा उपभोग करने के लिए गेटटर होना चाहिए।
रेंडरर्स मान सेट नहीं करते हैं और प्रत्येक ऐप मॉडल अलग-अलग नियंत्रणों को आकार देगा (BindableProperty, BindingObject, आदि)।
उदाहरण के लिए, फैबुलस में अपरिवर्तनीय विचार होंगे। केवल आंतरिक रूप से, क्या यह उत्परिवर्तन को IButton के उदाहरण पर सेट करने के लिए अधिकृत होगा।

इस तरह, Fabulous सीधे IButton इंटरफ़ेस को अपने आंतरिक शब्दकोश पर पाठक-दृश्य के रूप में उपयोग कर सकता है ताकि रेंडरर्स काम कर सकें।

// This is the type used by our users, sort of a Builder that return a new instance each time
// and append the set value to an internal list 
public struct Button
{
     public Button Text(string value) => (...);

     internal ReadOnlyDictionary<string, obj> Build() { ... }
}

// This will be an implementation of IButton, hidden from our users
internal class FabulousButton : IButton
{
    private ReadOnlyDictionary<string, obj> _properties;
    FabulousButton(ReadOnlyDictionary<string, obj> properties)
    {
        _properties = properties;
    }

    void Update(ReadOnlyDictionary<string, obj> properties)
    {
        var previousProperties = _properties;
        _properties = properties;

        // Diffing of the 2 dictionaries to determine what changed
        // and which mapped functions inside the renderer should be called
        (...)
    }

    public string Text => _properties["Text"];
}

TimLariviere 1 जून 2020

👍1

@TimLariviere आपने

जहां तक रेंडरर्स की बात है तो वहां की ड्राइंग भ्रमित करने वाली है।

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

अधिकांश भाग के लिए इंटरफेस केवल पढ़ने के लिए हैं

यह बटन द्वारा उपयोग किया जाने वाला इंटरफ़ेस है
https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Views/IText.cs

वह सब वास्तव में आप पर है (जहाँ तक रेंडरर्स के रूप में) रेंडरर को संकेत देना है कि उसे IButton का पुन: उपभोग करना चाहिए

उदाहरण के लिए, इस सब के BindableObject संस्करण पर हम यहां केवल रेंडरर की अपडेटप्रॉपर्टी विधि को कॉल कर रहे हैं

https://github.com/dotnet/maui/blob/slim-renderer-samples/System.Maui.Core/VisualElement.cs#L1132

कुछ बिंदु (जल्द ही?) @Clancey के पास धूमकेतु का एक सार्वजनिक संस्करण होगा

मैं देख लूंगा
https://github.com/dotnet/maui/blob/slim-renderer-samples

आप शायद उसमें अपना खुद का Fabulous.Core हेड जोड़ सकते हैं और फिर इंटरफेस में कार्यान्वयन जोड़ना शुरू कर सकते हैं

PureWeen 1 जून 2020

❤4

@PureWeen ओह कूल। धन्यवाद, मैं यह देखने के लिए आपके द्वारा लिंक किए गए नमूनों के साथ खेलने की कोशिश करूंगा कि यह कैसा चल रहा है।

TimLariviere 1 जून 2020

@PureWeen @Clancey मुझे यकीन है कि माउ टीम इस सब पर होगी, लेकिन कृपया नए स्लिम

velocitysystems 1 जून 2020

👍3

@PureWeen
यह यूआरएल
https://github.com/dotnet/maui/blob/slim-renderer-samples

404 देता है, क्या यह निजी है?

Rand-Random 1 जून 2020

@ रैंड-रैंडम

https://github.com/dotnet/maui/tree/slim-renderer-samples

@velocitysystems

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

इस तरह उनका निर्माण किया जाता है। एक बहुत ही पतला आधार वर्ग है जो सीधे अच्छे ol' System.Object

https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Renderers/View/AbstractViewRenderer.Android.cs

और कोई देशी संबंध नहीं है।

वहां से पूरी चीज को परिभाषित किया जाता है कि मूल रूप से एक डिक्शनरी क्या है

https://github.com/dotnet/maui/blob/slim-renderer-samples/Maui.Core/Renderers/View/AbstractViewRenderer.cs#L31

जो मूल रूप से एक डेकोरेटर की तरह काम करता है।

आप अतिरिक्त मैपर के साथ मैपर को सजा सकते हैं और आप अपने स्वयं के फंक आदि को इंजेक्ट कर सकते हैं।

हमारा लक्ष्य 95 प्रतिशत उपयोगकर्ता परिदृश्यों को केवल मैपर में अपना स्वयं का Func जोड़कर या केवल मूल तत्वों को सीधे एक्सेस करके कवर करना है क्योंकि यह सभी बहु-लक्षित होंगे

PureWeen 2 जून 2020

👍1

@PureWeen आपके नमूने में उन स्लिम

मेरे कुछ प्रश्न हैं जैसे:

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

TimLariviere 10 जून 2020

क्या डिफ़ॉल्ट मानों को केंद्रीकृत स्थान पर परिभाषित किया जाएगा? XF में, वे वर्तमान में BindableProperty फ़ील्ड बनाते समय परिभाषित होते हैं लेकिन ये ऐप मॉडल के आधार पर मौजूद नहीं होंगे।

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

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

हां! हम सभी एप्लिकेशन क्लास (मूल और xplat) को एक ही एप्लिकेशन क्लास में संक्षिप्त करने की उम्मीद कर रहे हैं। आप इस बारे में क्यों पूछ रहे हैं? मैं यहां आपके उपयोग के मामले को लेकर उत्सुक हूं ताकि हम पता करना सुनिश्चित कर सकें

क्या नियंत्रण इंटरफेस से माप/व्यवस्था/आदि निकाले जाएंगे? मुझे नहीं लगता कि ऐप मॉडल के लिए उन्हें अलग तरीके से लागू करना वास्तव में समझ में आता है।

फिलहाल यही योजना है। विचार हमारे सभी लेआउट कोड को निकालने का होगा ताकि इनमें से कोई भी बाइंडेबल ऑब्जेक्ट/प्रॉपर्टी पर निर्भर न हो .. इस तरह ब्लेज़र/धूमकेतु/अन्य केवल स्टैकलाउट का उपयोग कर सकते हैं और परिणाम वही होगा।

PureWeen 10 जून 2020

आप इस बारे में क्यों पूछ रहे हैं? मैं यहां आपके उपयोग के मामले को लेकर उत्सुक हूं ताकि हम पता करना सुनिश्चित कर सकें

मुझे अभी तक पूरी तरह से यकीन नहीं है कि मुझे क्या चाहिए। लेकिन फैबुलस में, वैश्विक शैलियों और मुख्य मेनू (जैसे macOS के लिए) को परिभाषित करने के लिए हमारे पास वर्तमान में एक अच्छी कहानी नहीं है। चूंकि हम अपने उपयोगकर्ताओं को एप्लिकेशन वर्ग को स्वयं उप-वर्ग करने देते हैं, हम मूल रूप से उन्हें संसाधनों/मेनू को परिभाषित करने के लिए कहते हैं जैसे वे क्लासिक Xamarin.Forms में करते हैं।

तो आदर्श रूप से, एप्लिकेशन के सभी UI-संबंधित गुण भी दृश्य का हिस्सा होंगे, इस तरह हम अपने दृष्टिकोण-भिन्न तर्क को भी उस पर लागू करने में सक्षम होंगे।

ऐसा कुछ

public interface IAppRoot
{
    IEnumerable<object> Resources { get; }
    IMenu MainMenu { get; }
    IPage MainPage { get; }
}

public class Application
{
    /// Bootstrapping and other logic of MAUI

   public IAppRoot Root { get; set; } // Replaces MainPage, which is typed for pages only
}

TimLariviere 10 जून 2020

@PureWeen एक और सवाल: TextChanged , Toggled , आदि जैसी घटनाओं को ट्रिगर करने के लिए कौन जिम्मेदार होगा? नियंत्रण या रेंडरर्स?

एक बात जो मुझे लगता है कि अन्य ऐप मॉडल के कार्यान्वयन को बहुत सरल बना देगी, वह है राज्य-बदलती घटनाओं को ट्रिगर नहीं करने की संभावना जब परिवर्तन प्रोग्रामेटिक होते हैं।

उदाहरण के लिए, आज, जब उपयोगकर्ता कुछ लिखता है या जब हम MyEntry.Text = "New value"; करते हैं, तो प्रविष्टि पर TextChanged ट्रिगर होता है।
मुझे लगता है कि प्रोग्रामेटिक परिवर्तन पर प्रतिक्रिया करना वास्तव में उपयोगी नहीं है, और निहित है जो कोड के बारे में तर्क के लिए बुरा है।

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

TimLariviere 12 जून 2020

👍6

एक जिज्ञासु प्रश्न। जब MAUI वास्तुकला अज्ञेयवादी है, तो नियंत्रणों को आर्किटेक्चर नामों से क्यों नामित किया जाता है? उदाहरण के लिए ऊपर के चित्र में हमारे पास माउ है। MVVM .ButtonRenderer.Android? @PureWeen @Clancey

libin85 7 अग॰ 2020

XF में कम्प्रेस्ड लेआउट्स (जो छोटी गाड़ी है) नाम की कोई चीज़ होती है।
क्या हमारे पास MAUI में ऐसी चीज़ है (बिना बग्स के!)?

ysmoradi 8 अग॰ 2020

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

g0rdan 9 सित॰ 2020

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

यदि MAUI वेब (जैसे फ़्लिटर) का समर्थन करता है, तो हम हमेशा WebView में रेंडर कर सकते हैं।
ऐप्पल कभी भी वेबव्यू-आधारित एप्लिकेशन को ब्लॉक करने की हिम्मत नहीं कर सकता है, क्योंकि कुछ बड़ी कंपनियों का प्रतिनिधित्व केवल वेबव्यू के माध्यम से ऐपस्टोर में किया जाता है।

Atreides07 9 सित॰ 2020

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

यह पहले से ही दिशानिर्देशों के विरुद्ध है - https://developer.apple.com/app-store/review/guidelines/#minimum -functionality

IeuanWalker 9 सित॰ 2020

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

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

jackie0100 21 सित॰ 2020

👍9 ❤2 👎1

@ जैकी0100
में पूरी तरह से सहमत हूँ

प्रत्येक प्लेटफ़ॉर्म पर कस्टम UI को लागू करना जैसे कि Xamarin फ़ॉर्म में पुराना लगता है और जैसे यह नरक के सातवें सर्कल में बनाया गया समाधान था।

insinfo 22 सित॰ 2020

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

फिर आप आईओएस भूमि में चीजें कर सकते हैं, बस अपना विचार UIView होने के लिए डालें, और इसमें एक मूल बच्चा जोड़ें (जो भी आप चाहते हैं) क्योंकि एक आईवीव एक यूआईवीव है। इसी तरह, यदि आप 'मूल एम्बेडिंग' करना चाहते हैं, तो यह आसान है क्योंकि एक IView एक UIView है, आप अपने मूल दृश्य में अपना एक IViews जोड़ सकते हैं क्योंकि वे एक ही चीज़ हैं। यह बड़े पैमाने पर देशी <-> माउ इंटरऑपेबिलिटी को सक्षम करेगा, और उच्चतम स्तर के प्रदर्शन और न्यूनतम मेमोरी खपत के साथ।

मैं खुद इसका प्रोटोटाइप बनाने का मन कर रहा हूं। शायद एक सप्ताहांत/शाम की परियोजना ...

jsiemensLatitudegeo 23 सित॰ 2020

👍2 👀1

यदि MAUI वेब (जैसे फ़्लिटर) का समर्थन करता है, तो हम हमेशा WebView में रेंडर कर सकते हैं।

iOS पर WebView की आवश्यकता नहीं है: OpenGL या Metal में सीधे रेंडर कर सकते हैं।

या या तो OpenGL या नीचे धातु के साथ Skia का उपयोग करें।

MappingSteve 6 अक्तू॰ 2020

स्थानीय यूआई के साथ काम करने की क्षमता चीजों के राजनीतिक पक्ष पर ढांचे को सुरक्षित करती है। [सेब]

कुछ बिंदु पर, Apple ने अपनी लिखित नीति से देशी UI विजेट का उपयोग करने की आवश्यकता को हटा दिया। मुझे कोई व्यावहारिक तरीका नहीं दिख रहा है कि वे नीति को वापस प्रतिबंधात्मक होने के लिए उलट देंगे।

भले ही, देशी नियंत्रणों के साथ काम करने के लिए _able_ होना एक अच्छा विकल्प है।

MappingSteve 6 अक्तू॰ 2020

@legistek

इतने सारे लोग स्की के प्रति जुनूनी क्यों हैं? एक अच्छा प्रतिपादन युक्ति प्रतिपादन इंजन के लिए अज्ञेयवादी होगा ...

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

मुझे यह भी संदेह है कि स्की को लक्षित करना ज़ामरीन फॉर्म्स के दो समानांतर विजेट उत्तराधिकारियों के रखरखाव की तुलना में बहुत कम बोझिल होगा - क्रॉस-प्लेटफ़ॉर्म विजेट और देशी विजेट।

स्कीया उस दिन भी जल्दबाजी कर सकती है जब .नेट माउ ब्राउज़र में अत्यधिक प्रदर्शनकारी

MappingSteve 6 अक्तू॰ 2020

👍4 ❤3

हाय सब लोग, इसे मत भूलना:
https://github.com/dotnet/maui/discussions/103

jingliancui 13 अक्तू॰ 2020

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

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

roceh 18 अक्तू॰ 2020

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

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

cafelasm 4 नव॰ 2020

👎2

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Maui: [कल्पना] स्लिम रेंडरर आर्किटेक्चर

विवरण

उदाहरण

रेंडरर्स का मानकीकरण

रेंडरर्स का पंजीकरण

रेंडरर्स पर इंटरफेस

मैपर अवधारणा

लीगेसी कस्टम रेंडरर्स का उपयोग कैसे करें

पुराने रेंडरर्स के आधार पर तृतीय-पक्ष नियंत्रणों का उपयोग कैसे करें

मौजूदा रेंडरर्स को कैसे पूरक करें

पश्च संगतता

कठिनाई: बहुत अधिक

सबसे उपयोगी टिप्पणी

सभी 56 टिप्पणियाँ

संबंधित मुद्दों