ماذا عن حدث التمرير لدعم رؤوس المنظر

هناك الكثير لتحبه في هذا الأمر.

FontIconSource

بالنسبة لـ FontIconSource ، على الرغم من أننا نحتاج حقًا إلى طريقة لعدم استخدام قيمة Unicode (إذا لم نرغب في ذلك). إذا كنت تبحث عن FontIconSource بقيمة f370 فليس لديك أدنى فكرة عما يفترض أن تكون عليه.

من ناحية أخرى ، إذا كان بإمكاني انتقاء واختيار خط Icon الذي أستخدمه ومنح النماذج طريقة لتحويل fa-app-store-ios إلى رمز unicode يعادل f370 ، يمكنني الآن معرفة ذلك في لمحة أن الأيقونة التي أستخدمها من Font Awesome وهي أيقونة iOS App Store. لا أقول بأي حال من الأحوال أن النماذج يجب أن تتمتع بهذا الفهم لكل خط متاح مخبوز في (أو أي خط آخر لهذه المسألة) ، يمكن أن يأتي من بعض الجوانب العامة أو يُضاف إلى مجموعة أدوات المجتمع ، إلخ. وفي كلتا الحالتين ، نحتاج إلى طريقة لاستخدام الأسماء ذات المعنى.

أخيرًا ، آمل أن نتمكن من الحصول على خبز في امتداد XAML لذلك قد يكون لديك شيء مثل:

<Image Source="{FontIcon fa-app-store-ios,Color={StaticResource primaryColor}}" />

القوائم

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

الأحداث

أعتقد أنه من الآمن أن أقول إنني متحيز ، لكن جزءًا كبيرًا جدًا من المجتمع يتبع نمط تصميم MVVM. إن وجود أحداث SelectionChanged & RemainingItemsThresholdReached كلاهما مهم لواجهة برمجة التطبيقات ، ولكن سيكون من الرائع إذا تمكنا من إيجاد طريقة لدعم OOB مع إصدار ViewModel لمعالج الأحداث ... أنا أمر.

منذ RemainingItemsThresholdReached يرسل EventArgs قديمًا عاديًا أعتقد أنه يمكننا أن نفترض بأمان أن تمرير القيمة null إلى الأمر يجب أن يكون جيدًا لأننا نحتاج فقط إلى تنفيذ الأمر. بالنسبة لـ SelectionChanged ، فإنني أميل إلى الاعتقاد بأنه سيكون من الأهمية بمكان معرفة العناصر الجديدة ، مقابل العناصر القديمة ، لذا فإن تمرير العناصر الجديدة OOB إلى SelectionChangedCommand يجب أن يكون جيدًا. قد لا يصيب هذا كل حالة استخدام ، ولكنه يوفر على الأقل حدًا أدنى من النفقات العامة التي يحتاج المطور لإضافتها مع بعض EventToCommandBehavior.

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

ماذا عن إضافة GroupFooterTemplate أيضًا؟

هذا مطلوب بشدة في Forms :-) CollectionView من شأنه أن يلغي الحلول البديلة الباهظة ويحل القيود وربما يحسن الأداء في كل تطبيق Forms قمت بإنشائه في السنوات الخمس الماضية. النهج الصحيح تمامًا أيضًا - استفد من قوة الأنظمة الأساسية المحلية واكشف عنها.

إذا كان هناك تحسين واحد يمكنني طلبه للنماذج ، فسيكون هذا هو.
(في الواقع ، لقد فعلت ذلك في عام 2017 ردًا على davidortinau)

هذا رائع حقًا والذي طال انتظاره! واجهة برمجة التطبيقات نظيفة ومباشرة (شكرًا لإعادة تسمية HasUnevenRows!).

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

FontIconSource فكرة جيدة. قد يكون من الرائع تقديم قائمة افتراضية بالأيقونات ، مع تعيين رمز يونيكود لكل نظام أساسي (على غرار iOS أو UWP).

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

تعليقاتي حتى الآن:

dansiegel سيكون الأمر موضع ترحيب عند استيفاء عتبة العناصر المتبقية. لست متأكدًا من أنه مطلوب لـ SelectedItems بالرغم من ذلك - كل ما تقوله (تم إخطاره بالتغييرات ، وما الذي تغير ، وحتى لماذا) يتم التعامل معه تلقائيًا طالما أن SelectedItems عبارة عن ObservableCollection (أو أي شيء يقوم بتنفيذ INotifyCollectionChanged). أفضل أن يكون لدي أقل قدر ممكن من التعليمات البرمجية في CollectionView للحد من التعقيد.

التمرير: أوافق تمامًا على حدث التمرير. يمكننا الحصول عليه في الوقت الحالي لنظام Android ، ولكن بالنسبة لنظام التشغيل iOS ، يجب عليك التفاف UITableViewSource واختطاف الطريقة Scrolled.

الأهم من ذلك كله بالنسبة لي هو التمدد. من فضلك لا تستخدم الفئات الداخلية للمحولات و TableViewSources ، ويرجى في العارضين الأصليين الكشف عن أساليب "CreateAdapter" و "CreateViewSource" (وما شابه ذلك للأنظمة الأساسية الأخرى) حيث يمكننا إنشاء النوع الخاص بنا إذا أردنا ذلك. لدينا ListAdapter المخصص لدعم السحب والإفلات على Android ، وكما ذكرنا من قبل ، UITableViewSources مخصصة لكل من التمرير والسحب والإفلات. إنه ليس رمزًا يعجبني على الرغم من وجود التفاف للفئات الداخلية وما إلى ذلك.

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

أعتقد أن هذه ميزة رائعة وهامة حقًا!
يستخدم iOS بالفعل اسم UICollectionView ، والذي قد يؤدي إلى حدوث ارتباك ونتائج غير صحيحة في google عند البحث عن CollectionView. هذا هو مشكلة؟

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

يمكن إضافة هذا لاحقًا ، ولكن مثل:

public class MultipleFontIconsSource : ImageSource
{
    public List<FontIconSource> Icons { get; set; }
}

سيكون مفيدًا ، لدعم رموز التراص: https://fontawesome.com/how-to-use/on-the-web/styling/stacking-icons

ملاحظاتي:

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

public class CollectionView : View
{
   // Common capabilities related to a view capable of displaying a list of items
    public static readonly BindableProperty ItemsLayoutProperty;
    public IItemsLayout ItemsLayout { get; set; }

    public static readonly BindableProperty ItemsSourceProperty;
    public IEnumerable ItemsSource { get; set; }
}

public class ListCollectionView : CollectionView
{
     // Item selection capabilities and other capabilities 

    public static readonly BindableProperty SelectionModeProperty;
    public SelectionMode SelectionMode { get; set; }

    public static readonly BindableProperty SelectedItemProperty;
    public object SelectedItem { get; set; }

    public static readonly BindableProperty SelectedItemsProperty;
    public IList<object> SelectedItems { get; set; }

    public static readonly BindableProperty SelectedItemsProperty;
    public IList<object> SelectedItems { get; set; }
}

فكرتي هي أن يكون لديك CollectionView مشابه لـ ItemsControl في Windows XAML. تأخذ ItemsControl مثيل Panel الذي يضع العناصر. في النماذج ، سيكون لدينا CollectionView و IItemsLayout.
بشكل افتراضي ، إذا لم يتم توفير IItemLayout ، يمكن أن يكون التخطيط الافتراضي تخطيط مكدس. وبهذه الطريقة ، يمكن أن نحصل بشكل أساسي على ItemsSource مدمجًا مع StackPanel من Windows XAML ، أو بعبارة أخرى ، StackLayout قابل للربط!

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

1. سأعيد تسمية واجهة IItemsLayout إلى ICollectionViewLayout. إطار العمل يحتوي بالفعل على Layout و ItemsView . سيكون اسمًا أطول ، لكن ICollectionViewLayout هو مؤشر قوي على الغرض منه ، فهو خاص بـ CollectionView ، وليس طريقة عامة لعرض العناصر.

2. سأعيد تسمية فئة ItemsLayout إلى OrientedCollectionViewLayout. إنه مؤشر قوي على ما هي الفئة الأساسية المجردة حقًا ، حيث تقوم جميع الفئات المشتقة بتخطيط العناصر بطريقة موجهة. علاوة على ذلك ، فإن استخدام "Oriented" في الاسم يمنح الخيار في المستقبل لإضافة فئة أساسية مجردة تسمى فقط "CollectionViewLayout". إذا كانت بعض الوظائف المشتركة الجديدة مطلوبة لجميع فئات تخطيط عرض المجموعة ، وليس فقط تلك التي لها اتجاه.

3. إن إزالة ViewCell واستخدام DataTemplate أمر مرحب به للغاية ، فهو يحسن إمكانية إعادة الاستخدام.

1. هل يمكنك مشاركة المزيد من التفاصيل حول RefreshView؟
   أفترض أنه يجب تعيين RefreshView بطريقة ما إلى UIRefreshControl على iOS؟ كيف ستعمل على Android و UWP؟

في حالة اهتمام أي شخص ، قمت بإجراء بعض التحديثات لتعليقي الأول أعلاه.

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

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

bmacombe أتفق معك في أنه من "السهل" تنفيذ StackLayout القابل للربط ، لكن هذا ليس هو الهدف على ما أعتقد. إنها وظيفة شائعة جدًا ، فلماذا لا يتم وضعها في إطار العمل؟ ومع بعض التخطيط ، أعتقد أنه يمكن القيام بذلك. كما قلت أعلاه ، يمكن حلها بمجرد نشر الوظائف في فئتين ، فئة أساسية (على غرار ItemsControl في Windows XAML) و CollectionView (ListView). من الناحية المثالية ، يجب أن يكون هناك فئة محدد في التسلسل الهرمي (راجع https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.primitives.selector)

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

إذا قمت بذلك ، في الوقت الحالي لا يوصى بوضع ListView في ScrollView. إن عرض CollectionView القابل للربط الذي يمكنك وضعه هناك ، والذي لا يزال يحتمل أن يحتوي على جميع ميزات ListView ، هو شيء كنت أحتاجه عدة مرات.

لقد كتبت نفس الشيء BindableStack الذي يفعله أي شخص آخر ، لكن المخبوز في واحد سيكون أفضل بكثير للعمل معه.

adammeaney هذا منطقي ولقد فعلت نفس الشيء الآن بعد أن أفكر فيه.

