Xamarin.forms: [تحسين] تحكم قابل للربط مكرر

تم إنشاؤها على ٢٧ يناير ٢٠١٨  ·  55تعليقات  ·  مصدر: xamarin/Xamarin.Forms

المنطق

لا تحتوي النماذج حاليًا على عنصر تحكم يعرض عناصر من مصدر عناصر مرتبطة في حاوية غير قابلة للتمرير.

تطبيق

الخصائص المرفقة التي تستهدف Layout ستتم إضافتها لدعم ItemsSource و ItemsTemplate . سيؤدي تعيين هذه الخصائص إلى إضافة عناصر نموذجية إلى التخطيط الهدف.

public static class BindableLayout
{
    public static readonly BindableProperty ItemsSourceProperty =
        BindableProperty.Create("ItemsSource", typeof(IList), typeof(Layout), default(IList));

    public static readonly BindableProperty ItemTemplateProperty =
        BindableProperty.Create("ItemTemplate", typeof(DataTemplate), typeof(Layout);
}

يعد ItemTemplate مسؤولاً عن تحويل الكائنات في مصدر العناصر إلى كائنات View .

سيؤدي تعيين ItemsSource إلى مسح أي عناصر فرعية موجودة وتحديث مجموعة Children لتتوافق مع المصدر.

التوافق

هذه خصائص جديدة ، لذا من المحتمل ألا يمثل التوافق مع الإصدارات السابقة مشكلة.

مستوى الصعوبة: متوسط

F100 community-sprint enhancement ➕

التعليق الأكثر فائدة

هذه ملاحظات جيدة حقًا ، وسوف نستوعبها ونعود باقتراح جديد.

ال 55 كومينتر

لقد تم تنفيذ هذا التحكم إلى حد كبير بالفعل كما هو محدد. من المحتمل أن تحتاج فقط إلى بعض التنقية والتنظيف ومراجعة أفضل الممارسات.

وهو يدعم DataTemplate أو DataTemplateSelector. يمكنه أيضًا التعامل مع ItemSource الذي ينفذ INotifyCollectionChanged لإضافة / إزالة العناصر حسب الحاجة بدلاً من إعادة بناء جميع الأطفال

لقد كنت أبحث في قاعدة كود النماذج لمعرفة أفضل طريقة لتعديل الكود الخاص بي للأسلوب ، الاصطلاح ، إلخ.

اعتقدت أن النظر إلى ListView سيكون مثالًا جيدًا ، والذي يقودني إلى ItemsView و TemplatedItemsList. التي لا أفهمها تمامًا كيف تعمل حتى الآن. لكن سؤالي هو ، هل تحتاج هذه الميزة إلى كل هذه التعقيدات أو ببساطة إضافة طريقة عرض جديدة إلى تخطيط المكدس لكل عنصر في المجموعة المرتبطة استنادًا إلى DataTemplate؟

يقوم الحل الحالي بالطريقة البسيطة ، والتي لا تجعلها تؤدي أداءً جيدًا لقوائم كبيرة من العناصر ، وهي ليست حالة استخدامي لها.

أفكار؟

هناك طريق بديل يمكن اتباعه.

قمت بتطبيق ItemsSource و ItemTemplate كخصائص مرفقة يمكن تطبيقها على أي Layout :

https://github.com/GalaxiaGuy/MobileLibraries/blob/master/XamarinForms.Layout/Layout.cs

من الناحية الفنية ، لا يدعم هذا الإصدار DataTemplateSelector لكني قمت بتطبيق ذلك في الإصدار في مكان آخر.

(يصبح الأمر معقدًا بعد السطر 67 فقط لدعم INotifyCollectionChanged ).

أعتقد أيضًا أن فكرة التحكم "معيد الإرسال" المنفصل ليست كافية ويمكننا الحصول على شيء أفضل من ذلك. "المكرر" ليس هو الحل الصحيح.

لقد أنشأت عنصر التحكم الخاص بي لأنني كنت بحاجة إلى قائمة بسيطة من طرق العرض التي لا تسمح بالاختيار وفي ذلك الوقت لم أتمكن من العثور على طريقة لمنع ListView من إجراء التحديد.

تعتبر الخاصية المرفقة فكرة مثيرة للاهتمام ، لكننا ربما نحتاج إلى بعض الملاحظات من فريق XF على هذا الطريق.

أنا شخصياً أؤيد الفكرة الأصلية المتمثلة في توسيع StackLayout وإضافة الخاصيتين. إنها الطريقة التي تم بها ذلك في مشاريعي السابقة. يبقيها بسيطة.

التحكم في المكرر هو ما كنا نطلبه ، وقد أحب العديد من المطورين هذا النهج ، وفقًا لمنتدى التطور. إذا احتجنا إلى أي شيء أكثر من مكرر ، فإننا نستخدم ListView. يمنحنا هذا النهج أيضًا قائمة أفقية رائعة :) إذا كنا بحاجة إلى عرض قائمة أفقي ، فهذه هي علاقات عامة مختلفة.

