استغرق 7049 أكثر من شهر واحد للنشر حتى عندما يتم دمج العلاقات العامة بعد 7 أيام من تقرير الخطأ

وفتح طلب السحب لا يزال يؤدي إلى تعليق الطلب في طي النسيان إلى أن يوفر مسؤول من Xamarin الوقت لإلقاء نظرة على الملفات التي تم تغييرها.

نأمل أن يكون لدى الفريق خطة لإزالة بعض الاختناقات حول عملية إطلاق العلاقات العامة +.

وفتح طلب السحب لا يزال يؤدي إلى تعليق الطلب في طي النسيان إلى أن يوفر مسؤول من Xamarin الوقت لإلقاء نظرة على الملفات التي تم تغييرها.

وانظر إلى ذلك ، بعد ذكره في قضية عالية الوضوح ، قام شخص ما في فريق Xamarin.Forms بالرد أخيرًا على https://github.com/xamarin/Xamarin.Forms/pull/7728.

وفتح طلب السحب لا يزال يؤدي إلى تعليق الطلب في طي النسيان إلى أن يوفر مسؤول من Xamarin الوقت لإلقاء نظرة على الملفات التي تم تغييرها.

وانظر إلى ذلك ، بعد أن تم ذكره في قضية عالية الوضوح ، قام شخص ما في Xamarin.Forms بالرد أخيرًا على xamarin / Xamarin.Forms # 7728 .

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

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

أرى بضع نقاط ذات صلة

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

2) سيكون من المفيد حقًا أن تبدأ Microsoft في استخدام النماذج بالفعل على تطبيقاتها الخاصة. وأنا لا أقصد تطبيقات تجريبية أو مؤتمرات بسيطة. أعني تطبيقات حقيقية مثل Teams أو Outlook. سأكون سعيدًا إذا كنت مخطئًا في هذا ولكن لم أتمكن من العثور على أي تطبيق MS Forms في المتاجر ووفقًا لبعض المصادر مثل هذه التغريدة https://twitter.com/safaiyeh/status/1219294459298344961 يستخدمون رد الفعل في الغالب محلي.

• هذا في الواقع لا يرسل إشارة جيدة لأنه إذا لم تستخدم MS التكنولوجيا الخاصة بها (XF) فلماذا يجب علينا ذلك؟

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

3) أرى مشكلة أخرى في حقيقة أن MS constatly تحاول إعادة اختراع العجلة في شكل XF Xaml بدلاً من استخدام الحلول المثبتة بالفعل والحالية مثل Win UI Xaml. يتعين عليهم استثمار الوقت في تطوير الميزات الموجودة بالفعل وإصلاح الأخطاء التي يتم تقديمها بسبب ذلك ، ومن ثم يكون هناك وقت أقل للميزات وإصلاحات الأخطاء الأخرى.

أوافق 100٪ معReveon
أوه ، ويجب أن أقول إن استخدام VisualStudio لنظام التشغيل Windows مع Xamarin هو تجربة محبطة للغاية.

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

لقد قمت بالتبديل إلى Rider لذلك وأنا الآن أستخدم منتج Jetbrains في كل مكان :) على الأقل يمكنني استخدام IDE الذي هو نفسه تمامًا في iOS و Windows ومواصلة العمل بشكل منتج.

أنا متأكد من أنه مع MAUI ستتغير مثل هذه الأشياء ، وستبدأ Microsoft عاجلاً أم آجلاً في استخدام MAUI داخليًا للمشاريع الجادة

شهادة أخرى:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
EmilAlipiev :

لقد كنت أنتظر دمج العلاقات العامة الخاصة بي لمدة 1.5 شهر لهذه المشكلة. هناك بالفعل مشكلة حالية لـ Ios و android تم إصلاحها في يوليو 2019 ولم يتطرق أحد إلى uwp. لقد أصلحت في أبريل وطلبت عدة مرات للمراجعة والدمج. إنه أمر مزعج حقًا كيف تعمل فرق xamarin. يمكنك أن ترى أنهم يراجعون فقط 1-2 من العلاقات العامة في اليوم.
# 10316

على الرغم من أنني غالبًا ما أشعر بالإحباط ، إلا أن عبارة "Xamarin هي عربات التي تجرها الدواب" عبارة قاسية. أكثر من 2000 إصدار مفتوح اليوم ، إذا قمت بفحص flutter بها أكثر من 5000 مشكلة مفتوحة. الأرقام ليست مهمة جدا. يوفر Xamarin.forms أكثر من الأنظمة الأساسية الأخرى مثل uwp (بما في ذلك xbox) و wpf و mac و gtk و tizen. لذلك هناك العديد من المشكلات المفتوحة لـ Wpf على سبيل المثال والتي تعتبر ذات أولوية أقل بالنسبة لمعظمنا.
يجب أن يكون Core of Xamarin.forms هو ios و android و uwp على الرغم من أن فريق Xamarin غالبًا ما يهمل uwp.