andreinitescu لا أوافق ، سيكون رائعًا أن يتم

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

bmacombe مع بعض التخطيط ، آمل أن نتمكن من الحصول على عصفورين بحجر واحد.
على سبيل المثال ، مثال لفئة CollectionView تعمل بالطريقة التي ذكرتها ، إذا لم يكن بها مجموعة IItemLayout ، فيمكن فقط تعيينها بواسطة آلية العارض إلى UIStackView الأصلي على iOS أو StackPanel على UWP أو LinearLayout على Android. أو ، لتسهيل التنفيذ ، يمكن فقط استخدام StackLayout الحالي لترتيب العروض.

كان انطباعي أن ListView الجديد يجب أن يهدف إلى إصلاح التحديات باستخدام ListView الحالي ولكن أيضًا توفير حل لسلسلة "RepeatableBinder" هنا

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

لا أرى كيف يؤدي وضع جميع الوظائف في CollectionView مثل المواصفات هنا إلى القيام بالمهمة بشكل صحيح.

2680 يمكن أن يضاف إلى هذه المواصفات؟ فيما يتعلق بتمكين ScrollBar.

تضمين التغريدة

هل يمكنك مشاركة المزيد من التفاصيل حول RefreshView؟
أفترض أنه يجب تعيين RefreshView بطريقة ما إلى UIRefreshControl على iOS؟ كيف ستعمل على Android و UWP؟

في UWP ، RefreshContainer . على نظام Android ، ربما SwipeRefreshLayout .

تضمين التغريدة

يستخدم iOS بالفعل اسم UICollectionView ، والذي قد يؤدي إلى حدوث ارتباك ونتائج غير صحيحة في google عند البحث عن CollectionView. هذا هو مشكلة؟

إنها مشكلة ، لكنها ليست مشكلة جديدة. لدينا نفس المشكلة مع GestureRecognizer و ListView و Grid والعديد من الأشياء الأخرى في النماذج. لقد ناضلنا مع هذا داخليًا قليلاً. لا يوجد سوى عدد كبير جدًا من الأسماء الممكنة لـ "مجموعة من العناصر على الشاشة".

لا يتعارض "CollectionView" مع أي شيء لدينا حاليًا في "النماذج" ، ولا يتعارض مع أي أسماء عناصر تحكم UWP (بالطريقة التي تعمل بها "ListView") ، كما أنها ليست _ تمامًا مثل UICollectionView (بسبب بادئة "UI"). إنه ليس مثاليًا بنسبة 100٪ لأغراض البحث ، لكننا نشعر أنه أفضل تعبير عن القصد من عنصر التحكم.

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

(أردت أن أسميها "ListView2ColonRevengeOfTheListView" ، لكن

تضمين التغريدة

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

ألق نظرة على مواصفات SwipeView - هذا هو بالضبط ما نهدف إليه.

تضمين التغريدة

دعم الرموز التراص

هذه نقطة رائعة ، يجب أن ندعمها إن أمكن. أعلم أنه يعمل مع الحروف الرسومية المضمنة في UWP ؛ يجب أن أقوم ببعض البحث للتأكد من أن هذا النوع من التكديس سيعمل على الأنظمة الأساسية الأخرى (أظن أن الإجابة هي "نعم").

تحديث: تم نقل جزء FontIconSource من هذه المواصفات إلى المواصفات الخاصة به .

أود سيناريو مستخدم لعناصر متعددة الانتقاء من تحديد ، على سبيل المثال اختيار صورة واحدة أو أكثر من ألبوم. سيناريو شائع جدًا في تطبيقات مثل OneDrive أو WhatsApp.

تضمين التغريدة

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

لقد اقترحت بالفعل اسمًا جديدًا لأسباب مختلفة

ماذا ستكون قيمة SelectedItem عندما يكون SelectionMode Multiple ؟ هناك 5 خيارات يمكنني التفكير فيها:

1. العنصر الأخير المحدد بترتيب الاختيار.
   
2. العنصر الأخير المحدد بترتيب المصدر.
   
3. آخر عنصر تم تحديده / إلغاء تحديده حسب ترتيب الاختيار.
   
4. آخر عنصر تم تحديده / إلغاء تحديده حسب ترتيب المصدر.
   
5. باطل
   
   
   
   (2) و (3) و (4) ليست مفيدة جدًا. لقد أضفتهم فقط لتغطية جميع الخيارات. (1) يبدو أنه الخيار الأكثر منطقية. (5) إذا كنت لا تريد دعم SelectedItem على الإطلاق إذا كان SelectionMode هو Multiple .

@ AmrAlSayed0

ماذا ستكون قيمة SelectedItem عندما يكون SelectionMode متعدد؟

الجواب الآن هو "كل ما كان عليه قبل التبديل SelectionMode إلى Multiple ".

تضمين التغريدة

أود سيناريو مستخدم للعناصر متعددة الانتقاء من التحديد

هل تسأل عما إذا كان سيناريو الاختيار هذا مدعومًا؟ AFAIK ، جميع عناصر التحكم الأصلية التي نعتزم استخدامها تدعمها ، لذا يجب دعمها في CollectionView.

سيكون النمط القابل للربط لـ SelectionMode مفيدًا ، إذا كان SelectionMode = لا شيء ، وشفاف وما إلى ذلك ، فهذا شيء يفعله Radlist وهو طريقة مفيدة جدًا وسهلة للتعامل مع الحالة المرئية بناءً على الارتباطات. سيغطي نمط لكل وضع تحديد هذه السيناريوهات.

تضمين التغريدة

الرد على تعليقاتك من https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -401015625 (وأماكن أخرى):

أنت تطرح الكثير من النقاط الجيدة ، وأريد أن أتأكد من أنك تعلم أننا لا نتجاهلها. نحن فقط لا نعرف جميع الإجابات حتى الآن. نحن في طور زيادة سرعة واجهة برمجة التطبيقات هذه حتى نتمكن من معرفة مكان عملها وأين تتفكك ؛ أظن أن تقسيم الفصل الذي تقترحه قريب جدًا من المكان الذي سنحتاج إليه في النهاية.

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

تضمين التغريدة

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

ستكون الطرق UpdateX في برامج العرض هي protected virtual . :)

بكل جدية ، نحن ندرك أن هذه كانت نقطة ألم في الماضي ، ونحن نضعها في الاعتبار أثناء كتابة CollectionView .

1. عند التفكير الثاني ، لا أعتقد حقًا أن CollectionView هو اختيار جيد لاسم فئة هذا العرض.
   في Windows XAML ، CollectionView هي الفئة الأساسية لمصدر بيانات العناصر المستخدمة لتصفية التجميع ، راجع https://msdn.microsoft.com/en-us/library/system.windows.data.collectionview (v = vs. 110) .aspx
   ربما ستحصل نماذج Xamarin في وقت ما على فصل دراسي للغرض نفسه ، وأعتقد أنه سيكون من المنطقي أن يكون له نفس الاسم (CollectionView) ، خاصة عند التفكير في معيار XAML (هل لا يزال هذا مخططًا؟)

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

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

   _ إرشادات تصميم الإطار: الاصطلاحات والتعابير والأنماط الخاصة بمكتبات .NET القابلة لإعادة الاستخدام ، الإصدار الثاني_
   https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions

   في مرحلة ما لاحقًا ، سيستخدم الجميع اللون الجديد اللامع. ListView2 مستقرة وفعالة :). التقديم السريع ، إعادة تسمية ListView2 إلى ListView ، وإن كان تغييرًا جذريًا ، سيكون إعادة بناء بسيط (ومرحب به) للجميع.

2. في نماذج Xamarin هناك عنصر عرض العناصر بالفعلالذي يبدو قريبًا جدًا من ItemsControl في Windows XAML ، إلا أنه لا يحتوي على خاصية تخطيط العناصر.
   بدلاً من إنشاء فئة CollectionView جديدة ، هل سيكون من الممكن استخدام ItemsView الحاليةأيضًا كفئة أساسية لـ ListView الجديد؟

3. هناك تحدٍ واضح في تصميم واجهة برمجة التطبيقات وتنفيذها ، باستخدام عناصر تحكم النظام الأساسي الأصلية التي تعرض عناصر قائمة ولكن لا تزال تتمتع بالمرونة لامتلاك شيء مثل "BindableRepeater" الذي يُقصد به عرض عنصر بسيط وأخف وزنا وغير قابل للتمرير وغير قابل للتمرير -قائمة العناصر القابلة للتحديد.
   يبدو أن Uno تمكن من فعل ذلك:

   • https://github.com/nventive/Uno/blob/master/doc/articles/ListViewBase.md#internal -implementation
   • ListViewBase: https://github.com/nventive/Uno/blob/master/src/Uno.UI/UI/Xaml/Controls/ListViewBase/ListViewBase.cs
   • عناصر التحكم: https://github.com/nventive/Uno/blob/master/src/Uno.UI/UI/Xaml/Controls/ItemsControl/ItemsControl.cs

بدلاً من إنشاء فئة CollectionView جديدة ، هل سيكون من الممكن استخدام ItemsView الحالية أيضًا كفئة أساسية لـ ListView الجديد؟

هناك ItemsView<T> ، لكننا لا نريد استخدام ذلك. إنه يستخدم TemplatedItemsList ، وهو جزء من المشكلة التي نحاول تجنبها باستخدام هذا التحكم الجديد.

في مرحلة ما لاحقًا ، سيستخدم الجميع اللون الجديد اللامع. ListView2 مستقرة وفعالة :). التقديم السريع ، إعادة تسمية ListView2 إلى ListView ، وإن كان تغييرًا جذريًا ، سيكون إعادة بناء بسيط (ومرحب به) للجميع.

إن تفاؤلك ساحر ، لكن علينا أن نعمل على افتراض أن ListView (1) ستظل إلى الأبد ، وأنه لن يُسمح بتغيير جذري مثل إعادة تسمية ListView2.

اعتقدت أن كونك على قدم المساواة مع Windows XAML أمر منطقي ، ولكن حسنًا ، استخدم أي اسم تريده ، طالما أن عنصر التحكم الجديد يفي بوعده. يبدو أن إطار عمل Uno قد نجح في القيام بذلك ، لذلك أنا الآن حريص على رؤية ما تجلبه يا رفاق في نماذج Xamarin.

