Я думаю, что для людей из сообщества будет полезно, если команда Xamarin.Forms запишет больше документов об архитектуре Xamarin.Forms, принципе проектирования и его рабочем процессе в Github или документах MS.
С моей точки зрения, я использую Xamarin.Forms для создания своих продуктов, у меня будет 2 варианта выбора, когда я столкнусь с ошибками, один - отправить проблему в github и ждать, когда она будет исправлен, а другой - отправить проблему в github и исправил сам.
После клонирования исходного кода и его отладки трудно понять, как работают эти функции. Например https://github.com/xamarin/Xamarin.Forms/issues/8521
Другой пример - функция навигации по страницам Xamarin.Forms на стороне Android. Легко понять функцию навигации среди действий на Native Android. Но в Xamarin.Forms кажется, что он использует одно основное действие для обработки всей страницы (возможно) (кроме собственных форм и собственного представления).

Я считаю, что это здорово.

Разделение галереи и витрин для спецификаций / проблем и т. Д. На более мелкие проекты, над которыми можно работать и легче демонстрировать, является большим преимуществом в цикле разработки.

Одна из самых проблемных вещей - это иметь несколько разных версий, в которых исправляются ошибки или добавляются функции, а затем при дальнейшем улучшении.
В этом очень помогает наличие нескольких экземпляров меньшего размера.

Еще одна вещь, о которой я думаю, - это использование кодовых пространств и в будущем github-codepaces, где можно прикрепить точечные файлы для проблемы (включая правильную версию xamarin и т. Д.), А затем мы могли бы просто использовать кодовые пространства или проверить эту версию.

Лучше всего, если бы меньшие части контрольной галереи были доступны в виде проектов, которые доступны отдельно и могут быть просто открыты в кодовых пространствах. Я вижу много преимуществ в сочетании небольших управляющих приложений и кодовых пространств.

Думаю, я пытаюсь сказать:

• Множественная контрольная галерея
• поддержка кодовых пространств
• точечные файлы, о которых идет речь

Изменить: добавлен третий пункт.

Я согласен, что несколько месяцев подряд у меня открывались несколько вопросов. Я клонировал XF, но просто заблудился в нем.
Так что документ для видео, просто демонстрирующий, как работает решение, был бы отличным.

Чем больше .Netty, тем лучше.

1. Удалите из сердечника волшебные нити и нетипизированные привязки. Не требуйте, чтобы кто-либо, участвующий в репо, писал нетипизированную привязку или строку без проверки типа. Это значительно уменьшит количество ошибок, значительно упростит исправление ошибок и упростит рефакторинг, чтобы новые ошибки не появлялись.
2. Не требуйте от участников работы с каким-либо слоем разметки. Некоторые разработчики захотят использовать XAML или CSS, но участники, исправляющие ошибки, не должны заботиться об этих вещах. Только люди, работающие над языками разметки, которые должны быть слоем поверх реальных классов .Net, должны заботиться об этом слое.
3. Подход средства визуализации должен быть структурирован таким образом, чтобы неспособность реализовать изменение свойства (или ошибка типа при выполнении этого, как указано выше) являлась ошибкой типа.
4. Там, где это уместно, должен существовать допуск для реализации некоторых функций вообще без привязок к конкретной платформе, например, с использованием SkiaSharp, Shapes или составных объектов MAUI, для надежных кроссплатформенных реализаций, которые отображают то же самое и не вносят новых ошибок.

В какой-то момент мы тестировали направление, в котором пользователи упрощенного SLN могут внести свой вклад в это.

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

Просто предоставьте очень целевой "Contributor.sln", где участники могут продемонстрировать исправление или API.

Удалите все текущие галереи и просто сфокусируйте их на платформах и MainPage.

Может ли фильтр решения быть лучше? Вам не нужно поддерживать два решения.

Посмотрим, что все получится с помощью фильтров решений.

AFAIK в настоящее время они не работают с vsmac, и они немного странные, когда у вас есть многоцелевые проекты. Как только мы сможем получить первоклассную поддержку для множественного таргетинга, а головные проекты могут быть просто стилями sdk, я думаю, что потребность в фильтрах решений не так высока.

Другая неприятная вещь заключается в том, что VS для Windows в настоящее время строит все цели, когда у вас есть несколько таргетингов, тогда как vsmac просто строит одну для головы платформы, которую вы используете.

Другая неприятная вещь заключается в том, что VS для Windows в настоящее время строит все цели, когда у вас есть несколько таргетингов, тогда как vsmac просто строит одну для головы платформы, которую вы используете.

Было бы здорово получить поддержку этого в VS для Windows! Я мог избавиться от всех этих дополнительных конфигураций, которые я сделал, чтобы создать только ту платформу, с которой я работаю в данный момент.

Согласитесь, что текущая история с множественным таргетингом на VS для Mac невероятно разочаровывает. К сожалению, множественный таргетинг - это такой отличный вариант, что я все еще выбираю его в качестве своего подхода и просто служу технической поддержкой для других членов команды, которые сталкиваются с проблемами. Это нескончаемый поток разочарования.