adamped ما هي الخصائص 2 التي تقترح إضافتها إلى ListView؟ هل تقصد Layout؟
يحتوي ListView بالفعل على ItemsSource و ItemTemplate.

اعتذارات خطأ مطبعي. قصدته StackLayout :)

davidortinau - لمعلوماتك لم يتم تعيين هذا لك حتى الآن.

هذا هو RepeaterView الذي كنت أستخدمه والذي غالبًا ما يكون متطورًا مع بعض التعديلات الأخرى التي اضطررت لتطبيقها على طول الطريق

https://gist.github.com/PureWeen/4bf4d8c2e384a11b34398dc23201a7cc

إنه يدعم القوالب ويعمل معي مع uwp / ios / android

davidortinau يمكننا الحصول على شيء أفضل من مجرد إضافة عنصر تحكم مشتق للتو من StackLayout . بخلاف ذلك ، لا أعتقد أنه من المنطقي إضافة Repeater مشتق من StackLayout .
على الأكثر ، ربما تضيف بعض الخصائص المرفقة إلى Layout ، مثل الطريقة التي اقترحها GalaxiaGuy أعلاه.

الطريقة التي تقوم بها أطر XAML بذلك هي بواسطة ItemsControl .
إليك رأيي في هذا https://github.com/andreinitescu/XFItemsControl/

يرجى إلقاء نظرة على القسم الأخير في الجزء السفلي ، فأنا أشارك بعض المشكلات / الأخطاء في نماذج Xamarin التي عثرت عليها.

أنا جميعًا لإضافة الخاصيتين مباشرة إلى StackLayout ، بدلاً من عنصر تحكم منفصل يسمى مكرر.

ومع ذلك ، فإن ItemsControl ، على الرغم من أنها جيدة ، أعتقد أنها تحتاج إلى مزيد من المناقشة أو التحسين بعد ذلك. عنصر تحكم StackLayout القابل للربط هو ما يريده الناس. إنه الحل الأساسي البسيط للعديد من المشكلات.

ربما يجب أن تكون ItemsControl عنصر تحكم إضافي منفصل يتجاوز هذا التحسين. أو تحسين إضافي لـ StackLayout؟ في كلتا الحالتين ، هذه هي أفكاري. سوف نرى ما سيقرره فريق XF.

adamped إضافة ItemsSource و ItemTemplate إلى StackLayout لن يكون قرارًا جيدًا. بدلاً من ذلك ، يمكنك إضافتها كخصائص مرفقة ، فقط لإسعاد الجميع.

وإلا ، إذا تمت إضافة هذه الخصائص إلى StackLayout ، فهل يجب إضافتها إلى فئات Layout الأخرى أيضًا؟ لماذا لا تضيفهم أيضًا إلى الشبكة؟ ماذا عن AbsoluteLayout أو RelativeLayout؟ ربما تضيفهم إلى Layout أو Layout<View> ؟

أنا شخصياً أحب الطريقة التي يقوم بها Windows XAML. لا تحتوي فئة اللوحة (وهي Layout في نماذج Xamarin) على ItemsSource و ItemTemplate. للوحة غرض واحد فقط: وضع العناصر في موضعها. هذا يجعلها قابلة لإعادة الاستخدام وقابلة للتوصيل في ضوابط أخرى.

فكرة أخرى: كما ذكرت في الملف التمهيدي لمشروعي ، فإن Xamarin لديه ItemsView وهو قريب من ItemsControl في Windows XAML. أنا متأكد من أن هناك سببًا لاختيار فريق Xamarin اشتقاق ListView من ItemsView .

لا تعني إضافتها إلى StackLayout أنها مناسبة لعناصر تحكم التخطيط الأخرى. كيف يمكن أن يعمل مع شبكة ، هناك عدة أعمدة وصفوف. كيف ستعمل حتى مع التخطيط المطلق أو النسبي؟ لا أستطيع حتى أن أرى كيف سيعمل ذلك.

