أعتقد أنه من المفيد لأفراد المجتمع أن يقوم فريق Xamarin.Forms بتدوين المزيد من المستندات حول Xamarin. بنية النماذج ومبدأ التصميم وسير العمل في مستندات Github أو MS.
من وجهة نظري ، أستخدم Xamarin. نماذج لإنشاء منتجاتي ، سيكون لدي خياران عندما أقابل الأخطاء ، أحدهما إرسال المشكلة إلى github وانتظار إصلاحها يومًا ما والآخر إرسال المشكلة إلى github و أصلحته بنفسي.
بعد استنساخ الكود المصدري وتصحيحه ، من الصعب فهم كيفية عمل الميزات. على سبيل المثال https://github.com/xamarin/Xamarin.Forms/issues/8521
مثال آخر هو ميزة التنقل في صفحة Xamarin.Forms على جانب android. من السهل فهم ميزة التنقل بين الأنشطة على Native Android. ولكن في Xamarin.Forms ، يبدو أنه يستخدم نشاطًا رئيسيًا واحدًا للتعامل مع كل الصفحات (ربما) (باستثناء النماذج الأصلية والعرض الأصلي).

اظنها عظيمه.

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

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

هناك شيء آخر أفكر فيه وهو استخدام مساحات الشفرات وفي مساحات github-codespaces المستقبلية ، حيث يمكن للمرء إرفاق ملفات نقطية لمشكلة (بما في ذلك إصدار xamarin الصحيح وما إلى ذلك) ومن ثم يمكننا فقط استخدام مساحات التشفير أو الخروج من هذا الإصدار.

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

أعتقد أن ما أحاول قوله هو:

• معرض متعدد الأجزاء
• دعم codespaces
• dotfiles قيد الإصدار

تحرير: أضيفت النقطة الثالثة.

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

وكلما زاد هذا الأمر كان ذلك أفضل.

1. قم بإزالة الخيوط السحرية والارتباطات غير المصنفة من القلب. لا تطلب من أي شخص يساهم في الريبو كتابة ربط غير مطبوع أو سلسلة غير محددة النوع. سيؤدي ذلك إلى تقليل الأخطاء بشكل كبير ، وجعل إصلاح الأخطاء أسهل كثيرًا ، وتسهيل إعادة البناء حتى لا تظهر أخطاء جديدة.
2. لا تطلب من المساهمين التعامل مع أي طبقة ترميز. سيرغب بعض المطورين في استخدام XAML أو CSS ولكن لا ينبغي أن يحتاج المساهمون في إصلاح الأخطاء إلى الاهتمام بهذه الأشياء. فقط الأشخاص الذين يعملون على لغات الترميز ، والتي يجب أن تكون طبقة فوق فئات .NET الحقيقية ، هم الذين يجب أن يهتموا بهذه الطبقة.
3. يجب أن يتم بناء نهج العارض بطريقة تجعل الفشل في تنفيذ تغيير خاصية (أو خطأ في النوع في القيام بذلك على النحو الوارد أعلاه) خطأ في النوع.
4. حيثما كان ذلك مناسبًا ، يجب أن يكون هناك تسامح لتنفيذ بعض الميزات بدون ارتباطات خاصة بالمنصة على الإطلاق ، على سبيل المثال استخدام SkiaSharp أو الأشكال أو كائنات MAUI المركبة ، لتطبيقات موثوقة عبر الأنظمة الأساسية تعرض نفس الشيء ولا تقدم أخطاء جديدة.

في مرحلة ما كنا نختبر اتجاهًا لوجود مستخدمي SLN مبسط يمكنهم المساهمة في مثل هذا

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

ما عليك سوى توفير "Contributor.sln" شديد الاستهداف حيث يمكن للمساهمين عرض إصلاح أو واجهة برمجة تطبيقات

قم بإزالة جميع المعارض الحالية وركز فقط على الأنظمة الأساسية والصفحة الرئيسية

هل سيكون مرشح الحل أفضل؟ ليس عليك الحفاظ على حلين.

سنرى كل ما يتم تطويره باستخدام عوامل تصفية الحلول

AFAIK حاليًا لا يعملون على vsmac وهم غريبون بعض الشيء عندما يكون لديك مشاريع متعددة الأهداف. بمجرد أن نتمكن من الحصول على دعم من الدرجة الأولى للاستهداف المتعدد ويمكن أن تكون المشاريع الرئيسية بأسلوب sdk ، فأنا أعتقد أن الحاجة إلى مرشحات الحلول ليست عالية.

الشيء المزعج الآخر هو أن VS for Windows يبني حاليًا جميع الأهداف عندما يكون لديك استهداف متعدد ، بينما يبني vsmac الهدف لرئيس النظام الأساسي الذي تقوم بتشغيله.

الشيء المزعج الآخر هو أن VS for Windows يبني حاليًا جميع الأهداف عندما يكون لديك استهداف متعدد ، بينما يبني vsmac الهدف لرئيس النظام الأساسي الذي تقوم بتشغيله.

الحصول على دعم لذلك في VS for Windows سيكون رائعًا! يمكنني التخلص من كل هذه التكوينات الإضافية التي قمت بها لبناء النظام الأساسي الذي أعمل معه في الوقت الحالي.

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