تضمين التغريدة

https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -400925994

نقطة جيدة. لقد أضفت ذلك مؤقتًا إلى واجهة برمجة التطبيقات. أقول مبدئيًا ، لأنني أستطيع أن أرى تمامًا كيف يمكننا تنفيذه على iOS و Android ، لكن UWP قد يكون صعبًا.

لكن لا يمكنني أن أنكر أنهما منطقيان ومتماثلان بشكل ممتع.

ماذا عن إضافة GroupItemsBinding ؟

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

أي المثال المستخدم في وثائق GroupDisplayBinding يمكن أن يكون:

ج #
class Group // لاحظ أن المجموعة لا يجب أن تشتق من ObservableCollection
{
public Group (string firstInitial) {FirstInitial = firstInitial؛ }

public string FirstInitial { get; private set; }

public ObservableCollection<Person> Persons { get; set; } // We use a property for the group items instead

}

ListView CreateListView ()
{
var listView = new ListView {
GroupItemsBinding = ربط جديد (nameof (Group.Persons))
// ...
} ؛
// ...
}

""

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

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

titonton هذه المشكلة مخصصة فقط لمناقشة مواصفات CollectionView ، لم يبدأ التنفيذ حتى الآن ، ولا أعتقد أنه سيحدث حتى يتم الانتهاء من المواصفات.

@ AmrAlSayed0 في الواقع كان يجب أن يبدأ لأنه تم نقله إلى "قيد التقدم في Sprint 139" منذ 11 يومًا.

من غير الواضح تمامًا كيف بدأ هذا نظرًا لأنه ليس من الواضح ما هو القرار بشأن واجهة برمجة التطبيقات

opcodewriter هذا ما كنت أفكر فيه. @ AmrAlSayed0 شكرا على التوضيح.

هل يمكن لأحد أن يوضح ما هي الحالة الحالية لهذه المواصفات؟ هل هناك شيء مفقود حيث يمكن للمجتمع أن يساعد؟

migueldeicazahartez تسمية هذه ستكون صعبة إذا كنت لا تريد أن يكون اسمه CollectionView . ماذا عن CatalogView ؟

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

عينة:

hartez هل تشعر أن واجهات برمجة التطبيقات على وشك الاكتمال الآن؟ ما مقدار العمل الذي تم إنجازه في هذا الشأن حتى الآن؟ يود الكثير منا وضع أيدينا على هذا التحكم في أسرع وقت ممكن. :)

@ adrianknight89 أعتقد أن هذا هو فرع العمل. https://github.com/xamarin/Xamarin.Forms/tree/lv2spike

لا نتوقع أن يكون جاهزًا للمعاينة لفترة من الوقت حتى الآن ، لكنني سأعرض / أعرض نتائج الجهد الحالي في الأسابيع القادمة للتحقق من صحة التقدم وردود الفعل السريعة.

أنا مرتبك. نظرًا لأن لديك بالفعل بعض العروض التوضيحية الداخلية ، يبدو أنك بعيد جدًا عن التنفيذ.
ألا يجب أن يعني هذا أنه قد تم تسمير العديد من API؟ هل تتابع مواصفات API هنا؟
لا أستطيع أن أرى كيف ستتمكن المواصفات الحالية من معالجة ما تمت مناقشته هنا وعلى الخيط الآخر هنا https://github.com/xamarin/Xamarin.Forms/issues/1718
لكي تكون أكثر دقة ، فإن واجهة برمجة التطبيقات ليست مرنة بما يكفي للسماح على سبيل المثال بعنصر تحكم بسيط يشبه StackLayout غير قابل للتمرير وقابل للربط.

هل يسمح عنصر التحكم الجديد بوضع العناصر المربوطة في مكدس ، بدون شريط تمرير ، تمامًا مثل StackLayout؟

انتظرت شكرا طويلا لهذا 👍

بعد قدر كبير من المناقشة الداخلية ومحاولات العمل على بنية مناسبة ، قررنا أن CollectionView لن تتعامل مع سيناريوهات التخطيط التي تمت مناقشتها في # 1718. بمعنى آخر ، لن يتم التعامل مع ربط مجموعة من العناصر بالعناصر الموجودة في أي تخطيطات Xamarin.Forms.

كان الهدف الأصلي من CollectionView هو السماح للمستخدمين بسهولة تسخير مختلف عناصر التحكم القائمة / الشبكة الحديثة (UICollectionView ، RecyclerView ، ListView / GridView ، إلخ).

لقد كان من المغري محاولة جعل CollectionView تحكمًا شاملاً لجميع احتياجات "العرض والترتيب لهذا النموذج مع البيانات" للجميع ، بما في ذلك جميع السيناريوهات التي تم فيها التعامل مع خطوة "الترتيب" بواسطة Forms Layouts (FlexLayout ، StackLayout ، إلخ. ). وهناك بعض التداخلات الواضحة في الوظائف (على سبيل المثال ، يستخدم كلا السيناريوهين DataTemplates). لكن في النهاية ، لديهم اختلاف جوهري كبير في البنية ، ومحاولة ربطهم معًا ستؤدي إلى شيء أكثر صعوبة في الحفاظ عليه ومربكًا من تركهم كعناصر تحكم منفصلة. لم نرغب في إنشاء شيء معقد للغاية بحيث انتهى بنا الأمر إلى تنفيذ ListView3 في غضون عامين. سأشرح ذلك أكثر أدناه.

والنتيجة هي أن CollectionView ستظل تركز على مشكلة السماح لمستخدمي النماذج باستخدام عناصر تحكم القائمة / الشبكة الأصلية والاستفادة من محركات التخطيط والمحاكاة الافتراضية. وسيتم تحديث # 1718 ليعكس واجهة برمجة تطبيقات تسمح لمستخدمي النماذج بربط ItemsSource و ItemTemplate بمحركات تخطيط النماذج المختلفة.

للمهتمين بـ _لماذا_ عنصري تحكم مقابل عنصر واحد:

الاختلاف الأساسي بين ما تم تحديده هنا (مثل CollectionView) والاقتراح في # 1718 هو _ حيث_ يحدث التخطيط.

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

لذا فإن أي معلومات تخطيط يقدمها المطور إلى CollectionView يتم تمريرها فقط إلى العارض على كل نظام أساسي للتفسير ؛ إنها مواصفات تُترجم إلى اللغة المحلية (LinearLayoutManager / GridLayoutManager على Android ، UICollectionViewFlowLayout على iOS ، وما إلى ذلك). خارج DataTemplate ، لا تقوم النماذج بأي من أعمال التخطيط.

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

تؤدي محاولة ربط هذين الأمرين معًا إلى طرح بعض الأسئلة الصعبة ، بما في ذلك:

1. كيف يعمل تعيين العارض؟ يحتوي CollectionView الذي يستخدم StackLayout على عارض مختلف تمامًا عن CollectionView الذي يحتاج إلى استخدام RecyclerView. هل نمزجها معًا ونخفي RecyclerView عندما لا نحتاجها؟ هل لدينا العارض مشتق من DefaultRenderer؟ إذا فعلنا ذلك ، فلدينا دائمًا طبقة ViewGroup إضافية لا نحتاجها حقًا ...

2. كيف نتعامل مع ScrollViews؟ يتعامل UICollectionView مع عرض التمرير الخاص به ، ولكن إذا احتاج StackLayout إلى التمرير ، فعادة ما يضيفه المستخدم يدويًا في النماذج. هل نضيف طبقة أخرى لإدراج التمرير تلقائيًا إذا لزم الأمر؟ هل نقوم بتعطيل / إزالة ScrollView المضافة يدويًا إذا كان التخطيط يستدعي عرض UICollectionView؟

3. لهذه المسألة ، أين تذهب طرق ScrollTo؟

... وما إلى ذلك وهلم جرا. كل هذه المشاكل _ قابلة للحل_ ، لكن كل حل يضيف تعقيدًا. وكما تمت الإشارة إليه في # 1718 ، فإن إضافة ItemsSource و ItemsTemplate إلى تنسيق Forms ليست بهذه الصعوبة أو التعقيد. إن جعل الأمر معقدًا لمجرد دمج هذين السيناريوهين المميزين معًا لا يستحق الفوائد.

أنا مرتبك. نظرًا لأن لديك بالفعل بعض العروض التوضيحية الداخلية ، يبدو أنك بعيد جدًا عن التنفيذ. ألا يجب أن يعني هذا أنه قد تم تسمير العديد من API؟ هل تتابع مواصفات API هنا؟

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

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

صحيح ، وجزء مما كنا نعمل عليه هو تحديد ما إذا كان CollectionView _could_ يمكنه تغطية حالات الاستخدام هذه بشكل معقول. لقد توصلنا إلى قرار بشأن ذلك ؛ انظر https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment -424413234.

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