1. يجب أن تكون هناك عناصر أساسية مثل التخطيطات ، وعروض القوائم ، والعرض الدائري ، وعرض المجموعة ، والصور ، والخرائط ، والملصقات ، والمحرر ، إلخ. يجب أن تكون هذه العناصر خالية من الأخطاء. إذا قمت بإجراء إصدار جديد أو تحديث لهؤلاء ، فيجب عليك التأكد من عدم وجود خطأ في showstopper. إذا كان هناك خطأ ، فيجب عليك حله في غضون أسبوع كحد أقصى. لكن فريق Xamarin يطلق هذا الإصدار الرائع "4.5-4.6" بميزات رائعة (من الذي يحتاج إلى هذه الأداة الفاخرة بنسبة 10٪ من المجتمع؟) وتحطم الصورة. تم الإبلاغ عن المشكلة في بداية مارس ولم يتم حلها حتى اليوم. تم كسر نفس "التجميع في التجميعات الأصلية". لهذه الأسباب الحاسمة ، لا يمكنني الترقية إلى 4.5 و 4.6. استمروا في التطوير مع 4.7 إضافة ميزات جديدة. أنا ومعظمنا نراقب ملاحظات الإصدار حول ما إذا كان قد تم حل الأخطاء لدينا أم لا ، حتى أنني لم أعد أقرأ الميزة التي تمت إضافتها.
2. فريق Xamarin يجب أن يفهم هذا. أكبر سبب لاختيار العديد من الناس Xamarin هو "UWP". أنا بالقطعة. أسأل عميلي لماذا لا يرفرف أو يتفاعل مع السكان الأصليين؟ يقول لأن Xamarin لديه UWP. أريد UWP أيضا. لكن Uwp في الغالب عبارة عن عربات التي تجرها الدواب مع Xamarin.forms. لقد قدموا CollectionView ، إنه رائع حقًا ولكن منذ عام لم يتم حل هذا الخطأ. أصلحته ، لا أحد يراجع. كنت لا تشجع على القيام بأي مساهمة أخرى.
3. Hotreload لا يعمل على الإطلاق. قرأت على تويتر جميع "قبلة قبلة" ما مدى روعة hotreaload. أعتقد أنه يجب أن يكون هناك شيء خاطئ معي أو أنهم يستخدمون بعض الأدوات الأخرى. لأنه في كثير من الأحيان لا يتم تحديث hotreload. ما زلت أستخدم أدوات الطرف الثالث مثل livexaml وما إلى ذلك ، حتى أنني أنشأت تطبيق وحدة تحكم بسيطًا للقيام بالتحميل السريع الخاص بي. يكلفني يوم واحد. يعمل بشكل أفضل بكثير من Xamarin ويعمل حتى مع uwp. كيف لا يمكنهم تسليمها؟ كان لديهم الكبد كان يعمل.

4. أهم نقطة ما ذكره Reveon . يحتاجون إلى تطبيق مؤسسة حقيقي يعمل مع xamarin.forms ويجب عليهم تحديثه بإصدارات جديدة لاكتشاف المشكلات الحقيقية. إنهم يشتكون من أنه "ليس من الصعب إعطاء التأنيب". نعم ، من الصعب جدًا أن تحدث هذه المشكلة على تطبيق مؤسستك فقط ، وليس على تطبيق todo. تحتاج إلى محاولة تكرار نفس واجهة المستخدم. قد يكلفك أيام حتى تعرف. لهذا السبب من المهم جدًا أن يكون هناك شخص لديه تطبيق كبير. أتساءل حقًا عما إذا كان أي من مطوري Xamarin الذين نراهم على twitch و youtube و twitter وغيرها قد طوروا تطبيقًا كبيرًا باستخدام xamarin.forms.

5. يجب أن أعترف بشيء ما على الرغم من أنني لا أرغب في استخدام أدوات غير مفتوحة المصدر ، فإن أكثر من 50٪ من تطبيقاتي مزودة بأدوات syncfusion. بدون Syncfusion ، أعتقد أنه من الصعب جدًا الحصول على تطبيق يعمل على مستوى المؤسسة. لديهم كل شيء ما لا xamarin أو ما هو xamarin عربات التي تجرها الدواب. على سبيل المثال ، لقد بحثت عن بديل sfListView لسنوات بعد السحب والإفلات وعرض التمرير السريع والتخطيط الخطي والشبكي وأفضل المحاكاة الافتراضية وما إلى ذلك. وأخيرًا ، ظهر xamarin مع CollectionView وألقوا به على وجهنا باعتباره "إصدارًا رائعًا" من Listview ولكن بعد ذلك انها عربات التي تجرها الدواب. لا تعمل في Uwp. العديد من الميزات المفقودة. ما عليك سوى البحث عن CollectionView ضمن المشكلات ، وسوف ينتهي بك الأمر بالعشرات منها.

ما زلت أعتقد أن Xamarin هي أفضل أداة لمنصة مشتركة وآمل أن يأخذوا هذه المشكلة على أنها تعليقات بناءة.

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

لأنني ذكرت ...

أقود مشروعًا صغيرًا لتطبيق متعدد الأنظمة الأساسية بين Android و Windows Desktop (WPF).

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

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

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

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

أرى بضع نقاط ذات صلة

1. لا أعرف عدد الأشخاص الذين يعملون في النماذج ولكن بالنسبة لي يبدو أن الفريق صغير جدًا لمواكبة وتيرة النمو السريع للأخطاء الجديدة أو العلاقات العامة. سيزداد هذا الأمر سوءًا حيث سيتعين عليهم تقسيم الانتباه بين النماذج وماوي. آمل حقًا أن يحصل الفريق على دعم كبير قريبًا.
2. سيكون من المفيد حقًا إذا بدأت Microsoft في استخدام النماذج بالفعل على تطبيقاتها الخاصة. وأنا لا أقصد تطبيقات تجريبية أو مؤتمرات بسيطة. أعني تطبيقات حقيقية مثل Teams أو Outlook. سأكون سعيدًا إذا كنت مخطئًا في هذا ولكن لم أتمكن من العثور على أي تطبيق MS Forms في المتاجر ووفقًا لبعض المصادر مثل هذه التغريدة https://twitter.com/safaiyeh/status/1219294459298344961 يستخدمون رد الفعل في الغالب محلي.