تم تصميم StackLayout لتكديس عنصر تلو الآخر. هذا هو السبب في أن مصدر العناصر يعمل بشكل جيد ، ولن يكون من المنطقي أن تحتوي التخطيطات الأخرى على هذه الخيارات.

كيف يمكن أن يعمل مع شبكة ، هناك عدة أعمدة وصفوف. كيف ستعمل حتى مع التخطيط المطلق أو النسبي؟ لا أستطيع حتى أن أرى كيف سيعمل ذلك.

من شأنه. Google قليلاً لأشياء مثل "itemscontrol with grid". سترى مواد المدرسة القديمة كيف يمكن أن يؤدي استخدام ItemsControl مع الفئات المختلفة المشتقة من اللوحة إلى أشياء مثيرة جدًا للاهتمام.

سيسمح ذلك بالحصول على بعض الأشياء المثيرة للإعجاب في نماذج Xamarin خاصةً بالنظر إلى أنه متعدد الأنظمة الأساسية ، وهو رمز قد يستغرق وقتًا طويلاً للكتابة والمحافظة عليه بشكل أصلي.

بالإضافة إلى ذلك ، في المستقبل ، يمكن لأي شخص أن يكتب عنصر تحكم على غرار ListView -like في نماذج Xamarin. تخيل أن لديك عنصر تحكم يأخذ أي تخطيط يسمح بتحديد موضع أي عنصر ، ولكن لديك أيضًا خصائص مثل SelectedItem لتتمكن من تحديد العناصر (ListView في Windows XAML مشتق من ItemsControl)

ترجع مشكلة الشبكة إلى الأداء ، ومن ثم الاضطرار إلى إعداد خصائص إضافية للتحكم في تدفق العناصر التي تتم إضافتها. سترى من Googling قليلاً عن ItemsSource و Grid في Xamarin. هناك العديد من الحلول ، بما في ذلك أحد الحلول التي قمت بها. إنه ليس الحل الأفضل للشبكة.

StackLayout هو عنصر التحكم الوحيد المنطقي مع هاتين الخاصيتين فقط. يجب أن يتم توسيعه ليشمل ضوابط أخرى ، أو تحويل هذه المشكلة إلى شيء أكثر تعقيدًا مما هو مطلوب ، في قضية منفصلة. الأشخاص الذين يواجهون هذه المشكلة يريدون فقط StackLayout مع مصدر Items.

بينما أعرف أن الآخرين يرغبون بالتأكيد في ItemsControl والحل الذي قدمته ، أعتقد أنه عنصر تحكم مختلف تمامًا لمجموعة مختلفة من المتطلبات. أنا لا أطلب ولا أطلب الكثير من عناصر التحكم في العناصر. كل ما أحتاجه لمشاريعي العديدة الأخيرة هو مجرد مصدر ItemsSource و DataTemplate على StackLayout.

الأشخاص الذين يواجهون هذه المشكلة يريدون فقط StackLayout مع مصدر Items.

نعم ، يختبرها الأشخاص ، بما فيهم أنا ، عدة مرات ، لكن هذا لا يعني أن إضافة الخصائص بشكل صحيح إلى StackLayout هو الحل الجيد من منظور إطار العمل.
تبدو الأشياء مختلفة من منظور أوسع ، وإلا إذا بدأنا في إضافة خصائص لمجرد تناسب احتياجاتنا الفورية ، فسننتهي بالفوضى ، مع القليل من إعادة الاستخدام أو معدوم. على الأقل هذا رأيي الشخصي.

جانب آخر هو التقارب مع XAML موحد (معيار XAML). أنا متأكد من أن هذه الخصائص لا معنى لها في StackLayout ، ما عليك سوى إلقاء نظرة على Windows XAML.

StackLayout هو عنصر التحكم الوحيد المنطقي مع هاتين الخاصيتين فقط.

بالنسبة لي هذا يبدو وكأنه استنتاج متسرع.
نعم ، بالتأكيد نحتاج جميعًا إلى مصدر عناصر قابل للربط في بعض الأحيان. لماذا لا تستخدم ListView بعد ذلك؟ ربما يكون القرار الأفضل هو امتلاك خاصية في ListView ، شيء مثل IsSelectionEnabled ؟ أفضل من إنشاء عنصر تحكم Repeater أو إضافة خصائص إلى StackLayout وهذا يعني أنه لا يزال بإمكاننا استخدام المحاكاة الافتراضية .