كما قلت (https://github.com/xamarin/Xamarin.Forms/issues/3172#issuecomment-401186893) ، أنا منفتح على أسماء أخرى.

ماذا عن CatalogView؟

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

هذه فكرة تثير الاهتمام. بالتأكيد لا يتعارض مع أي أسماء تحكم حالية.

hartez كشخص عشوائي على الإنترنت ، أصبح أكثر دراية بالأجزاء الداخلية لنماذج Xamarin (وكان بالفعل على دراية تامة بـ UITableView و UICollectionView) أعتقد أن هذه هي الخطوة الصحيحة.

هل سيظل من الممكن توفير تخطيط مخصص (حتى لو كان ذلك يعني توفير عمليات تنفيذ منفصلة لكل نظام أساسي)؟

هل سيظل من الممكن توفير تخطيط مخصص (حتى لو كان ذلك يعني توفير عمليات تنفيذ منفصلة لكل نظام أساسي)؟

قطعا. يمكنك تقديم تخطيطك الخاص المميز بعلامة IItemsLayout ويمكن للعارض المخصص تفسيره كما تريد.

على سبيل المثال ، كدليل على المفهوم ، قمت بتصنيف عارض Android لـ CollectionView وأضفت القدرة على تفسير فئة FlexLayout : IItemsLayout والتي تضمنت مجموعة من خصائص Flex Layout. يقوم بتمرير هذه الخصائص إلى FlexBoxLayoutManager من Google ويستخدم مدير التخطيط هذا مع RecyclerView. بمجرد إتاحة معاينة عامة ، ربما سأقوم بإلقاء هذا المثال على GitHub حتى يكون لدى الأشخاص مرجع سهل حول كيفية القيام بهذا النوع من الأشياء.

الهدف هو جعل هذا الشيء شديد المرونة.

تضمين التغريدة
هل المشكلة الموضحة في https://github.com/xamarin/Xamarin.Forms/issues/3749 تم إصلاحها باستخدام CollectionView؟
لأنني أرى هنا أن CollectionView به خاصية ItemTemplate ، والتي يبدو أنها ستواجه نفس المشكلة مثل ListView .

تضمين التغريدة
هل المشكلة الموضحة في # 3749 تم إصلاحها باستخدام CollectionView؟
لأنني أرى هنا أن CollectionView به خاصية ItemTemplate ، والتي يبدو أنها ستواجه نفس المشكلة مثل ListView .

andreinitescu شكرًا على الإشارة إلى تلك المناقشة ، لم أكن على علم بهذه المشكلة مع DataTemplate.

سأقضي بعض الوقت الأسبوع المقبل في البحث في تاريخ DataTemplate - لماذا تم تصميمه بهذه الطريقة ، وما إذا كانت هناك أي مشكلات تتعلق بالتوافق مع الإصدارات السابقة مع إصلاح CreateContent لفعل الشيء الصحيح تلقائيًا (كلاهما في ListView و CollectionView).

hartez فقط كمثال لكيفية

// تحقق لمعرفة ما إذا كان لدينا محدد قالب أم مجرد قالب
var templateToUse = itemTemplate هو محدد قالب DataTemplateSelector؟ templateSelector.SelectTemplate (item، null): itemTemplate؛

لذلك في حالة من هذا القبيل ، لن يؤدي مجرد إصلاح CreateContent إلى كسرها ، فقط اجعلها غير ضرورية. لكنني أتفق مع andreinitescu على أن فصل ItemTemplate و ItemTemplateSelector كخصائص منفصلة سيكون مثاليًا ... ربما بسبب خلفية WPF و SL الخاصة بي.

bmacombe IMHO ، إنها ليست فقط مسألة تفضيل جعلها تتماشى مع WPF / SL ، إنها حقًا مشكلة ، إنها تسبب الارتباك. انظر # 3544

andreinitescu إنها تخلق ارتباكًا :) صدقني ، لقد كنت مرتبكًا في البداية عندما كنت أحاول دعم DataTemplate و DataTemplateSelector في مكرر البيانات الخاص بي! خاصةً عندما يكون هناك خطأ عندما قمت بتعيين DateTemplateSelector إلى خاصية DataTemplate الخاصة بي عندما كانت تعمل في جميع أماكن XF التي استخدمتها. أخذ بعض حفر شفرة المصدر لمعرفة ذلك. ربما لا يمثل ذلك مشكلة لشخص يستخدم فقط عناصر تحكم XF المدمجة ، ولكن محاولة امتلاكه واستخدامه ... أمر محير حقًا.

هل يمكننا الحصول على حدث التمرير من فضلك على CollectionView؟ حتى يتم إصدار CollectionView ، لدي اقتراح لـ ListView https://github.com/xamarin/Xamarin.Forms/issues/4323

وهل سيكون من الممكن إنشاء تخطيطات غير منتظمة وديناميكية ، مثل PInterest على سبيل المثال:

كما ترى ، كل صورة لها ارتفاعها الخاص :-)

ألست متأكدًا من إمكانية دعم هذا النوع من التخطيط؟

تحديث: من قائمة اقتراحات الأسماء ، أقرب ما توصلنا إليه هو "ItemsView" ، وذلك لتجنب استخدام مصطلح "CollectionView" الذي يعطي الناس انطباعًا بأن هذا كامل مثل نظام iOS "UICollectionView"

مرحبًا ، ما زلت جديدًا على Xamarin ، لكني أعمل مع ListView باستخدام DataTemplateSelector.
عندما حاولت اختبار استخدام CollectionView مع DataTemplateSelector ، حدث خطأ

استثناء غير معالج:

System.InvalidOperationException: يجب ألا يكون LoadTemplate فارغًا

هل هناك خطأ معروف متعلق بـ DataTemplateSelector؟
يمكن أن أكون تنفيذها بشكل خاطئ. هل هناك أي مثال على استخدام DataTemplateSelector مع CollectionView؟

hartezdavidortinau لأي سبب من الأسباب لعدم تسمية KeepItemsInView KeepFirstItemInView للتوافق مع KeepLastItemInView ؟ الاسم الحالي هو جمع (أي يقترح عدة عناصر) بينما يقول الوصف أنه يحتفظ فقط بالعنصر المرئي الأول في منفذ العرض.

أيضًا ، هل هناك طريقة يمكنك من خلالها الكشف عن واجهة برمجة التطبيقات للحصول على قائمة العروض الموجودة حاليًا في منفذ العرض؟ في الليلة الماضية ، كنت أعمل على إنشاء عرض فيديو ليتم تضمينه في خلية ListView ويتم تشغيله تلقائيًا / إيقافه مؤقتًا بناءً على رؤية منفذ العرض ، ولكن كان من المستحيل تقريبًا مع ItemAppearing و ItemDisappearing الحاليين أحداث CollectionView لدعم هذا النوع من الوظائف بطريقة أكثر موثوقية.

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

لذلك لعبت مع الإصدار الليلي الحالي قليلاً (4.0.1.43780-nightly) والذي حل بعض مشكلات تغيير الحجم مقارنةً ببنية المعاينة الحالية.

اقتراح لدي هو إضافة شيء مثل RowSpacing / ColumnSpacing أو GridSpacing إلى تخطيطات الشبكة لأن ذلك يجعل من الأسهل بكثير وضع العناصر الخاصة بك بشكل صحيح دون استخدام الهامش / الحشو على العناصر الفردية.
شيء آخر هو إضافة Padding أو ربما EdgeOffset إلى CollectionView أو Layout لتجنب استخدام الهامش ، الذي يقطع العناصر كما هو موضح هنا:

يعمل الهامش أيضًا على اقتصاص الرسوم المتحركة "السحب" على Android كما ترى هنا:

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

متفق عليه ، وهذا على رادارنا - انظر # 4681.

تحديث: من قائمة اقتراحات الأسماء ، أقرب ما توصلنا إليه هو "ItemsView" ، وذلك لتجنب استخدام مصطلح "CollectionView" الذي يعطي الناس انطباعًا بأن هذا كامل مثل نظام iOS "UICollectionView"

ماذا عن "FloatView"؟

بجانب أحداث ItemAppearing / Disappearing المذكورة أعلاه ، أي خطط لطرق عرض عنصر ما:
View GetView(object item)
إذا لم يتم تحقيق العنصر ، فيجب أن يعود فارغًا على ما أعتقد.

أنا أستخدم قائمة عمودية ويبدو أن هناك تناقضات في كيفية عرضها على iOS مقابل Android.

على نظام iOS ، ستشغل التسمية 100٪ من العرض.

على نظام Android ، سيستغرق عرض المحتوى فقط.

يمكنني فقط الحصول عليه للتخطيط بشكل صحيح مع تعريف عرض ثابت.
هل هناك حل بديل لنظام Android يحترم خاصية Grid Width="Auto" ؟

أنا أستخدم قائمة عمودية ويبدو أن هناك تناقضات في كيفية عرضها على iOS مقابل Android.

shwanton الرجاء فتح مشكلة منفصلة لهذا الخطأ ،

shwanton كانت لدي مشكلات مماثلة تم إصلاحها عندما انتقلت إلى التغذية الليلية

krdmllr أستطيع أن أؤكد أنه تم إصلاحه في أحدث بناء. شكرا لك.

مرحبا. هل سيكون هناك حدث ItemTapped في CollectionView مشابه لـ ItemTapped في ListView؟ أنا لا أرى ذلك في المواصفات. شكرا لك.

uvirra هناك مشكلة حالية DataTemplateSelector . انظر # 4826.

hartez هل ستكون هناك حاجة على الإطلاق لإستراتيجية إعادة تدوير عنصر مثل تلك الثلاثة الموجودة مقابل ListView ؟ لقد ذكرت عدة مرات المحاكاة الافتراضية الأصلية التي تستفيد منها CollectionView . أريد فقط الحصول على مزيد من التوضيح حول هذا الموضوع.

لدي فضول أيضًا لمعرفة كيف سيبدو RefreshView على iOS. التحديث الحالي لـ ListView يتطلب UITableView 's Bounces الخاصية قيد التشغيل بينما ، في Android ، يتم سحب عرض التحديث أعلى العنصر الأكثر ظهورًا (والذي أنا شخصيا أفضل).

hartez هل ستكون هناك حاجة على الإطلاق لإستراتيجية إعادة تدوير عنصر مثل تلك الثلاثة الموجودة مقابل ListView ؟ لقد ذكرت عدة مرات المحاكاة الافتراضية الأصلية التي تستفيد منها CollectionView . أريد فقط الحصول على مزيد من التوضيح حول هذا الموضوع.

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

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

ماذا عن الحدث الذي تم تمريره؟ توفر معظم UI / UX الحديثة رأس المنظر وإظهار / إخفاء العناصر (الأزرار والعناوين والمرشحات و ecc ..) عند التمرير وما شابه.
أعتقد أن عنصر تحكم جديد ومذهل مثل هذا يجب أن يدعم السيناريوهات الحديثة.

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

حتى عرض Carouselview (استنادًا إلى عرض المجموعة) يدعم الحدث الذي تم تمريره مع الاتجاه وقيمة التمرير والدلتا: https://github.com/xamarin/Xamarin.Forms/issues/4996

لمتابعة تعليق Evolutionlab على كونه عنصر تحكم جديد

https://docs.microsoft.com/en-us/windows/uwp/debug-test-perf/listview-and-gridview-data-optimization

إذا كان هذا أمرًا يصعب فهمه ، فأنا أرغب في الوصول إلى VisibleItems حتى أتمكن من إجراء المحاكاة الافتراضية في ViewModel الخاص بي بدلاً من ذلك.

استمروا في العمل العظيم!

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

يمكن القيام بذلك أيضًا عن طريق تعيين SelectedItems (الذي لم يتم تنفيذه بعد) على حدث SelectionChanged بناءً على حساب CurrentSelection ، ولكن هذا سيؤدي إلى تشغيل SelectionChanged مرتين. في رأيي ، يجب أن يكون لدينا طريقة للتحكم بشكل استباقي في سلوك الاختيار قبل أن يصل أي شيء إلى Core.