• هذا في الواقع لا يرسل إشارة جيدة لأنه إذا لم تستخدم MS التكنولوجيا الخاصة بها (XF) فلماذا يجب علينا ذلك؟
• يمكن أن يكون استخدام النماذج داخليًا على التطبيقات المعقدة وطبقة إضافية من الاختبار ويمكن أن يقلل من عدد المشكلات التي وصلت إلى الإصدار العام. بالإضافة إلى أنهم قد يرون أن العمل باستخدام النماذج ليس بالسهولة التي يخبروننا بها

1. أرى مشكلة أخرى في حقيقة أن MS constatly تحاول إعادة اختراع العجلة في شكل XF Xaml بدلاً من استخدام الحلول المثبتة بالفعل والحالية مثل Win UI Xaml. يتعين عليهم استثمار الوقت في تطوير الميزات الموجودة بالفعل وإصلاح الأخطاء التي يتم تقديمها بسبب ذلك ، ومن ثم يكون هناك وقت أقل للميزات وإصلاحات الأخطاء الأخرى.

أنا أتفق مع العديد من القضايا التي ذكرتها. تحتاج Microsoft بالتأكيد إلى إنشاء تطبيق مؤسسي باستخدام Xamarin Forms أو iOS أو Android. بمجرد أن يكون لديهم مثال على تطبيق مؤسسة عاملة ، فلا يمكننا الشكوى من أن إنشاء تطبيقات احترافية أمر محبط.

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

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

أجد أن Visual Studio عربات التي تجرها الدواب بشكل لا يصدق عند تطوير تطبيقات Xamarin. على سبيل المثال ، إذا تم تحديد مشروع Android الخاص بي كمشروع بدء التشغيل ، واختبره به ، ثم قم بالتبديل إلى مشروع iOS الخاص بي كمشروع بدء التشغيل الخاص بي ، فسوف يعرض جميع أنواع الأخطاء الخاطئة. لا يساعد إتلاف الحاوية أو مجلدات الكائنات. يتطلب مني إعادة تشغيل VS. في مثال آخر ، سيفقد VS بشكل عشوائي اتصاله بجهاز Mac الخاص بي أثناء تصحيح أخطاء تطبيقي. سيؤدي ذلك إلى تجميد VS الخاص بي. سألقي بنوبة غضب ، وسأشكك في هوايتي وحياتي كمطور للهواتف المحمولة ، وأقوم بقتل VS باستخدام مدير المهام. علاوة على ذلك ، أجد أن الإصدارات المستقبلية من Visual Studio تعيد تقديم الأخطاء التي تم إصلاحها في الإصدارات السابقة. لا أعرف بأي طريقة حول كيفية تثبيت إصدار سابق من VS بعد إصدار أحدث إصدار وأقوم بتثبيته. يمكنني إلغاء تثبيته ومحاولة إعادة تثبيته باستخدام المثبت ، لكنه سيثبت دائمًا أحدث إصدار. إنها ليست مثل حزمة NuGet حيث يمكنك تثبيت أي إصدار.

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

أنا متوتر من اعتماد استخدام MAUI عندما يظهر في أي تطبيق احترافي أقوم بتطويره حتى يتم حل العديد من إحباطات المطورين هذه باستخدام Xamarin و Visual Studio. سوف ألعب وأجرّبها عندما تخرج. لكنني سأكتسب المزيد من الثقة إذا خرجت Microsoft وصنعت تطبيقًا مؤسسيًا باستخدام MAUI بدلاً من إنشاء تطبيقات تجريبية بسيطة.

هل يمكن لأي شخص أن يطلعنا على نماذج Xamarin وخرائط طريق MAUI؟ هل سيتم الحفاظ عليها بالتوازي؟ هل هناك توقف صارم لدعم Xamarin Forms وهل ستدفع Microsoft MAUI أسفل حناجرنا في تحديث Visual Studio مستقبلي؟

شكرا لك

SunnyMukherjee من التعليمات ،

ما هو مستقبل أشكال Xamarin؟

سيستمر الإصدار الرئيسي التالي من Xamarin.Forms في حوالي سبتمبر 2020 وسيستمر تحديثه من خلال إصدار .NET MAUI مع .NET 6. بعد ذلك ، ستستمر Xamarin.Forms في تلقي الخدمة ذات الأولوية لمدة 12 شهرًا.

بشكل أساسي ، Xamarin.Forms سيتم قتلها بعد الإصدار 5.

SunnyMukherjee من التعليمات ،

ما هو مستقبل أشكال Xamarin؟

سيستمر الإصدار الرئيسي التالي من Xamarin.Forms في حوالي سبتمبر 2020 وسيستمر تحديثه من خلال إصدار .NET MAUI مع .NET 6. بعد ذلك ، ستستمر Xamarin.Forms في تلقي الخدمة ذات الأولوية لمدة 12 شهرًا.

بشكل أساسي ، Xamarin.Forms سيتم قتلها بعد الإصدار 5.

بحلول منتصف عام 2021. . . إذا لم تقتلني Covid قبل ذلك ، فإن نماذج Maui أو Xamarin ستؤدي المهمة.