يثير معيار XAML نقطة جيدة. قد يكون هذا سببًا جيدًا للذهاب إلى ItemsControl. سيتعين علينا أن نرى ما هو موقف XF من هذا.

والسبب في عدم استخدامنا ListView هو أنه يقوم بتنفيذ التمرير. وإلا فإننا سنستخدم طريقة عرض القائمة فقط. لكني أعتقد أن هذا يسلط الضوء على أنك تبحث عن حل لمشكلة مختلفة. نريد فقط قائمة قابلة للربط لا تتضمن عرض تمرير تلقائيًا.

إن إضافة عنصر تحكم جديد في Repeater أو مجرد إضافة خصائص إلى StackLayout لا يروق لي. من المؤكد أنه سيحل المشكلة ولكن بغض النظر عن مدى "وضوح" هذه الحلول ، من منظور إطار العمل ، هناك طرق أفضل من شأنها أن تضيف المزيد من المرونة إلى إطار العمل ، فلماذا لا تفعل ذلك الآن؟ لن يكون التنفيذ أكثر تعقيدًا بشكل ملحوظ.
بعد كل شيء ، ما هي مشكلة ItemsControl التي قمت بتطبيقها بالفعل؟ نظرت إلى التعليقات والشيء الوحيد الذي استطعت رؤيته هو "الناس يريدون StackLayout قابل للربط". بالتأكيد ، ولكن هذا لأن الناس لا يعرفون شيئًا عن ItemsControl :)

أنا أعرف؟ لكنك تكرر الأشياء الآن. كما ذكرنا ، تم طرح النقاط الصحيحة ، سنحتاج إلى انتظار فريق XF لوضع اللمسات الأخيرة على أي شيء.

هناك نقاط جيدة تُطرح في كلا الاتجاهين بشأن هذه المسألة. اقترحت علينا النظر في ما يلي

  1. هناك حاجة لقائمة بسيطة لعرض عدد صغير من العناصر النموذجية ، "المكرر" كما هو محدد يلبي هذا. سيكون أيضًا منخفضًا جدًا ، ويشير الاسم بوضوح إلى أنه ليس عنصر تحكم متطور.

  2. نحن بحاجة إلى "عرض قائمة" "ItemsControl" أفضل ، وما إلى ذلك. ولكن هذه مشكلة أكبر بكثير ولها تأثير أوسع بكثير ، وبالتالي سوف تتطلب الكثير من التفكير والمزيد من المدخلات من فريق XF. أرغب في الحصول على عنصر تحكم في قائمة الأداء بحيث يمكنني عرض مئات العناصر النموذجية ، ولكن يجب أن يكون هذا اقتراحًا منفصلاً. أظن أن العديد من المشكلات التي نواجهها مع ListView ناتجة عن تطبيقه في النظام الأساسي الفردي المقدم "ListViews". لذلك قد يكون عنصر التحكم القائم على XF حلاً جيدًا.

لكن فريق XF راجع هذا الطلب وإذا نشروا التحسين كعنصر عمل هنا ، فيبدو أنهم على استعداد للنظر فيه. دعونا لا ندع عظيم الوقوف في طريق الخير. هناك متسع لـ "مكرر" و "ItemsControl".

كما أنني لا أحب فكرة إضافة هذه الخصائص إلى StackLayout ، فهي تنتمي إلى فئة فرعية. يجب أن تكون التخطيطات عبارة عن تخطيطات ، لا أكثر.

رداً على بعض التعليقات السابقة - نحن بالتأكيد لسنا قلقين بشأن الظاهرية أو الأداء مع ItemsSource s هنا. هذا صراحة للتعامل مع قوائم صغيرة من العناصر النموذجية.

بالنظر إلى عنصر التحكم في Andrei ، هناك الكثير مما يعجبك ؛ إنه أكثر مرونة من مكرر بسيط ، وسيكون من التافه استخدامه كمكرر (خاصة أنه يتحول إلى استخدام StackLayout افتراضيًا). كما أنه يتميز بكونه مألوفًا جدًا لمطوري UWP / WPF.

TBH ، إذا تمكنا من دمج علاقات عامة لـ ItemsControl في المستقبل القريب ، فسيسعدني إغلاق هذه المشكلة لأنني _فكر في ItemsControl يحل المشكلات التي كان المكرر يهدف إلى حلها. هل هناك حالة استخدام لمكرر لا يغطيها ItemsControl؟