باللعب مع CollectionView اليوم قليلاً ، لاحظت أن UWP متأخر كثيرًا عن Android و iOS ، وهذا هو السبب وراء ذلك.

هل تريد فقط التأكيد على أنه من المخطط الحصول على دعم UWP الكامل عند الانتهاء؟

بجانب أحداث ItemAppearing / Disappearing المذكورة أعلاه ، أي خطط لطرق عرض عنصر ما:
View GetView(object item)
إذا لم يتم تحقيق العنصر ، فيجب أن يعود فارغًا على ما أعتقد.

ماذا عن ظهور العنصر؟ لا أرى أي أخبار عنه

كنت ألعب مع CollectionView وكنت أواجه مشاكل مع ارتفاع الصف غير المتكافئ. رأيت أنه كان هناك ItemSizingStrategy تقديمه مؤخرًا ، لكنه لا يزال يتصرف بشكل غريب.

لعبت مع DataTemplateGallery وعند التبديل إلى MeasureAllItems أحصل على النتيجة التالية (iPhone 6 ، iOS 12.1.4):

بعد التمرير سريعًا جهة اليمين والعودة ، تتغير النتيجة إلى:

hartez هل من المتوقع أن يعمل هذا أو لا يزال قيد التقدم (تعذر العثور على أي مشكلة لذلك)؟

هل تم تنفيذ RemainingItemsThresholdReached بعد؟

لا يتوفر على عنصر التحكم CollectionView XAML في 4.0.0.169046-pre5.

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

Dresel هل يمكنك فتح تذكرة جديدة إذا كنت تعتقد أن هذا خطأ؟ من الأفضل أن يتم تعقبها.

melucaschandrubk لا أعتقد RemainingItemsThresholdReached يجري العمل على حتى الان.

https://github.com/xamarin/Xamarin.Forms/branches/all

أود أيضًا أن أرى هذه الميزة (جنبًا إلى جنب مع عرض التحديث) تم تنفيذها قريبًا حيث لا يمكنني لمس CollectionView بدونها.

4323

نحتاج إلى حدث Scrolled مثل ScrollView

مع تحياتي،

4323

نحتاج إلى حدث Scrolled مثل ScrollView

مع تحياتي،

أنا أؤيد هذا.
علاوة على ذلك ، سيكون من الرائع الحصول على حدث عند إيقاف / انتهاء التمرير.

في IOS ، تعد UICollectionview فئة فرعية من UIScrollview ، لذلك يمكننا الحصول على scrollViewDidEndDecelerating من UIScrollViewDelegate

في Android ، أعتقد أنه يمكننا تمديد RecyclerView.OnScrollListener ؟

سيؤدي هذا إلى فتح سيناريوهات أكثر تقدمًا ومصقولًا للتحديث المخصص ، والمنظر ، وعناصر التمرير المتزامنة ، إلخ.

هل هناك أي فرصة لوجود رسوم متحركة خارج الصندوق لنظام Android ، مثل تلك الموجودة في Recycler View؟

هل هناك أي فرصة لوجود رسوم متحركة خارج الصندوق لنظام Android ، مثل تلك الموجودة في Recycler View؟

ما هي الرسوم المتحركة التي تشير إليها؟ تم بناء عارض Android لهذا على RecyclerView ، لذلك يستخدم بالفعل الرسوم المتحركة الافتراضية لأشياء مثل إضافة / إزالة العناصر.

مرحبا،

أنا أستخدم 4.0.0.304370-pre8.
المثال من (الرابط أدناه) لا يعرض أي شيء على UWP ، عند استخدام CarouselView.
لكن CollectionView يعرض القائمة. هل هناك أي تكوين محدد مطلوب لتمكين CarouselView لـ UWP؟

https://devblogs.microsoft.com/xamarin/xamarin-forms-4-0-feature-preview-an-entirely-new-point-of-collectionview/

شكرا.

مرحبًا noypi ،

بينما يمكن لـ CollectionView "العمل" تقنيًا بدرجة صغيرة إلى حد ما على UWP ، فإن التنفيذ الكامل لـ CollectionView و CarouselView يتم بشكل صارم على Android و iOS لتبدأ. لم تتم جدولة أي عمل رسمي لـ UWP في الوقت الحالي ، ولكننا نجمع التعليقات باستمرار. إذا كنت ترغب في مناقشة نوع العمل الذي تقوم به على UWP على وجه الخصوص ، يمكنك إرسال بريد إلكتروني إلي على Paul. [email protected].

وفقًا للمواصفات ، هل سيتم استبدال TableView بـ CollectionView بالكامل؟

سؤال آخر: نظرًا لعدم وجود خلايا بعد الآن ، كيف تضيف مؤشر ديسكلور لنظام iOS؟ مع ListView كان ذلك ممكنًا عبر العارض المخصص.

وفقًا للمواصفات ، هل سيتم استبدال TableView بـ CollectionView بالكامل؟

سيظل TableView موجودًا. لن نقوم بإزالة أي عناصر تحكم موجودة.

سؤال آخر: نظرًا لعدم وجود خلايا بعد الآن ، كيف تضيف مؤشر ديسكلور لنظام iOS؟ مع ListView كان ذلك ممكنًا عبر العارض المخصص.

على نظام iOS ، يتم عرض CollectionView باستخدام UICollectionView ، مما يعني أن خلاياها هي UICollectionViewCells. ولا تمتلك UICollectionViewCells عروض ملحقة (مثل مؤشرات الكشف). لذلك بالنسبة لأي عناصر واجهة مستخدم مثل مؤشرات الكشف أو علامات الاختيار ، ستحتاج إلى إنشاء تلك الموجودة في ItemTemplate.

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

hartez عند تعيين ItemTemplate إلى DataTemplateSelector أحصل على استثناء: System.InvalidOperationException: LoadTemplate should not be null

اعتقدت أنه سيتم دعم القوالب خارج الصندوق

hartez عند تعيين ItemTemplate إلى DataTemplateSelector أحصل على استثناء: System.InvalidOperationException: LoadTemplate should not be null

اعتقدت أنه سيتم دعم القوالب خارج الصندوق

يجب أن يكونوا ؛ ربما كنت تواجه خطأ. الرجاء فتح مشكلة حتى نتمكن من التحقيق.

toomasz قبل فتح أي إصدار ، هل يمكنك تحديث Nuget إلى أحدث إصدار سابق (أو كل ليلة) واختبار المحدِّد مرة أخرى؟ كانت المشكلة التي تراها موجودة عندما لم يكن هناك دعم لـ DataTemplateSelector .

hartez هل يتم حاليًا إجراء أي عمل على رأس الصفحة

@ adrianknight89 يعمل على 4.0! مدهش

hartez هل يتم حاليًا إجراء أي عمل على رأس الصفحة

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

هل هناك خطة لدعم عرض المجموعة على UWP؟

نعم. التنفيذ متأخر قليلاً عن الأنظمة الأساسية الأخرى في الوقت الحالي ، لكن الخطة هي دعمه بالكامل. يمكنك متابعة تقدم الميزة على https://gist.github.com/hartez/7d0edd4182dbc7de65cebc6c67f72e14

أي معلومات عن RefreshView؟
لدي أحدث إصدار تجريبي من Xamarin 4 ولا يمكن العثور على نوع RefreshView

أي معلومات عن RefreshView؟
لدي أحدث إصدار تجريبي من Xamarin 4 ولا يمكن العثور على نوع RefreshView

لم يتم تنفيذ RefreshView حتى الآن. يمكنك تتبع تقدم الميزة هنا .

إضافة GroupItemsBinding ؟

ماذا عن إضافة خاصية GroupItemsBinding لتحديد الخاصية التي تحتوي على العناصر الفرعية للمجموعة؟ سيسمح ذلك بتضمين خاصية مجموعة فرعية بدلاً من إجبار المجموعات على الوراثة من مجموعة.

مزايا:

• القدرة على (إلغاء) إجراء تسلسل للمجموعة المجمعة إلى / من JSON.
  يؤدي توريث المجموعات من مجموعة إلى حظر تسلسل JSON (de) (لأن مصفوفات JSON تدعم نطاقًا من القيم فقط وليس الخصائص). (De) يلزم إجراء تسلسل لنماذج العرض للحفاظ على حالة نموذج العرض عندما ينتقل التطبيق إلى الخلفية ، أو إذا كانت واجهة برمجة تطبيقات التطبيق ترسل لك نماذج عرض. الحل الحالي هو أن يكون لديك بنية بيانات ثانية والقيام بتكرار + تحويل مكلف في كل تحديث للبيانات.
• القدرة على استخدام الفئة الأساسية الخاصة بك لعناصر المجموعة (على سبيل المثال ، ViewModelBase )
• تجنب تلويث كائنات المجموعة بكل الخصائص الموروثة للمجموعة

على سبيل المثال ، يمكنك كتابة مثال التجميع هذا
ج #
فئة عامة PageTypeGroup: قائمة
{
عنوان السلسلة العامة {get؛ تعيين؛ }
// المزيد من الخصائص ...
}

like this instead:

```C#
public class PageTypeGroup
{
    public string Title { get; set; }
    // More properties ...

    public List<PageModel> Children { get; set; }
}

مع XAML:

C# <CollectionView GroupItemsBinding = "{Binding Children}" ...> </CollectionView>

عدم تحديد GroupItemsBinding سيكون متوافقًا مع التنفيذ الحالي ، بما يعادل GroupItemsBinding="{Binding .}"

لقد قدمت هذا الاقتراح في وقت سابق ، في يوليو 2018 .

تحديث 23 أغسطس 2019: تم تنفيذ التجميع ولكن بدون هذا الإصلاح ؛ انظر بيانات المجموعة

آمل ألا يكون الوقت قد فات لإضافة هذا.

ماذا عن دعم مستويات التجميع المتعددة؟
سيسمح بعرض الأشجار .

على سبيل المثال ، يحتوي Flutter على ExpansionTile ( مثال )

فيما يتعلق بـ CollectionView ، واجهت مشكلة أعتقد أنها ستكون ميزة رائعة لإضافتها.

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

أقترح خاصية الوظيفة. ستحتوي هذه الخاصية على فهرس العنصر الحالي. سيسمح هذا بالتكامل السهل لـ ViewPagerIndicator والمؤشرات المماثلة.

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

يمكن أن تتيح هذه الخاصية أيضًا وصولاً سهلاً ثنائي الاتجاه كبديل لـ ScrollTo ().

hartez كنا نتوقع أن يكون هذا جاهزًا للإصدار 4.0 ولكن فوجئنا برؤيته لم ينته بعد. لا يمكننا اختبار CollectionView بدون وظيفة التمرير والتحديث. هل يمكنك إخبارنا بعدد سباقات السرعة التي يجب أن ننتظرها قبل طرحها؟ لقد قررنا عدم شحن أي شيء باستخدام ListView من الآن فصاعدًا ونود أن يكون عنصر التحكم هذا متاحًا في أقرب وقت ممكن.

hartez نحن بحاجة إلى طريقة لـ CollectionView مع تخطيط قائمة لحجم محتويات العناصر. أعتقد أنها حالة استخدام شائعة:

في هذه الأزرار exaple يجب أن تكون مباشرة أسفل عرض المجموعة. أعتقد أنه يجب أن يعمل بهذه الطريقة عندما يكون VerticalOptions هو Start

عندما وصلت عتبة العناصر المتبقية إلى اختبار الملكية

لدي أسئلة حول ما إذا كان تدفق CollectionView لسلوك عنصر فردي يحاكي سلوك iOS الأصلي عندما يتعلق الأمر بتغييرات حجم الشاشة. سأعطيك مثالا:

يتم إنشاء خلية معرض الصور في iOS باستخدام CollectionView ويمكنك تحديد خلية فردية. السلوك خارج الصندوق هو أن عدد الخلايا التي يتم رسمها في صف واحد ديناميكي بناءً على حجم الشاشة. على الهاتف ، قد أضع 4 عناصر ولكن على جهاز لوحي يمكنني أن أضع 8 أو 9 على جهاز لوحي.

هل سيقدم إصدار النماذج هذا أيضًا؟ لقد رأيت حتى الآن المثال الذي قرأته حيث قمت بتعيين خاصية GridItemsLayout Span. ينتج عن هذا قيمة مشفرة ثابتة لعدد العناصر التي يمكن رسمها وفي عالم مختلف أحجام الشاشات ، يبدو الترميز الثابت حتى عام 2014. :-P

UWP لها أربع حالات اختيار
{
لا أحد،
غير مرتبطة
عديد،
تمديد،
}

أعتقد أن Four state في Android و IOS مفيدة أيضًا
ما عليك سوى إلقاء نظرة على مستكشف الملفات

هل هناك أي خطط لخاصية الحشو البسيطة؟ # 6605 بالنسبة لحالة الاستخدام الخاصة الخاصة بي ، ربما يمكنني استخدام رأس وتذييل فارغين بحجم مناسب (بمجرد تطوير هذه الميزات) ، ولكن هذا سيكون نوعًا من الاختراق ولن يكون مناسبًا لتخطيط الشبكة حيث قد يكون الحشو على الجوانب الأربعة تكون مطلوبة.

أي خطة لإعادة ترتيب عنصر القائمة في عرض المجموعة.

هل تغطي المواصفات كيفية تعطيل التحديد لعناصر معينة في CollectionView؟

// Any possible API could be helpful
private void OnSelectionChanging(object sender, SelectionChangingEventArgs e)
{
  if (...)
      e.Cancel = true;
 }

أنا حاليًا أعمل على حل المشكلة ولكن هذا لا يمنع تطبيق VisualState المحدد.

void OnCollectionViewSelectionChanged(object sender, SelectionChangedEventArgs e)
{
    // Deselect the item.
    if (sender is CollectionView cv && e.CurrentSelection...)
    {
        cv.SelectedItem = null;
    }
}

سيكون لون شريط التمرير العمودي ولون شريط التمرير الأفقي رائعين!

ماذا عن اتجاه التمرير ، أعني ابدأ التمرير من اليمين إلى اليسار ، وليس المحتوى نفسه

أود الحصول على فواصل ...

سيكون من الرائع أن يكون لديك إمكانية "حفظ" وتطبيق موضع التمرير.

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

لا يمكنك فعل ذلك مع محدد القوالب بالفعل؟ باستخدام الموقف مع
مشغل modulo؟

في الثلاثاء ، 13 أغسطس 2019 ، الساعة 16:53 م كتب Legacyorder [email protected] :

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

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/xamarin/Xamarin.Forms/issues/3172؟email_source=notifications&email_token=AC4YCKDFCH3WFENRCLPWEC3QELDE3A5CNFSM4FHJRXPKYY3PNVWWK3TUL52HS4DFVREXG43
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AC4YCKHXX5YSR7M3S4VU5QLQELDE3ANCNFSM4FHJRXPA
.

التمرير الدائري سيكون لطيفًا. أعتقد أنه سهل التنفيذ.

أرغب في الحصول على "AbsoluteItemsLayout" كـ ItemsLayout لـ CollectionView لجعل من الممكن تعيين المواضع المطلقة في قائمة ، في الوقت الحالي لا أرى أي حل آخر بدلاً من القيام بذلك في الكود الخلفي.

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

هل يمكنكم أيضً ا فضح حدث التمرير لعنصر التحكم هذا؟ والغرض من ذلك هو عندما أصل إلى أسفل القائمة ، أريد إعادة تحميل عناصر إضافية. لا أعرف ما إذا كانت CollectionView تكتشف ما إذا كانت داخل ScrollView وتعطل إمكانية التمرير.

هل يمكنكم أيضً ا فضح حدث التمرير لعنصر التحكم هذا؟ والغرض من ذلك هو عندما أصل إلى أسفل القائمة ، أريد إعادة تحميل عناصر إضافية. لا أعرف ما إذا كانت CollectionView تكتشف ما إذا كانت داخل ScrollView وتعطل إمكانية التمرير.

تم منح أمنيتك! تحقق من الإصدار 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

يجب ألا تقوم بتضمين CollectionView داخل ScrollView ، وإلا فلن تعمل المحاكاة الافتراضية.

هل يمكنكم أيضً ا فضح حدث التمرير لعنصر التحكم هذا؟ والغرض من ذلك هو عندما أصل إلى أسفل القائمة ، أريد إعادة تحميل عناصر إضافية. لا أعرف ما إذا كانت CollectionView تكتشف ما إذا كانت داخل ScrollView وتعطل إمكانية التمرير.

تم منح أمنيتك! تحقق من الإصدار 4.2 :)
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/scrolling

يجب ألا تقوم بتضمين CollectionView داخل ScrollView ، وإلا فلن تعمل المحاكاة الافتراضية.

أنا في 4.2.0.709249
هل فاتني شيء؟

لدي حدث Scrolled مع 4.2.0.709249.
حاول حذف مجلدات bin / obj وتحقق من دمج NuGet للتأكد.

هل نحصل على دعم RTL قريبًا مع الإصدار 4.2 لنظامي Android و iOS؟

هل نحصل على دعم RTL قريبًا مع الإصدار 4.2 لنظامي Android و iOS؟

بعض الدعم موجود بالفعل ؛ يجب أن يعمل دعم FlowDirection بالفعل داخل عناصر CollectionView. ما زال غير مكتمل هو اتجاه التمرير لتخطيطات CollectionView الأفقية. يجب أن يتطابق اتجاه التمرير مع FlowDirection على نظام Android ، ولكن لا يزال لدينا بعض العمل الذي يتعين علينا القيام به على الأنظمة الأساسية الأخرى ؛ هذا العمل مستهدف للانتهاء في 4.3.

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

هل يمكنك من فضلك وصف ما لم يتم فعله بدعم RTL؟
لأنه في المواصفات ، لم يتم وضع علامة عليه على أنه قيد التقدم أو مكتمل.

في الخميس ، 5 سبتمبر 2019 ، 2:19 صباحًا ، كتب EZ Hart ، [email protected] :

هل نحصل على دعم RTL قريبًا مع الإصدار 4.2 لنظامي Android و iOS؟

بعض الدعم موجود بالفعل ؛ يجب أن يكون دعم FlowDirection موجودًا بالفعل
العمل ضمن CollectionView العناصر. ما زال غير مكتمل هو التمرير
اتجاه تخطيطات CollectionView الأفقية. اتجاه التمرير
يجب أن يتطابق مع FlowDirection على Android ، ولكن لا يزال لدينا بعض العمل
تفعل ذلك على الأنظمة الأساسية الأخرى.

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/xamarin/Xamarin.Forms/issues/3172؟email_source=notifications&email_token=ACDWB3GSYAQSADERHWVTJX3QIANMNA5CNFSM4FHJRXPKYY3PNVWWK3TUL52HS4DFVREXG43
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACDWB3HMFCHBRZWD5AJMXH3QIANMNANCNFSM4FHJRXPA
.

لم يتم: قم بالتمرير في اتجاه التخطيطات الأفقية.

إذا قمت بتعيين FlowDirection = RightToLeft في عرض مجموعة يتم تمريره أفقيًا ، فلن يكون اتجاه التمرير من اليمين إلى اليسار على iOS و UWP الآن (أعتقد أنه يعمل على Android).

ماذا عن بعض LoadingDataTemplate؟

من تجربتي تحميل البيانات غير متزامن في ListView / CollectionView قد تكون هناك مساحة فارغة في بعض الأحيان حتى يتم ملء عرض القائمة / عرض المجموعة.

يمكن أن توفر إضافة LoadingDataTemplate استجابة إضافية عند تعبئة بيانات كبيرة وظهور الصفحة بالفعل.

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

يتطلب العنصر الأول مزيدًا من العمل (على سبيل المثال ، تحميل المصدر مبدئيًا بـ 3-5 عناصر لها نفس قالب بيانات العنصر النائب ثم قم بإزالة تلك العناصر وإضافة البيانات الفعلية عند جلبها). هناك طريقة أخرى تتمثل في وضع عرض هيكلي أعلى CollectionView وإخفائه عندما تكون البيانات جاهزة. أنا حاليًا أتبع هذا الأسلوب باستخدام ListView .

لم أجرب هذا ، ولكن يمكننا تعيين EmptyView لعرض التحميل أولاً وإذا لم تكن هناك نتائج ، فغيّر القالب الخاص بـ EmptyView لإظهار رسالة "لم يتم العثور على أي شيء".

@ adrianknight89

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

هذا يبدو مثل نفس الطريقة التي أتبعها أيضًا ، أي ضع بعض مؤشرات النشاط أعلاه. عيّن ListView إلى IsVisible = false و ActivityIndicator IsVisible = true ، ثم اعكس كلا القيمتين بعد ملء عرض القائمة.

@ adrianknight89

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

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

أوافق على أنه سيكون من الأفضل امتلاك خاصيتين مختلفتين. بخلاف جانب البساطة ، فإن استخدام خاصية واحدة لغرضين مختلفين ليس له معنى كبير. ربما كان من المفترض تسمية EmptyView BackgroundView حتى نتمكن من استخدامه لأي غرض. (تحرير: A BackgroundView شيء مختلف تمامًا.)

LeoJHarris لقد أضفت # 7447 لدعم BackgroundView . يمكننا استخدام EmptyView و BackgroundView لدعم السيناريوهين المذكورين أعلاه على الرغم من أن هذا لا يزال 100٪ ما تريده ، ولكن يجب أن يكون أفضل من استخدام EmptyView لدعم كلا السيناريوهين سيناريوهات. يمكنك استخدام BackgroundView كشاشة تحميل وتفريغها عندما تكون البيانات جاهزة.

@ adrianknight89 سيكون رائعًا إذا تعامل CollectionView مع "null it out" بمجرد أن تصبح البيانات جاهزة بدلاً من التحكم في هذا يدويًا (ما لم تكن تشير إلى ذلك بالفعل).

عند التمرير بسرعة عبر صفحة تستخدم RemainingItemsThreshold في CollectionView ، فإننا نواجه مشكلتين مختلفتين.

1. يتجمد التطبيق ويجب إنهاء العمل بالقوة
2. العناصر الموجودة في CollectionView مكدسة فوق بعضها البعض (انظر الصورة )

لم أتمكن من العثور على أي شخص آخر لديه هذه المشكلة. هل رأيت أنه أبلغ؟

@ Bronson15 كيف تتعامل مع حدث RemainingItemsThresholdReached ؟ سيؤدي التمرير السريع إلى تشغيله عدة مرات ، ولذا تحتاج إلى تجاهل مكالمات الأحداث أثناء انتظار تحديث مصدر البيانات وإلا فسوف تتراكم. حاول أيضًا تحديث واجهة المستخدم الخاصة بك في السلسلة الرئيسية.

إذا كنت لا تزال تواجه مشكلة ، فيمكنك فتح مشكلة جديدة مع repro للتحقيق.

@ Bronson15 كلا القضيتين.
حاولت باستخدام ObservableRangeCollection وتم إصلاحها # 2.
لا تزال تواجه مشكلات في التجميد / القائمة الفارغة: عند التشغيل على المحاكي أرى ارتفاع وحدة المعالجة المركزية ، يبدو وكأنه حلقة لا نهائية.

تحرير: فواصل فقط على iOS ، على Android يعمل بشكل جيد.

أهلا بالفريق،
حتى أنني حاولت استخدام RemainingItemsThreshold و RemainingItemsThresholdReachedCommand ولاحظت أنه يتم استدعاء الوظيفة المعينة لـ RemainingItemsThresholdReachedCommand عدة مرات متتالية (في المرة الأولى التي يتم استدعاؤها مرتين ، في المرة القادمة 4 مرات وما إلى ذلك) حتى إذا لم أقوم بالتمرير بسرعة. أنا أيضًا قادر على إعادة إنتاجه باستخدام مشروع Xamarin Forms الجديد (الإصدار 4.2.0.778463).
هل يمكنك محاولة إعادة إنتاجه في نهايتك؟ إليك مقتطف الشفرة البسيط أدناه:

XAML:

<CollectionView
        x:Name="StackLayout"
        ItemsSource="{Binding LatestStories}"
        RemainingItemsThreshold="10"
        RemainingItemsThresholdReachedCommand="{Binding RemainingStoriesCommand}">
        <CollectionView.ItemTemplate>
            <DataTemplate>
            <Grid
                                ColumnSpacing="16"
                                HeightRequest="110"
                                RowSpacing="0">

                    <Grid.RowDefinitions>
                        <RowDefinition Height="*" />
                        <RowDefinition Height="Auto" />
                        <RowDefinition Height="Auto" />
                    </Grid.RowDefinitions>
                    <Grid.ColumnDefinitions>
                        <ColumnDefinition Width="Auto" />
                        <ColumnDefinition Width="*">
                        </ColumnDefinition>
                        <ColumnDefinition Width="Auto" />
                    </Grid.ColumnDefinitions>

                    <!--  Blog title  -->
                    <Label
                                    Grid.Column="1"
                                    Margin="0,8"
                                    FontSize="14"
                                    LineBreakMode="TailTruncation"
                                    LineHeight="{OnPlatform Default=-1,
                                                            Android=1.25,
                                                            iOS=1.25}"
                                    MaxLines="2"
                                    Text="{Binding Title}" />

                    <!--  Author name  -->
                    <Label
                                    Grid.Row="1"
                                    Grid.Column="1"
                                    Margin="0,8,0,0"
                                    FontSize="12"
                                    LineHeight="{OnPlatform Default=-1,
                                                            Android=1.5}"
                                    Text="{Binding Author}" />

                </Grid>
            </DataTemplate>
        </CollectionView.ItemTemplate>
</CollectionView>

عرض النموذج:

public class ArticleListViewModel
    {
        public ObservableRangeCollection<FeedItem> LatestStories { get; } = new ObservableRangeCollection<FeedItem>();
        public Command RemainingStoriesCommand => new Command(() => RemainingStories());

        public ArticleListViewModel()
        {
            RemainingStories();
        }

        private async void RemainingStories()
        {
            var feeds = await GetRemoteFeedsAsync();
            try
            {
                Device.BeginInvokeOnMainThread(() =>
                {
                    LatestStories.AddRange(feeds);
                });

            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex, "");
            }
        }

        private async Task<List<FeedItem>> GetRemoteFeedsAsync()
        {
            try
            {
                Stopwatch watch = new Stopwatch();
                watch.Start();
                var allItems = new List<FeedItem>();
                HttpResponseMessage response;
                var httpClient = new HttpClient();
                response = await httpClient.GetAsync("https://jsonplaceholder.typicode.com/photos").ConfigureAwait(false);
                if (response.IsSuccessStatusCode)
                {
                    var data = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
                    var testData = JsonConvert.DeserializeObject<List<TestJson>>(data);
                    if (LatestStories.Count == 0)
                    {
                        testData = testData.Take(20).ToList();
                    }
                    else
                    {
                        testData = testData.Skip(LatestStories.Count).Take(20).ToList();
                    }

                    foreach (var item in testData)
                    {
                        var newItem = new FeedItem
                        {
                            Title = item.id.ToString(),
                            Description = item.title,
                            ImagePath = item.thumbnailUrl,
                            Link = item.url,
                            PublishDate = "2019-09-11",
                            Category = ""
                        };
                        allItems.Add(newItem);
                    }
                }
                watch.Stop();
                Debug.WriteLine("TPL Total Time: " + watch.ElapsedMilliseconds);
                return allItems;
            }
            catch (Exception ex)
            {
                Debug.WriteLine(ex, "");
                throw;
            }

        }
    }

@ Bronson15andreabalduccitechduggu وبما أننا لا تحجب UI بينما RemainingItemsThresholdReachedCommand يتم معالجة، فمن الطبيعي أن الحفاظ على ضرب الأمر عدة مرات بسبب أنماط التمرير الخاص بك. يرجى الاطلاع على كيفية التعامل مع المشكلة باستخدام آلية القفل: https://github.com/xamarin/Xamarin.Forms/pull/7516/files#diff -2be3eff4d53f761cd581cca1d2ec3bc0R48

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

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

techduggu توجد

@ adrianknight89 نشكرك على إبراز مصطلح "بسبب أنماط التمرير الخاصة بك". أثار هذا حكة في العثور على المزيد حول هذا الموضوع. بعد الاطلاع على الوثائق الرسمية لـ RecyclerView وبعض الموارد الأخرى ، نعم ، يمكنني أن أؤكد أنه يتم استدعاؤها عدة مرات بسبب أنماط التمرير وأن هذه الأنماط هي SCROLL_STATE_IDLE أو SCROLL_STATE_DRAGGING أو SCROLL_STATE_SETTLING اعتمادًا على حالة التمرير لدينا.
https://developer.android.com/reference/android/support/v7/widget/RecyclerView.OnScrollListener

يؤكد الرمز الخاص بك ودليل android هذا (https://github.com/codepath/android_guides/wiki/Endless-Scrolling-with-AdapterViews-and-RecyclerView) أيضًا على نفس الشيء الذي يجب أن نتعامل معه مع التمرير اللانهائي إما عن طريق القفل أو الاستخدام من حالات التمرير أعلاه (والتي تتطلب في الغالب عارض مخصص). ومن ثم مع Xamarin.Forms ، جربت الكود الخاص بك وعمل مثل السحر. :) أوصي وأدعم رأيك لتضمين هذا الاقتراح كجزء من المستندات لتجنب مثل هذه المشكلات التي يثيرها أشخاص (نصف معرفة) مثلي. :)

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

شكرا!

@ adrianknight89 آه نعم. كان فحصنا مشغولاً مفقودًا وقد ساعد ذلك في حل مشكلة التراص.

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

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

تحرير: إعادة تعيين موضع التمرير لا يزال موجودًا ، ولكن ليس كثيرًا. عرض تحميل المزيد من العناصر متقطع جدًا على الجهاز أيضًا.

techduggu ليس لدي VS معي ، ولكن بمجرد النظر إلى الكود ، يجب أن تنتظر RemainingStories() ، انقل المكالمة عن بُعد داخل المحاولة ، واستخدم استخدام HttpClient (استخدام مثالي مثيل واحد ثابت عبر التطبيق الخاص بك ولا تتخلص منه أبدًا) ، لكنني سأتوقف هنا. :)

@ Bronson15 حدثت مشكلة في CollectionView

@ adrianknight89 التمرير خلال البناء الليلي. يبدو أن المشكلة قد تم إصلاحها في الغالب (لقد رأيت أنها تحدث مرة واحدة). يبدو أن القائمة في حلقة لا نهاية لها الآن على الرغم من أن لها نهاية. AFAIK ليس هناك خاصية في المواصفات لمنع ذلك من الحدوث؟

@ Bronson15 حلقة لا نهاية لها لا ينبغي أن يحدث. هل تراه على iOS أو Android؟ تحتاج إلى إنهاء الحلقة عندما تصل إلى نهاية التغذية البعيدة (أي العودة من RemainingItemsThresholdReachedCommand الفور دون إصدار مكالمة DB أخرى).

بمجرد توقف عرض التمرير ، يجب ألا يتم تشغيل الأمر مرة أخرى. أستخدم Azure Cosmos الذي يُرجع رمز استمرار. عندما يكون الرمز المميز فارغًا ، أعلم أنه لا يوجد المزيد من المحتوى للتحميل ، لذلك يعمل RemainingItemsThresholdReachedCommand بناءً على هذا الرمز المميز. يجب عليك تنفيذ شيء مشابه.

تضمين التغريدة مثير للاهتمام. تمت إضافة فحص لعدد النتائج والعودة إذا كانت 0. تم إصلاح التمرير اللانهائي. شكرا للمساعدة!

@ adrianknight89 تم اختباره قريبًا لمشكلة تعطل iOS ، وهو يعمل أخيرًا. لا يزال أبطأ "كثيرًا" من Android.
مع وجود 1000 عنصر على Android في الوقت الفعلي تقريبًا ، يتعين على iOS الانتظار من 5 إلى 7 ثوانٍ حتى يتم عرض العرض. كلا التصحيح ، iPhone Xs و Redmi Note 7

andreabalducci هل أنت من

@ adrianknight89andreabalducci نعم فإنه يأخذ حوالي 1-5 ثواني على بلدي إكسس ماكس لتحميل المزيد من العناصر. يُفرغ العرض ويعيد تحميل جميع العناصر بدلاً من إضافة عناصر إلى القائمة المعروضة بالفعل.

@ adrianknight89 كلا الجهازين الماديين ، ومحاكي iOS له نفس المشكلات.

لقد أزلنا جميع عمليات التكديس من قوالب البيانات واكتسبنا بعض تبديل السرعة إلى FormattedString ، وتمكين الارتباطات المجمعة ، قبل أن يتجاوز نظام iOS 20 ثانية.

على نظام التشغيل iOS ، يتم عرض اللون الأسود وإعادة رسم الكل عند الإضافة إلى ObservableRangeCollection (من مساعدي mvvm) ، على Android يعمل بشكل جيد.

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

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

أي معلومات عن هذا؟

LynoDesu يتم تتبع مشكلة لهذا: https://github.com/xamarin/Xamarin.Forms/issues/6357

LynoDesu يتم تعقب مشكلة لهذا: # 6357

آه عظيم! شكرا. من أين أبدأ إذا كنت أرغب في المساهمة في ذلك؟

اقرأ ويكي الصفحة الرئيسية وكذلك Contributing.md .

@ adrianknight89 عثر على فارغ + رجوع لبدء المشكلة ، أعده هنا https://github.com/andreabalducci/XamarinCollectionView/blob/b186e563ff8391dfb473e62e5a4c4587e8d4e9da/cvrepro/cvrepro/ListViewModel.cs#

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

تم اختباره على محاكي iPhone.

أرى القضية. من المحتمل أن يكون هذا هو نفس الرقم # 7548. قد ترغب في نشر التأنيب الخاص بك هناك.

يبدو أن CollectionView قد تم التنصت عليها على Android عند استخدام IsGrouped.

CollectionView.GroupHeaderTemplate إطلاقًا. على iOS يعمل بشكل جيد. يمكنك فقط استخدام مثال التجميع من موقع Microsoft لاختباره.

    public class AnimalGroup : List<Animal>
    {
        public string Name { get; private set; }

        public AnimalGroup(string name, List<Animal> animals) : base(animals)
        {
            Name = name;
        }
    }

    public class Animal
    {
        public string Name { get; set; }
        public string Location { get; set; }
        public string Details { get; set; }
        public string ImageUrl { get; set; }
    }

    public List<AnimalGroup> Animals { get; private set; } = new List<AnimalGroup>();

    Animals.Add(new AnimalGroup("Bears", new List<Animal>
        {
            new Animal
            {
                Name = "American Black Bear",
                Location = "North America",
                Details = "Details about the bear go here.",
                ImageUrl = "https://upload.wikimedia.org/wikipedia/commons/0/08/01_Schwarzbär.jpg"
            },
            new Animal
            {
                Name = "Asian Black Bear",
                Location = "Asia",
                Details = "Details about the bear go here.",
                ImageUrl = "https://upload.wikimedia.org/wikipedia/commons/thumb/b/b7/Ursus_thibetanus_3_%28Wroclaw_zoo%29.JPG/180px-Ursus_thibetanus_3_%28Wroclaw_zoo%29.JPG"
            },
        }));

<CollectionView ItemsSource="{Binding Animals}"
                        IsGrouped="true">
            <CollectionView.GroupHeaderTemplate>
                <DataTemplate>
                    <Label Text="Header"
                           BackgroundColor="LightGray"
                           FontSize="Large"
                           FontAttributes="Bold" />
                </DataTemplate>
            </CollectionView.GroupHeaderTemplate>
            <CollectionView.ItemTemplate>
                <DataTemplate>
                    <Grid Padding="10">
                        <Image Grid.RowSpan="2"
                               Source="{Binding ImageUrl}"
                               Aspect="AspectFill"
                               HeightRequest="60"
                               WidthRequest="60" />
                        <Label Grid.Column="1"
                               Text="{Binding Name}"
                               FontAttributes="Bold" />
                        <Label Grid.Row="1"
                               Grid.Column="1"
                               Text="Child"
                               FontAttributes="Italic"
                               VerticalOptions="End" />
                    </Grid>
                </DataTemplate>
            </CollectionView.ItemTemplate>
        </CollectionView>

https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/collectionview/grouping

الأهمية

تجميع البيانات مع CollectionView مدعوم حاليًا على iOS فقط.

عذرًا ، فاتني هذا الجزء. شكرا.

بالنسبة لأولئك منا الذين يرغبون في عرض قائمة مجمعة على كل من iOS و Android ، ولكنهم يريدون تجنب ListView ، هل هناك أي شيء آخر يمكننا استخدامه بمرونة مثل CollectionView في الوقت الحالي؟ أم أننا عالقون مع ListView؟

آمل أن يكون هذا هو المكان المناسب لأسأل. أرى في المواصفات الأصلية المنشورة أن هناك خصائص لـ IsHeaderSticky و IsFooterSticky ، لكني لا أرى أي ذكر لها في أي مكان في المناقشة أو في الكود المصدري المنفذ. هل ما زال هؤلاء على خارطة الطريق لوجهة النظر هذه؟

في collectionview ، نحتاج إلى ItemAppeared ، ITemDisappeared.
هل هناك اي طريقه لتحقيق؟

IosDeveloperHarsh يوفر الحدث Scrolled الكثير من المعلومات المفيدة في مواقع الحدث. انظر إلى فهارس العناصر المرئية الأولى والأخيرة هناك.

تعمل عينات معرض

@ cabal95 لست مؤهلاً للإجابة على هذا السؤال ، لكن إذا كان عليّ التخمين فسيتم تنفيذها في النهاية. ربما نحتاج إلى وجود مشكلة نشطة لتتبع ذلك. أعلم أن عمل الرأس / التذييل الأولي استبعد الأشياء اللاصقة.

أعتقد أنه يجب إزالة SelectionChangedCommandParameter وبدلاً من ذلك سنقوم بتعيين العنصر المحدد تلقائيًا كمعامل.

إذا كان من الممكن أن يكون من الجيد استخدام الممتلكات مثل هذا

public ICommand => new Command<MySelectedItemModel>((item) => {}

ولكن يجب أن يكون هذا جيدًا أيضًا:

public ICommand => new Command<object>((item) =>{ var selectedItem = item as MySelectedItemModel;}

أعتقد أنه يجب إزالة SelectionChangedCommandParameter وبدلاً من ذلك سنقوم بتعيين العنصر المحدد تلقائيًا كمعامل.

إذا كان من الممكن أن يكون من الجيد استخدام الممتلكات مثل هذا

public ICommand => new Command<MySelectedItemModel>((item) => {}

ولكن يجب أن يكون هذا جيدًا أيضًا:

public ICommand => new Command<object>((item) =>{ var selectedItem = item as MySelectedItemModel;}

ماذا لو أراد المستخدم استخدام شيء آخر غير SelectedItem كمعامل لأمره؟

أعتقد أنه يجب إزالة SelectionChangedCommandParameter وبدلاً من ذلك سنقوم بتعيين العنصر المحدد تلقائيًا كمعامل.
إذا كان من الممكن أن يكون من الجيد استخدام الممتلكات مثل هذا
public ICommand => new Command<MySelectedItemModel>((item) => {}
ولكن يجب أن يكون هذا جيدًا أيضًا:
public ICommand => new Command<object>((item) =>{ var selectedItem = item as MySelectedItemModel;}

ماذا لو أراد المستخدم استخدام شيء آخر غير SelectedItem كمعامل لأمره؟

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

أرغب أيضًا في طلب ميزة لا يمتد عرض CollectionView هذا على الشاشة بأكملها ويستخدم الارتفاع فقط يعتمد على عدد العنصر.

أحاول الحصول على قوائم متعددة في العرض
بمعنى آخر
المشتريات

الخصومات

مجموع
مجموع
توت

لكن العناصر 1 و 2 (عرض CollectionView) أخذت ارتفاعًا كبيرًا للغاية حتى لو كان لدي 3 أو 4 عناصر فقط وهناك فجوة BIIIIIIIIIIIIIG أدناه قبل أن أتمكن من رؤية قسم الخصومات

انتهى بي الأمر بإنشاء عنصر التحكم في مجموعة ItemsCollection الخاص بي بناءً على StackLayout

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

أعتقد أن ما تبحث عنه قد يكون تخطيطات قابلة

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

أعتقد أن ما تبحث عنه قد يكون تخطيطات قابلة

مهلا! بالضبط ما أحتاجه. منذ متى BindableLayouts موجودة؟

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