SunnyMukherjee أسمع ألمك. لقد تم استخدام Xamarin.Forms منذ ظهوره لأول مرة ، وقد ظهر منذ ذلك الحين. تذكر أن Microsoft لم تنشئ Xamarin.Forms ، لقد اشتروا Xamarin فقط في عام 2018. لذا فإن MAUI هو مشروع Microsoft لإعادة كتابته ليكون أفضل وجعله يعمل بسلاسة مع شبكة .net بأكملها. العمل مع Xamarin. الأشكال ليست تافهة لأن ما يجب أن تفعله ليس تافهاً. يقول الكثير من الناس أنهم يجب أن يفعلوا ما فعله Uno أو Flutter وأن يجعلوا عناصر التحكم بأنفسهم تمامًا - لكن هذا ضد ما هو Xamarin. إنه إطار تطوير أصلي - يعرض عناصر التحكم الأصلية بطريقة مشتركة. هذه ليست مهمة صغيرة. لقد واجهت أيضًا الكثير من المشكلات مع نماذج Xamarin ، ولكن بشكل عام ، فإن الوقت الذي تم توفيره باستخدامه بدلاً من كتابة نفس التطبيق بلغات متعددة يفوق المشكلات بكثير. بالإضافة إلى أن القدرة على مشاركة 90٪ من الكود مع المشاريع الأساسية ASP.Net الخلفية تجعل الأمر أكثر جدارة بالاهتمام.
في حين أنه من المهم السماح لـ Microsoft بمعرفة ما نريده في MAUI - لكن علينا أن نفهم أنها ليست مهمة صغيرة بالنسبة لهم ، ولدي أمل في أن يكون MAUI خطوة كبيرة في الاتجاه الصحيح.
شاهد هذا الفيديو من الإصدار الأخير من MAUI للعرض التوضيحي وشرح كيف يتناسب مع خرائط الطريق وأيضًا ما سيفعلونه ويدعمونه على Xamarin.
https://channel9.msdn.com/Events/Build/2020/BOD106؟ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

من خلال القراءة هنا ، أتساءل ما الذي يمكنني تعلمه هنا لتحسين جودة Xamarin. أود العودة إلى السؤال الأصلي لـ @ Happypig375 :

أي أفكار حول كيفية التحسين؟

أحد أهدافنا الرئيسية من الآن وحتى شحن .NET MAUI هو تحسين الأساس ونقطة البداية. لهذا السبب ، فإننا ننفق الكثير من سباقات السرعة الحالية لدينا على مشكلات CollectionView ، ونقترح إيقاف مطور الميزات مؤقتًا في Xamarin.Forms 5 لذلك لدينا من سبتمبر 2020 إلى نوفمبر 2021 لتحويل المزيد من التركيز إلى حل المشكلة.

كل هذا مرئي على لوحات مشروع العدو

باختصار:

• كن أسرع في طلب سحب المجتمع.

لقد أعدت إنشاء شجرة طلب السحب منذ أيام. لماذا تستغرق المراجعة وقتًا طويلاً؟

WPF-Renderer ، نقاط البق المحتملة:

• قياس / ترتيب الضوابط
• الشجرة المنطقية / المرئية مكسورة
• أداء

مرحبًا @ davidortinau ، أعتقد أن الطريقة الجيدة لمعالجة هذا الأمر تتمثل في تكريس شخص ما للمشاركة بشكل كامل في:

• فرز مشكلة الشوائب
• الإدارة والإرسال والدفع من أجل مراجعة العلاقات العامة والدمج.

سيكون هو / هي نقطة الاتصال الخاصة بنا إذا سارت الأمور ببطء شديد ويمكنه / يمكنها شرح ما يحدث.
علاوة على ذلك ، إذا كانت هناك عوائق غير قانونية ، فسيكون من الرائع أن يكون لدينا قناة Twitch حيث يقوم شخص ما بإصلاح خطأ أو مراجعة العلاقات العامة عبر الإنترنت. IHMO ، قد يكون لهذا تأثير هائل على اهتمام المطورين الخارجيين وتعاونهم.
هذا كلاهما صالح لنماذج .NET MAUI و Xamarin. لكن ربما أنا مجرد حالم 😄

لست مندهشًا حقًا أن Xamarin.Forms بها الكثير من الأخطاء نظرًا لعدد المنصات التي تعمل عليها والتغييرات من الأنظمة الأساسية أو من خلال تطويرها.

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

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

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

لتحسين الإطار. وأود أن أضيف:

تحسين إمكانية كتابة العارض الخاص بك. تجنب الكلمة الأساسية internal .

بدلاً من مجرد نشر مشاريع نموذجية على GitHub ، يمكن لـ Microsoft إنشاء تطبيق احترافي أو مؤسسي مثل OneDrive أو تطبيق Xbox باستخدام Xamarin Forms أو iOS أو Android ونشره على App Store بحيث يستخدمه الأشخاص بخلاف المطورين. قامت Microsoft بذلك من قبل عن طريق ترحيل Visual Studio من C ++ إلى C # و WPF (يُمنح العميل هو المطور في هذه الحالة). سيخبر ذلك Microsoft عن نقاط الألم لدينا وإذا نجحت ، فسوف يمنح ثقة هائلة لمجتمع المطورين بأن أي شيء ممكن مع Xamarin.

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

أدير فريق Agile Scrum ، وغالبًا ما يكون مؤشر الأداء الرئيسي هو السرعة (مقدار العمل المنجز). في بعض الأحيان ، عندما يتم تصعيد المشكلة إلى مستوى معين ، سيكون البيان الختامي دائمًا "... أتساءل عما يمكنني تعلمه هنا لتحسين جودة" [منتجنا]. لا يوجد أي إهانة (حقًا) ، ولكن هذا فقط لإرضاء مديري أو عميلنا. عندما أقول أنه خلال هذا النوع من سياق المناقشة ، فإن هذا يعني فقط أنني أو مالك المنتج الخاص بي ليس على مستوى الوظيفة أو أننا في حالة إنكار أو أسوأ من ذلك ، فنحن لا نعرف حقًا ما الذي يحدث. (مجد لأحد أصحاب المصلحة لدينا الذي صفع الإحساس مني)

ما يزعجني حقًا هو أخطاء الانحدار وعدم وجود أي استجابة / شرح موجز لهذه المشكلة. كل إصدارات XF تكون عرضة لكسر شيء ما ؛ وهو يكسر شيئًا واضحًا - محاذاة خاطئة ، لا تظهر الصورة ، لا يعمل اقتطاع النص وما إلى ذلك. نصف حالات الاختبار لدينا هي فقط للتحقق من هذه الانحدارات XF ؛ انه سخيف. من الواضح أن هناك خطأ ما في اختبار XF الداخلي. حتى عندما يتم التعرف على خطأ في show-stopper ، لا يزال هناك العديد من الإصدارات الجديدة اللاحقة ؛ ما هو الهدف من تلك الإصدارات الجديدة عندما لا نستطيع استخدامها؟ ألا يجب أن تدخل هذه الإصدارات الجديدة في الإصدار التجريبي الخاص بك؟

بعد كل هذا ، أنا وأصحاب المصلحة لدينا متعبون جدًا من "الثقافة السامة" مع XF. يشبه الأمر كيف يمكن لنظام Windows 10 إصدار التحديث الذي يحذف ملفات المستخدم أو نظام مستخدم الطوب (ولكن على الأقل استجابته والإصلاحات السريعة سريعة). أعتقد أن إحباطنا هنا لا يتعلق بنقص الميزات في XF ، ولكنه يتعلق بجودة الإصدار. كيف يمكن لـ XF تحسين الجودة؟ يمكنك البحث عبر الإنترنت والحصول على ملايين النتائج ؛ ولست متأكدًا من أين أبدأ هنا دون أن أكون متعجرفًا لتقويض فهم Microsoft لـ "ضمان الجودة". أنا متأكد من أن Microsoft تعرف كيفية القيام بضمان الجودة (مهلاً ، لقد قرأت أوراق Microsoft البيضاء حول هذا الأمر). يتلخص الأمر في الشخص المسؤول ؛ يحتاج إلى المسؤولية والمساءلة والالتزام بتحسين (أو تنفيذ) فحص الجودة.

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

أحد الأمثلة الجيدة على ذلك هو هذا الانحدار فيما يتعلق بجمعيات BundleAssemblies (سبق ذكره عدة مرات).
مثال جيد آخر هو هذه المشكلة بخصوص CollectionView.

مصدر قلق آخر بالنسبة لي هو أن تطبيق XF يتأثر بالتغييرات في XF بالطبع ، ولكن أيضًا Mono و Visual Studio و Xamarin Framework و DotNet وحتى بعض مكتبات Microsoft.
لدي شعور بأن تلك الفرق لا تتواصل بشكل جيد داخليًا.
في رأيي ، فإن استخدام Microsoft لـ XF داخليًا لتطبيقاتها سيساعد بالتأكيد.

مرة أخرى ، أحد الأمثلة الجيدة هو هذا الانحدار ، والذي يكون السبب الجذري له في الواقع في Mono و AndroidX.
ولكن يمكنني أيضًا أن أذكر هذه المشكلة في امتدادات dotnet التي تؤثر على تطبيقات iOS ، أو حتى هذه المشكلة في msal.
وبالطبع هذه القضية في الاستوديو المرئي ، بخصوص رابط المصدر.

لقد قام الأشخاص هنا بعمل رائع بقول معظم ما كنت سأقوله بالتفصيل ، لذا سأجعله سريعًا

مشاكل تقنية