سيكون من التافه تغيير المكرر الذي كنت أعمل عليه لتقديم هذه المشكلة حتى لا ترث من StackPanel واستخدام أي تخطيط متوفر (أو افتراضي إلى StackLayout).

أنا شخصياً أحب هذا الحل أفضل من فكرة الملكية المرفقة التي تم اقتراحها.

يمكننا اتباع النهج البسيط المتمثل في عدم القلق بشأن المحاكاة الافتراضية أو الأداء في القوائم الكبيرة ، ولكن فقط دعم استخدام أي تخطيط. يمكن دائمًا تحسين عنصر التحكم لاحقًا لمعالجة القوائم الكبيرة إذا لزم الأمر.

hartez - إنه يغطي جميع السيناريوهات التي كنا مهتمين بها. سعداء بإغلاق هذا واستبداله بـ ItemsControl. يبدو أنه من الأفضل أن يكون لديك عنصر تحكم واحد يحل العديد من المشكلات في نفس الوقت.

andreinitescu - هل أنت سعيد بتنفيذ هذا في العلاقات العامة ، أم أنك تريد أن

fyi -davidortinau - في حالة الحاجة إلى إعادة التعيين.

hartez لقد أنشأت تذكرة لـ ItemsControl هنا # 1743
adamped علينا أن نقرر أولاً كيف يجب أن يعمل بالضبط.

بحاجة إلى أكبر قدر ممكن من ردود الفعل من الجميع.

هذه ملاحظات جيدة حقًا ، وسوف نستوعبها ونعود باقتراح جديد.

هل يمكننا نقل هذا من "قيد التقدم"؟ أقترح وجود عمود يسمى "قيد المناقشة" أو أي شيء به قضايا قيد المناقشة من قبل الفريق. وإلا فإن الأشياء تسقط من خلال الشقوق إلى الأبد مثل بوغزيلا.

تضمين التغريدة سهل الاستخدام ، ويعمل بشكل جيد على جميع الأنظمة الأساسية وهو موجود في مجموعتنا "الأساسية" من عناصر تحكم تخطيط XF غير المصنّعة.

BindableStackLayout

هذه ملاحظات جيدة حقًا ، وسوف نستوعبها ونعود باقتراح جديد.

jassmith لقد مرت 5 أشهر ، هل يمكنني أن أسأل ما هو اقتراح الفريق؟

mattrichnz الخاص بك BindableStackLayout يدور حول ما فعلته بالضبط وكنت أخطط للقيام بهذه الميزة حتى تم تسللها إلى الأعمال المتراكمة :)

jassmith أي أخبار؟ آخر مرة قلت فيها في كانون الثاني (يناير) أنك تناقشها مع فريقك

IMHO ، ListView يجب أن يعتمد على هذا التحكم والوراثة من هذا (# 1743) تمامًا كما هو الحال في UWP و WPF (موروث من ItemsControl ).
ربما يكون هذا هو الشيء الأكثر أهمية الذي تفتقر إليه XF ، مما يجعل الإحباط يصل إلى المستويات العليا.
بالإضافة إلى ذلك ، تم إنشاء ListView بمشكلة رؤية هائلة ، بحيث لا يدعم التخطيط الأفقي ، والضبط الدقيق للاختيار ، والحجم على المحتوى ، والحجم إلى الفضاء ، وغيرها من القضايا الرئيسية.
انظر # 1727 ، # 2531 ، و # 2723.

على أي حال ، فإن الافتقار إلى ItemsControl و / أو ListView الأفقي مؤلم للغاية !
Xamarin لديه تثبيت ملتوي لتحيز كل شيء نحو الهاتف وتجاهل أي شيء آخر تمامًا. لقد مر الوقت ونريد أن نبدأ في استخدام Xamarin للحصول على شاشة أكبر أيضًا ، وكذلك لأجهزة سطح المكتب.
إن الافتقار إلى الدعم الأفقي والتحكم الأفضل في لوحة المفاتيح والماوس أمر مزعج تمامًا!

بالإضافة إلى ذلك ، عند الحديث عن هذا ، ربما حان الوقت للتخلص من الخلايا ووضع المحتوى مباشرةً في DataTemplate s كما هو الحال في WPF / UWP؟

الأزيزjassmith مرة أخرى ... والمزيد من الناسhartezStephaneDelcroix 🤞 :)