• يتعطل الاستوديو المرئي أكثر من 3 مرات / دقيقة عند العمل مع XF.
• الكثير من الضوابط الأساسية مفقودة ، أو تتطلب هيكلاً لتشكيلها كما يفترض أن تكون.
• عندما تقول XF إنك تقول فقط أسوأ إطار عمل عبر النظام الأساسي ، واسمحوا لي أن أكون واضحًا للأشخاص الذين يقولون إن XF يتعامل مع android / ios الأصلي ... وهذا صعب. فقط انظر! من فضلك انظر! لمحبة الله! في flutter ، RN ، NativeScript ... لديهم جميعًا نفس الهدف ولكن XF متأخر جدًا
• لا يعمل إعادة التحميل السريع جيدًا إلا عند إنشاء مشروع جديد وجعل النص الافتراضي في الجانب الأيسر وهذا هو ، ثم بنفسك!
• كل شخص في مجتمع الرفرفة على سبيل المثال في كل إصدار يكون مثل: أوه يا إلهي ، إنه رائع جدًا لما فعلوه ، ومن ناحية أخرى يكون XF com مثل: لنرى ما كسروه أو ما أضافوه أن 10٪ فقط من com يحتاج!
• رحلة البداية باستخدام XF عبارة عن سلسلة من المراجعات ، ومثال على ذلك: كان علي مؤخرًا إنشاء أحد عناصر التحكم الشائعة في جميع التطبيقات على Playstore وهو رمز علامة تبويب بسيط في أسفل الصفحة فقط ، واستخدام shell with icon له هامش كبير فقط في الجزء السفلي تبدو قبيحة ومثل الجميع ، لقد خلقت مشكلة ، فقط لألاحظ أن مشكلة مماثلة قد تمت معالجتها منذ أكثر من 6 أشهر ... ولا يوجد حل في الطريق
• فكر في تطبيق جيد؟ أي تطبيق؟ هل يحتوي على عملية شراء داخل التطبيق أو نوع من الخدمة المتميزة؟ بالطبع هو كذلك. هل بدأت في البحث عن مكون إضافي لـ google pay و apple pay ، أليس كذلك؟ أو حتى paypale أليس كذلك؟ دعني أخبرك بشيء ، ليس هناك !!! عندما تسأل الفريق الرسمي لـ XF ، هل تعرف ماذا سيستجيبون؟ لقد أرسلوا لك رابطًا لمكوِّن إضافي قديم غير رسمي أنشأه رجل واحد (أحترمه) منذ عامين بدون تحديث ، WTF (آسف) !!

ليس تقنيا

• أوه ، لا ، حتى لو كانت الوثائق الرسمية سيئة للغاية ، فهم يتعاملون مع ميزات مستوى تطبيق todo والبرامج التعليمية الإرشادية
• كرهت XF حتى قبل استخدامها ، أتعرف لماذا؟ يقول الجميع حتى MS لا يستخدم فلماذا تستخدمه F؟
• استجابة بطيئة للغاية للقضايا والعلاقات العامة التي يتخذها المجتمع على وقتهم ونفقاتهم الخاصة لمساعدة فريق XF !!!

حلول

• فريق XF صغير جدًا ، كيف يمكن لشركة ضخمة مثل Microsoft لا توظف عددًا كافيًا من الأشخاص لجعل منتجهم أفضل؟ هناك مواهب في كل مكان حول العالم ممن يحبون Microsoft بقدر ما أحبهم!
• يجب أن تتعامل XF مع المشكلات عالية المستوى قبل إطلاقها ، فهي تُظهر فقط مدى عدم نضج الفريق ، مثل مجرد شحن من يهتم ...
• مايكروسوفت ملزمة في الغالب باستخدام XF لمنتجاتها! إذا لم تكن مجرد طريقة للقول أن XF جيد ولكن لا أحب ذلك yukh
• قم بعمل وثائق غنية جدا! مستند هو أول ما تذهب إليه في معظم المواقف ، قم بتوظيف المزيد من الأشخاص! الأمر بهذه السهولة ، فهناك الكثير من المطورين ذوي الخبرة الذين يقومون بإنشاء مدونات يمكنك العمل معهم
• XF غير معروف مثل Flutter ، قم بعمل شراكات مع المؤثرين الكبار في مجال الترميز على youtube ، حتى ذكر بسيط يساعد XF
• لا بأس أيضًا في إلقاء نظرة على المنتجات الأخرى ومعرفة ما يعجبه المطور عنها وإنشاء نسختك الخاصة. رفرفة على سبيل المثال.
• لا تخافوا من سؤال المجتمع عما يريدون ، لا تعيشوا تحت صخرة واصنعوا ما لن يستخدمه أحد!

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

@ Amine-Smahi يرجى التواصل عبر البريد الإلكتروني مع مزيد من المعلومات حول السلوك الذي يؤدي إلى الأعطال ([email protected]).

أوافق تمامًا على أن إصلاح الأخطاء وعملية اختبار الميزات الجديدة أمر مروع.

على سبيل المثال:
https://github.com/xamarin/Xamarin.Forms/issues/3335 - توقف عن استخدام ListView.RecycleElement
https://github.com/xamarin/Xamarin.Forms/issues/4168 - توقف عن استخدام CompressedLayout

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

وبعض المشكلات التي تؤثر على تطبيقاتي ولم يتم إصلاحها لفترة طويلة:
https://github.com/xamarin/AndroidX/issues/64
https://github.com/xamarin/Xamarin.Forms/issues/5087
https://github.com/xamarin/Xamarin.Forms/issues/5127
https://github.com/xamarin/Xamarin.Forms/issues/3168
https://github.com/xamarin/Xamarin.Forms/issues/8058 https://github.com/xamarin/Xamarin.Forms/issues/10055
https://github.com/xamarin/xamarin-android/issues/3341
https://github.com/xamarin/xamarin-android/issues/3480

يجب أن يتحمل الفريق مسؤولية الميزات التي ينفذونها. على سبيل المثال ، نفذ StephaneDelcroix https://github.com/xamarin/Xamarin.Forms/pull/1136. أعتقد أنه الشخص الذي يجب تعيينه لـ https://github.com/xamarin/Xamarin.Forms/issues/4168 وإصلاح الأخطاء المتعلقة بـ CompressedLayout.

حول الوثائق: أنا شخصيا أعتقد أنه في غالب الأحيان يرام، باستثناء ملاحظات الإصدار، والتي هي تماما و * د فوق؛) (دائما في وقت متأخر أو غير كاملة)
مرة أخرى ، لا أتحدث تحديدًا عن XF ، ولكن بشكل عام ، إطار عمل xamarin بالكامل (xamarin.android ، xamarin.ios ، visual studio ، mono ، المكونات ...).

هنا مثال: ملاحظات إصدار xamarin ios

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

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

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

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

قم بإلغاء الميزات الجديدة في 4.7-4.8 ، وانتبه لإصلاحات الأخطاء.
التطوير على Xamarin يشبه إيجاد حلول بديلة ، حلول مؤقتة.
أعتذر عن لغتي الإنجليزية الضعيفة

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

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

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

freever أتفق تماما!
لن يؤدي هذا فقط إلى جعل مطوري Xamarin الحاليين أكثر سعادة ، ولكنه سيحل هذه الأخطاء لـ MAUI أيضًا!

لا أعرف ما إذا كان سيتم تنفيذ هذه الأخطاء ليتم إصلاحها هنا في MAUI ، أم سيتم إصلاحها في Xamarin.

أشعر أن davidortinau غطى روح هذه القضية هنا

https://github.com/dotnet/maui/issues/109#issuecomment -635078640

لقد قمت بتحديث الوصف بتعليقه

أريد حقًا أن أسلط الضوء على هذا الجزء مما قاله مرة أخرى للجميع

نحن ننفق الكثير من سباقات السرعة الحالية على مشكلات CollectionView ، ونقترح إيقاف مطور الميزات مؤقتًا في Xamarin.Forms 5 لذلك لدينا من سبتمبر 2020 إلى نوفمبر 2021 لتحويل المزيد من التركيز إلى حل المشكلة.

PureWeen أغلقت هذا منذ 10 ساعات

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

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

@ tranb3r

أعتقد أن الشيء الأكثر إحباطًا فيما يتعلق بـ XF هو عندما يتجاهل الفريق مساهمتنا (سواء كانت علاقات عامة جديدة أو مشكلة جديدة أو حتى سؤالًا بسيطًا أو تعليقًا).

ما رأيك في تعليق

هههههههههههههههه

تواصلpauldipietro مع الشخص الذي نشر هذه المشكلة حتى يتمكن من البدء في معالجة هذه المشكلات بشكل مباشر معه.

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

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

مع MAUI ، يجب أن تكون لدينا عملية إصلاح أخطاء بأسرع ما يمكن. أي أفكار حول كيفية التحسين؟

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

هذا هو لوحة مشروعنا

https://github.com/xamarin/Xamarin.Forms/projects

يمكنك أن ترى ما نضيفه إلى كل سباق
https://github.com/xamarin/Xamarin.Forms/projects/70

ها هي خارطة الطريق الخاصة بنا
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
نحاول أن نكون شفافين قدر الإمكان فيما نعمل عليه

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

@ Amine-Smahi ها هي لوحة مشروع شل وما نراه كحاصرات
https://github.com/xamarin/Xamarin.Forms/projects/54

هل يمكنك توجيهي إلى المشكلة التي تشير إليها حتى أتمكن من إلقاء نظرة عليها؟

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

ما رأيك في تعليق

كما ذكرنا سابقًا ، تغطي هذه المشكلة أكثر بكثير من مجرد عدد الأخطاء في XF.

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

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

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

كما ذكرنا سابقًا ، تغطي هذه المشكلة أكثر بكثير من مجرد عدد الأخطاء في XF.

دعونا نخلق قضايا مختلفة لهؤلاء. معالجة أشياء متعددة في قضية واحدة لن تكون مثمرة.

ما التعليقات الأخرى هنا التي ليس لها أي علاقة بأخطاء الأخطاء / العلاقات العامة / الهشاشة حول XF التي تريد توضيحها؟

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

نعم ، نحاول إقناع الجميع حرفياً باستخدام Xamarin

نتحدث كثيرًا مع الفرق الداخلية حول خيارات التطبيق وهي مناقشة مستمرة. ستوجه الكثير من هذه المناقشات الداخلية أيضًا اتجاه .NET Maui.

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

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

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

1. تبسيط المستودع لتسهيل المساهمة ومراجعة المساهمات. قد تساعد بنية العارض الجديدة في حالة إزاحة XAML من جوهرها وإعطاء نهج أكثر أمانًا من النوع للعارضين.
2. إعطاء الأولوية لإصلاحات الأخطاء والتعليمات البرمجية النظيفة على الميزات. نظرًا لأن ثقافة Xamarin تتمثل في إضافة ميزات جديدة مع تجاهل الأخطاء ، فإن أفضل طريقة هي فرض حظر كامل على الميزات الجديدة حتى يتم استيفاء حد الجودة للميزات الحالية.
3. السماح بالتغييرات الفاصلة التي تعمل على إصلاح الأخطاء وتنظيف التعليمات البرمجية.
4. حقق أقصى استفادة من .Net لتقليل الأخطاء. احتفظ بالأشياء داخل نظام الكتابة كلما أمكن ذلك ، واستخدم بدائل النيكوتين C # 8.
5. أصلح عناصر التحكم الأساسية أولاً ، ثم عناصر التحكم المتبقية.
6. تخلص من أنظمة التشغيل المستهدفة القديمة والمحررين القدامى لتنظيف الريبو وتبسيط الاختبار وتحرير الموارد
7. تقرير عن مقياس البق علانية. سيساعد هذا في تركيز المنظمة على الأخطاء. ضع تقدمًا في الأخطاء باعتباره القسم الأول في أي مدونة حول التحديث.
8. قم بإزالة الميزات لتقليل حجم المستودع ، لجعله أكثر قابلية للصيانة.

تجربتنا: نحن نستخدم فقط طرق عرض XF الأساسية لأننا لا نثق في أي شيء آخر يمكن استخدامه. التسمية ، الإدخال ، الزر ، المنتقى ، التبديل ، منتقي التاريخ ، المنزلق ، StackLayout ، ScrollView ، ContentView ، Grid ، ContentPage. ولكن حتى ذلك الحين ، تظهر الحشرات وتبقى لأشهر. من الصعب جدًا الحصول على إصلاحات في XF لدرجة أننا نقوم فقط بنسخ ولصق العارضين في التعليمات البرمجية الخاصة بنا بدلاً من ذلك.

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

هذه خطتنا. لقد قمت بإنشاء مشكلة نائب هنا يمكنك اتباعها أو تقديم اقتراحاتك https://github.com/dotnet/maui/issues/147

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

هذه هي خطتنا في الغالب.

السماح بالتغييرات الفاصلة التي تعمل على إصلاح الأخطاء وتنظيف التعليمات البرمجية.
حقق أقصى استفادة من .Net لتقليل الأخطاء. احتفظ بالأشياء داخل نظام الكتابة كلما أمكن ذلك ، واستخدم بدائل النيكوتين C # 8.

هذه هي خطتنا ببطء. لكن من المهم فهم النطاق الكامل للمستخدمين الذين يستخدمون منتجاتنا. على سبيل المثال ، بمجرد كسر دعم vs2017 ، ظهرت هذه المشكلة هنا والتي تلقت الكثير من التعليقات من المستخدمين
https://github.com/xamarin/Xamarin.Forms/issues/7602

لذلك لا يمكننا القفز فقط. أود 100 في المائة أن أقوم بهذه القفزة ولكن لا يمكننا تحطيم الناس فقط.

لكننا نتخذ خطوات باستمرار للاستعداد لهذه القفزة. على سبيل المثال العلاقات العامة هنا
https://github.com/xamarin/Xamarin.Forms/pull/10937

سيسمح لي بتشغيل عملية CI الداخلية للاختبار مقابل C # 8 والميزات التجريبية الأخرى حتى نتمكن من تحقيق قفزة سهلة.

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

هذه خطتنا كما ذكرت أعلاه

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

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

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

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

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

الإصدار القديم من الشهرين التاليين: https://github.com/xamarin/Xamarin.Forms/issues/11166
تم إنشاء الخطأ في 22 Jun.
تم افتتاح العلاقات العامة في 25 يونيو.
حالة الخطأ 17 أغسطس: لم يتم دمجها بعد. لماذا ا؟ ؛ (

PawKanarek مرحبا بكم في Xamarin. عادة ما يدمجون فقط الإصلاحات أو Prs التي قام بها الفريق. هذا هو السبب في أنه من المحبط المساهمة في Xamarin. أعتقد أنهم قللوا من قدرة الفريق. فقط 2-3 أشخاص يعملون بنشاط في المشروع. إذا كنت بحاجة إلى إصلاح سريع ، فقم ببناء حزم xamarin nuget الخاصة بك.

EmilAlipiev ولكن هذه المرة تم فتح العلاقات العامة (لـ # 11166) بواسطة أحد أعضاء فريق Xamarin ولم يتم دمجها بعد xD

إذا ألقيت نظرة على ملاحظات الإصدار ورؤى GitHub ، فإننا ندمج الكثير من العلاقات العامة من المجتمع. في الحقيقة أرى اسمك في القائمة الأخيرة EmilAlipiev :)

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

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

@ hamiddd1980 ستسعد بمعرفة أننا نعمل قليلاً على RTL خلال الأشهر القليلة الماضية. آمل أن تحسن تجربتك!

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

الرجاء إصلاح المزيد من الأخطاء ، لا تقم بإضافة المزيد من الميزات. الاستقرار على الوظائف. لا يزال لديك 1590 خطأ تم التحقق منه https://github.com/xamarin/Xamarin.Forms/issues؟q=is٪3Aopen+is٪3Aissue+-label٪3As٪2Funverified+label٪3A٪22t٪2Fbug+٪3Abug٪3A٪ 22

samhouts شكرا
إلى جانب ذلك ، هناك مسألة تحديد الأولويات من جانبك. يبحث الناس بشدة عن إصلاحات للأدوات الأساسية مثل الأخطاء مثل Device.Idiom .. أو CollectionView bugs وما إلى ذلك.
اليوم كان هناك تقدم كبير بالفعل 8 عمليات دمج حتى الآن. ولكن لكي نكون صادقين في عمليات الدمج أدناه ، فإن عددًا أقل من الأشخاص يهتمون بعرض التمرير السريع أو الفرش المتدرجة أو السمات وما إلى ذلك عندما تكون هناك علاقات عامة مهمة في قائمة الانتظار لأشهر. هذا هو أكبر إحباط على ما أعتقد

يجب إصلاح أي خطأ مفتوح وتم التحقق منه في github في أسرع وقت ممكن

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

الرجاء إصلاح المزيد من الأخطاء ، لا تقم بإضافة المزيد من الميزات

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

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

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

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

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

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

يرجى العلم أننا نضعك أنت وعملائك دائمًا في الاعتبار أثناء إجراء أي تغييرات ، ونحن نستمع إلى تعليقاتك.