mattrichnz أنا أعلم أن هناك الكثير من الضوابط هناك ولدي أيضًا ضوابط خاصة بي ، المشكلة هي أنه لا يوجد أي منهم لديه دعم رسمي واختبار مناسب وأنك تقضي أيامًا في العثور على العنصر المناسب حتى تدرك أن صنعه هو الأفضل والأكثر موثوقية . يجب أن يتوقف هذا. إنها ليست لغة PHP الغرب المتوحش ، إنها .NET هنا. إنها جامعة مايكروسوفت. يجب أن تكون هذه الأشياء في الصندوق.

أحب أن يكون لديك عناصر قابلة للربط على StackLayout ، أو على الأقل عرض مكرر.
التصويت الإيجابي لهذا التحسين!

هذه ملاحظات جيدة حقًا ، وسوف نستوعبها ونعود باقتراح جديد.

مرحباjassmith
لقد مر ما يقرب من 6 أشهر حتى الآن ... هل يمكنك مشاركة بعض الأفكار من فضلك؟ نماذج Xamarin بحاجة ماسة إلى بعض البدائل لـ ListView ...

شكرا.

حقًا لا أحد من نماذج Xamarin يتلقى إشعارًا بهذا الشأن؟ hartezStephaneDelcroixrmarinhosamhouts؟

نريد أن نرى مكان هبوط ListView2 قبل دفع هذه المواصفات للأمام. يحتوي على العديد من نفس المكونات المطلوبة وسيكون من الأفضل تجنب تكرارها.

ما هو "ListView2"؟

شيء ما سنستعرضه بمزيد من التفصيل قريبًا.

حسنًا ، شكرًا ، آمل أن يكون لدينا شيء يعمل بحلول نهاية عام 2018 :)

jassmith من فضلك قل لي أنه لن يسمى ListView2 ...

لن يطلق عليه ListView2

أنا أعرف. سوف يطلق عليه إما ListViewEx أو TheRealListView 😆

آمل أن يتلاشى مفهوم "الخلية". فكرة غبية في جوهرها. يجب أن يكون مجرد "محتوى" مثل WPF / UWP / Silverlight / Avalonia / Uno.

jassmith الآن بعد أن

dansiegel إذا تم تنفيذ CollectionView بالطريقة التي أتخيلها بها ، فسيعمل مثل طريقة عمل ItemsControl مع StackPanel في Windows XAML. والتي يجب أن تجيب على سؤالك بخصوص التمرير. انظر تعليقي هنا . كما ذكرت هناك ، لا ينبغي أن يحتوي CollectionView على اختيار عنصر أو تمرير أو EmptyView ، يجب أن يعمل وأن يكون بسيطًا مثل ItemsControl. يجب وضع هذه القدرات في فئة مشتقة ، والتي اقترحت تسميتها مثل ListCollectionView (على غرار ListView في Windows XAML)

آمل أن يتلاشى مفهوم "الخلية". فكرة غبية في جوهرها. يجب أن يكون مجرد "محتوى" مثل WPF / UWP / Silverlight / Avalonia / Uno.

أعتقد أن ViewCell يجب أن تكون فقط DataTemplate ، والتي من الواضح أنها ستعتمد على المواصفات
اقتراح

هذا لطيف.
هل هناك خطط لـ FlexRepeater أيضًا؟ أعني ، نفس هذا ولكن موروث من FlexLayout بدلاً من StackLayout؟ أعتقد أن كلاهما سيكون مرحبًا به في XF.

يجب إرفاق ItemsSource و ItemTemplate بخصائص قابلة للربط ، بحيث يمكن تطبيقها على Grid ، StackLayout ، Flex ، ...

لقد قمت بتحديث المواصفات المقترحة لتعكس اقتراحات الملكية المرفقة من GalaxiaGuy و StephaneDelcroix.

رد: https://github.com/xamarin/Xamarin.Forms/issues/1718#issuecomment -394780832

بعد دراسة متأنية ، لن تغطي CollectionView السيناريو من هذا الاقتراح: https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -424413234

لذا هذا الاقتراح مطروح على الطاولة مرة أخرى.

hartez Typo في المواصفات المحدثة ، كلا الخاصيتين ItemTemplate . :)

hartez Typo في المواصفات المحدثة ، كلا الخاصيتين ItemTemplate . :)

D'oh! شكرا ثابتة.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات