На развертывание 7049 ушло более 1 месяца, даже если PR объединен через 7 дней после отчета об ошибке.

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

Надеюсь, у команды есть план по устранению некоторых узких мест, связанных с процессом выпуска PR +.

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

И посмотрите на это: после того, как он был упомянут в заметной проблеме, кто-то из команды Xamarin.Forms наконец ответил на https://github.com/xamarin/Xamarin.Forms/pull/7728.

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

И посмотрите на это, после того как кто-то из команды Xamarin.Forms был упомянут в заметной проблеме, наконец, ответил на xamarin / Xamarin.Forms # 7728 .

Сочувствую команде. Так много проблем нелегко отсортировать / решить / исправить. При этом определенно необходимо сосредоточиться на устранении узких мест и решении открытых проблем и PR.

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

Я вижу пару связанных моментов

1) Я не знаю, сколько людей работает над формами, но мне кажется, что команда слишком мала, чтобы успевать за быстрым ростом новых ошибок или PR. Это будет только хуже, так как им придется разделить внимание между Формами и Мауи. Очень надеюсь, что вскоре команда получит существенный прирост.

2) Было бы действительно полезно, если бы Microsoft фактически начала использовать Forms в своих собственных приложениях. И я не имею в виду простые демонстрационные приложения или приложения для конференций. Я имею в виду настоящие приложения, такие как Teams или Outlook. Я был бы рад, если бы я ошибался в этом, но мне не удалось найти приложение MS Forms в магазинах, и, согласно некоторым источникам, подобным этому твиту https://twitter.com/safaiyeh/status/1219294459298344961, они в основном реагируют родные.

• это действительно не посылает хороший сигнал, потому что если MS не использует свою собственную технологию (XF), то почему мы должны?

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

3) Я вижу еще одну проблему в том, что MS постоянно пытается изобрести колесо в форме XF Xaml вместо использования уже проверенных и существующих решений, таких как Win UI Xaml. Им приходится тратить время на разработку уже существующих функций и исправление ошибок, которые появляются из-за этого, и тогда остается меньше времени для других функций и исправлений ошибок.

Я на 100% согласен с @Reveon
о, и я должен сказать, что использование VisualStudio для Windows с Xamarin - очень неприятный опыт.

Они продолжают добавлять выдающиеся, блокирующие, ошибки ... я даже не знаю, как это возможно (такие вещи, как нарушение ВСЕХ сборок устройства ios, нарушение профилей подготовки, нарушение распознавания жестов ... как могут подобные ошибки попадать в производство, а затем на исправление в сборке релиза уйдут недели или месяцы? не знаю ....)

Для этого я перешел на Rider и теперь использую продукт Jetbrains везде :) По крайней мере, я могу использовать IDE, которая точно такая же в iOS и Windows, и продолжать продуктивно работать.

Я уверен, что с MAUI это изменится, и рано или поздно Microsoft начнет использовать MAUI для внутренних целей для серьезных проектов.

Другой отзыв:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@EmilAlipiev :

Я ждал, пока мой PR будет объединен 1.5 месяца по этому выпуску. Уже существует проблема для iOS, и Android была исправлена ​​в июле 2019 года, и никто не трогал uwp. Исправил в апреле и несколько раз просил для обзора и слияния. Действительно раздражает, как работают команды xamarin. Вы можете видеть, что они просматривают только 1-2 PR в день.
# 10316

Хотя я часто расстраиваюсь, «Xamarin ошибается» - это резкое заявление. Более 2000 открытых проблем сегодня, если вы проверите, что у flutter 5000+ открытых проблем. Цифры не так важны. Xamarin.forms предлагает больше, чем другие кросс-платформы, такие как uwp (включая xbox), wpf, mac, gtk, tizen. Так что есть много открытых проблем, например, для Wpf, который для большинства из нас менее важен.
Ядром Xamarin.forms должны быть ios, android и uwp, хотя команда Xamarin часто пренебрегает uwp.

1. Должны быть основные элементы, такие как макеты, списки, карусель, коллекция, изображения, карты, метка, редактор и т. Д. Они не должны содержать ошибок. если вы делаете новый выпуск или обновление для них, вы должны убедиться, что в них нет ошибки showstopper. Если есть ошибка, вы должны устранить ее в течение недели. Но команда Xamarin выпускает классную версию 4.5-4.6 с классными функциями (кому нужен этот модный инструмент, 10% сообщества?), А управление изображениями не работает. Проблема была зарегистрирована в начале марта и до сих пор не решена. Тот же "Bundle into native сборки" сломан. По этим важным причинам я не могу перейти на 4.5 и 4.6. Они продолжают развиваться с 4.7, добавляя новые функции. Я и большинство из нас слежу за примечаниями к выпуску, исправлены ли наши ошибки, я даже больше не читаю, какая функция была добавлена.
2. Команда Xamarin должна это понимать. Самая большая причина, по которой многие люди выбирают Xamarin, - это «UWP». Я фрилансер. Я спрашиваю своего покупателя, почему бы не трепетать или не реагировать на нативные? Он говорит, потому что в Xamarin есть UWP. Я также хочу UWP. Но в Uwp в основном есть ошибки с Xamarin.forms. они представили CollectionView, это действительно здорово, но через год эта ошибка не решена. Исправил, никто не просматривает. Я был обескуражен делать какие-либо дальнейшие пожертвования.
3. Hotreload вообще не работает. Я читал в твиттере все «поцелуй, поцелуй», как здорово это hotreaload. Я думаю, что со мной что-то не так, или они используют какой-то другой инструмент. Потому что часто hotreload не обновляется. Я до сих пор использую сторонние инструменты, такие как livexaml и т. Д. Я даже создал простое консольное приложение для собственной горячей перезагрузки. мне это стоит 1 день. Работает намного лучше, чем Xamarin, и даже работает с uwp. Как они могут этого не доставить? У них livereload работал.

4. Самый важный момент; что упомянул @Reveon . им нужно настоящее корпоративное приложение, которое работает с xamarin.forms, и они должны обновлять его новыми выпусками, чтобы обнаруживать реальные проблемы. Они жалуются, что «не так уж и сложно дать репутацию». Да, это очень сложно, если эта проблема возникает только в вашем корпоративном приложении, а не в приложении todo. Вам нужно попытаться воспроизвести тот же пользовательский интерфейс. это может стоить ваших дней, пока вы не разберетесь. Вот почему очень важно, чтобы у кого-то было большое приложение. Мне интересно, действительно ли кто-нибудь из тех разработчиков Xamarin, которых мы видим на twitch, youtube, twitter и т. Д., Когда-либо разрабатывал большое приложение с xamarin.forms.

5. Я должен признать, что, хотя я не люблю использовать инструменты с открытым исходным кодом, более 50% моих приложений используют инструменты синхронизации. Я думаю, что без Syncfusion очень сложно получить рабочее приложение для предприятий. У них есть все, чего нет в xamarin или что такое багги xamarin. Например, я годами искал замену sfListView с перетаскиванием, просмотром смахивания, линейным и сеточным макетом, улучшенной виртуализацией и т. Д. Наконец, xamarin вышел с CollectionView, и они бросили его нам в лицо как «классную версию» Listview, но затем он глючный. Не работает для Uwp. многие недостающие функции. Просто найдите CollectionView среди проблем, и вы найдете их десятки.

Я по-прежнему верю, что Xamarin - лучший инструмент для кросс-платформы, и надеюсь, что они воспримут эту проблему как конструктивный отзыв.

Замечательные и конструктивные комментарии. Я читал список и чувствовал то же самое, что и другие разработчики. Проблемы типичны для тех из нас, кто использует Xamarin.Forms для разработки корпоративных приложений. Отслеживание ошибок и их исправление требуют большего внимания, но, в частности, ясен один момент, и я много раз спрашивал себя, почему не существует корпоративного приложения MS, созданного с помощью Xamarin.Forms. MS Teams или любой другой. Если ответ: слишком сложный или невозможный путь с Xamarin.Forms, есть отличное внутреннее понимание, позволяющее улучшить платформу в целом и попытаться исправить эти проблемы. Xamarin / MAUI, безусловно, выиграет, если больше разработчиков будут тестировать, вносить свой вклад и распространять информацию, но это должна быть улица с двусторонним движением. Опять же, я не жалуюсь, но было бы здорово увидеть в этом году, в следующем году, отличную версию мобильного приложения для MS, созданного с помощью MAUI или Xamarin. Также проверьте разработчиков на предмет их разочарований или возможных улучшений и выведите кроссплатформенную разработку на новый уровень.

Потому что меня упомянули ...

Я веду небольшой проект по кроссплатформенному приложению между Android и Windows Desktop (WPF).

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

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

В части xamarin, относящейся к wpf, есть над чем поработать. Производительность плохая, и это чертовски простые ошибки. Но идея и основа заложены. Печально видеть текущее состояние, потому что могло бы быть лучше ...

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

Я вижу пару связанных моментов

1. Я не знаю, сколько людей работает над формами, но мне кажется, что команда слишком мала, чтобы успевать за быстрорастущими темпами новых ошибок или PR. Это будет только хуже, так как им придется разделить внимание между Формами и Мауи. Очень надеюсь, что вскоре команда получит существенный прирост.
2. Было бы действительно полезно, если бы Microsoft фактически начала использовать Forms в своих собственных приложениях. И я не имею в виду простые демонстрационные приложения или приложения для конференций. Я имею в виду настоящие приложения, такие как Teams или Outlook. Я был бы рад, если бы я ошибался в этом, но мне не удалось найти приложение MS Forms в магазинах, и, согласно некоторым источникам, подобным этому твиту https://twitter.com/safaiyeh/status/1219294459298344961, они в основном реагируют родные.

• это действительно не посылает хороший сигнал, потому что если MS не использует свою собственную технологию (XF), то почему мы должны?
• внутреннее использование форм в сложных приложениях может стать дополнительным уровнем тестирования и уменьшить количество проблем, возникающих в общедоступной версии. Кроме того, они могли видеть, что работать с формами не так просто, как они нам говорят.

1. Я вижу еще одну проблему в том, что MS постоянно пытается изобрести колесо в форме 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 в качестве моего запускаемого проекта, он покажет всевозможные ложные ошибки. Уничтожение папок bin или obj не помогает. Мне требуется перезапустить VS. В другом примере VS случайно потеряет соединение с моим Mac, пока я отлаживаю свое приложение. Это приведет к зависанию моего VS. Я устрою истерику, подвергну сомнению свое хобби и свою жизнь в качестве разработчика мобильных устройств и заставлю убить VS с помощью диспетчера задач. Более того, я обнаружил, что в будущих версиях Visual Studio снова будут появляться ошибки, исправленные в предыдущих версиях. Я не знаю, как установить предыдущую версию VS после выпуска последней версии и ее установки. Я могу удалить его и попытаться переустановить с помощью установщика, но он всегда будет устанавливать последнюю версию. Это не похоже на пакет NuGet, где вы можете установить любую версию.

Наконец, почему элемент управления сегментированной вкладкой уже не входит в набор инструментов Xamarin? Сегментированные вкладки используются практически везде. Мне не нужно использовать набор инструментов Syncfusion или другой набор инструментов, чтобы использовать столь распространенный элемент управления.

Я нервничаю, чтобы использовать MAUI, когда он появляется в любом профессиональном приложении, которое я разрабатываю, пока не будут решены многие из этих разочарований разработчиков, использующих Xamarin и Visual Studio. Я буду играть и экспериментировать с ней, когда она выйдет. Но я получу больше уверенности, если Microsoft выйдет и создаст корпоративное приложение с использованием MAUI вместо создания простых демонстрационных приложений.

Может ли кто-нибудь рассказать нам о планах Xamarin Forms и MAUI? Будут ли они поддерживаться параллельно? Есть ли полная остановка для поддержки Xamarin Forms и будет ли Microsoft заталкивать нам в глотку MAUI в будущем обновлении Visual Studio?

Спасибо

@SunnyMukherjee Из FAQ,

Какое будущее у Xamarin.Forms?

Следующая основная версия Xamarin.Forms выйдет примерно в сентябре 2020 года и будет продолжать обновляться посредством выпуска .NET MAUI с .NET 6. После этого Xamarin.Forms продолжит получать приоритетное обслуживание в течение 12 месяцев.

По сути, Xamarin.Forms будет уничтожен после версии 5.

@SunnyMukherjee Из FAQ,

Какое будущее у Xamarin.Forms?

Следующая основная версия Xamarin.Forms выйдет примерно в сентябре 2020 года и будет продолжать обновляться посредством выпуска .NET MAUI с .NET 6. После этого Xamarin.Forms продолжит получать приоритетное обслуживание в течение 12 месяцев.

По сути, Xamarin.Forms будет уничтожен после версии 5.

К середине 2021 г. . . если Covid не убьет меня до этого, то Maui или Xamarin Forms сделают это.

@SunnyMukherjee Я слышу твою боль. Я использую Xamarin.Forms с тех пор, как он впервые появился, и с тех пор он претерпел значительные изменения. Помните, что Microsoft не создавала Xamarin.Forms, они купили Xamarin только в 2018 году. Таким образом, MAUI - это проект Microsoft, направленный на то, чтобы переписать его, чтобы он стал лучше и работал без проблем со всей .net. Работа с Xamarin.Forms нетривиальна, потому что то, что он должен делать, нетривиально. Многие люди говорят, что им следует просто делать то, что сделали Uno или Flutter, и полностью создавать элементы управления, но это противоречит тому, что представляет собой Xamarin.Forms. Это собственный фреймворк для разработки - общий доступ к встроенным элементам управления. Это непростая задача. У меня также было много проблем с Xamarin.Forms, но в целом время, сэкономленное за счет его использования вместо написания одного и того же приложения на нескольких языках, намного перевешивает проблемы. Кроме того, возможность совместного использования 90% кода с базовыми проектами ASP.Net делает это еще более целесообразным.
Хотя важно сообщить Microsoft, что мы хотим от MAUI, но мы должны понимать, что это непростая задача для них, и я надеюсь, что MAUI станет огромным шагом в правильном направлении.
Посмотрите это видео из недавней сборки, которая демонстрирует MAUI и объясняет, как она вписывается в дорожные карты, а также что они будут делать и поддерживать в Xamarin.Forms тем временем:
https://channel9.msdn.com/Events/Build/2020/BOD106?ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

Читая здесь, мне интересно, что я могу здесь узнать, чтобы улучшить качество Xamarin.Forms. Я хотел бы вернуться к исходному вопросу @ Happypig375 :

Есть мысли о том, как улучшить?

Одна из наших основных целей с настоящего момента и до выпуска .NET MAUI - улучшение основы, отправной точки. По этой причине мы тратим большую часть наших текущих спринтов на проблемы с CollectionView, и мы предлагаем приостановить разработку функций в Xamarin.Forms 5, чтобы с сентября 2020 года по ноябрь 2021 года мы могли больше сосредоточиться на решении проблем.

Все это видно на досках наших спринт-

Суммируя:

• Будьте быстрее при запросе сообщества.

Я перебазировал дерево запросов на вытягивание несколько дней назад. Почему проверка длится так долго?

WPF-Renderer, возможные ошибки:

• Измерение / расположение элементов управления
• Логическое / визуальное дочернее дерево не работает
• Представление

Привет, @davidortinau , я думаю, что хороший способ

• сортировка ошибок
• управлять, рассылать и продвигать PR-обзор и слияние.

Он / она мы будем нашим контактным лицом, если что-то пойдет слишком медленно, и он / она может объяснить, что происходит.
Более того, если есть препятствия не юридического характера, было бы здорово, если бы у нас был канал Twitch, где, в свою очередь, кто-то исправляет ошибку или просматривает PR онлайн. IHMO, это может оказать огромное влияние на интерес и сотрудничество внешних разработчиков.
Это справедливо как для .NET MAUI, так и для Xamarin Forms. Но может я просто мечтатель 😄

Я не очень удивлен, что в Xamarin.Forms есть много ошибок, учитывая количество платформ, на которых он работает, и изменения с платформ или его собственная разработка.

Что меня удивляет, так это количество регрессионных ошибок, вещей, которые работали раньше или были исправлены раньше, а затем ломаются в следующем выпуске.
Для меня это явный признак недостаточного тестирования. Более строгий режим тестирования может привести к тому, что некоторые изменения не появятся в следующем выпуске, но их ранняя регистрация действительно необходима, чтобы избежать клейма ненадежного продукта, если прямо сказать.

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

Когда я сказал «основные функции» и «критические ошибки». Вот что я имею в виду, проблема вроде этой . Это сейчас очень раздражает. Каждую неделю я выпускал релиз, даже не зная об этой проблеме. Мне было интересно, почему резко упало удержание приложений. Представьте, что у меня в основном люди, не говорящие по-английски, и пользователь, использующий испанский или немецкий язык, открывает приложение, и оно является английским из-за этой ошибки. Он сразу удалит его, хотя мое приложение переведено на этот язык. Эта ошибка может произойти, но о ней сообщалось ранее? почему не было исправлено. Даже в Appcenter и Azure Pipelines есть эта ошибка.

Для улучшения фреймворка. Хочу добавить:

Улучшите возможность написания собственного средства визуализации. Избегайте ключевого слова internal .

Вместо того, чтобы просто публиковать образцы проектов на GitHub, Microsoft может создать профессиональное корпоративное приложение, такое как OneDrive или приложение Xbox, с Xamarin Forms, iOS или Android и опубликовать его в App Store, чтобы его могли использовать люди, не являющиеся разработчиками. Microsoft делала это раньше, мигрировав Visual Studio с C ++ на C # и WPF (при условии, что в этом случае разработчиком является заказчик). Это расскажет Microsoft о наших болевых точках, и если им это удастся, это вселит огромную уверенность в сообществе разработчиков в том, что с Xamarin все возможно.

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

Я управляю командой Agile Scrum, и очень часто KPI - это скорость (количество проделанной работы). Иногда, когда у нас проблема доходит до определенного уровня, моим заключительным заявлением всегда будет «... Мне интересно, что я могу здесь узнать, чтобы улучшить качество» [нашего продукта]. Без обид (правда), но это просто для того, чтобы опекать моего босса или нашего клиента. Когда я говорю это во время такого рода обсуждения, это будет означать только то, что я или мой владелец продукта не справляемся с работой, или мы находимся в состоянии отрицания, или, что еще хуже, мы действительно не знаем, что происходит. (Престижность одному из наших участников, который выбил из меня здравый смысл)

Что меня действительно беспокоит, так это ошибки регрессии и отсутствие краткого ответа / объяснения проблемы. Каждый выпуск XF склонен что-то ломать; и это нарушает то, что очевидно - неправильное выравнивание, изображение не отображается, не работает усечение текста и т. д. Половина наших тестовых примеров предназначена только для проверки этих регрессий XF; это нелепо. Очевидно, что-то не так с внутренним тестированием XF. Даже когда обнаружена ошибка « показной

Сказав все это, я и наши заинтересованные стороны очень устали от «токсичной культуры» с XF. Это похоже на то, как Windows 10 может выпускать обновление, которое удаляет файлы пользователя или блокирует систему пользователя (но, по крайней мере, их ответ и исправление являются быстрыми). Я считаю, что наше разочарование здесь связано не с отсутствием функций в XF, а с качеством выпуска. Что касается того, как XF может улучшить качество? Вы можете искать в Интернете и получать миллионы результатов; и я даже не уверен, с чего начать, не будучи высокомерным, чтобы подорвать понимание Microsoft о «гарантии качества». Я уверен, что Microsoft знает, как обеспечить качество (эй, я читал официальные документы Microsoft по этому поводу). Все сводится к ответственному лицу; он / она нуждаются в ответственности, подотчетности и стремлении улучшить (или внедрить) проверку качества.

Я думаю, что больше всего расстраивает XF, когда наш вклад (будь то новый PR, новая проблема или даже простой вопрос или отзыв) просто игнорируется командой.
Команда, наверное, слишком мала. Но наличие одного человека, который предоставит ответы в разумные сроки, определенно поможет.

Хороший пример - это регресс в отношении BundleAssemblies (об этом уже упоминалось несколько раз).
Еще один хороший пример - проблема с CollectionView.

Еще меня беспокоит то, что на приложение XF, конечно же, влияют изменения в XF, но также и в Mono, Visual Studio, Xamarin Framework, DotNet и даже некоторых библиотеках Microsoft.
У меня такое ощущение, что эти команды плохо общаются внутри.
На мой взгляд, если бы Microsoft использовала XF внутри своих приложений, это определенно помогло бы.

Опять же, одним из хороших примеров является эта регрессия , основная причина которой на самом деле в Mono и AndroidX.
Но я также могу упомянуть эту проблему в расширениях dotnet, влияющих на приложения iOS, или даже эту проблему в msal.
И, конечно же, эта проблема в Visual Studio , касающаяся ссылки на источник.

Люди здесь отлично поработали, рассказав большую часть того, что я собирался сказать, в деталях, так что я сделаю это быстро

Технические проблемы

• Visual Studio дает сбой более 3 раз в минуту при работе с XF.
• Отсутствуют многие базовые элементы управления, или требуется, чтобы они были сформированы так, как они должны быть.
• Когда вы говорите XF, вы просто называете кроссплатформенный фреймворк с худшей производительностью, и позвольте мне прояснить, что XF решает проблемы с родным Android / ios ... и это сложно. Взгляни! посмотрите пожалуйста! во имя любви Господа! at flutter, RN, NativeScript ... Все они преследуют одну и ту же цель, но XF сильно отстает
• Горячая перезагрузка работает хорошо только тогда, когда вы создаете новый проект и делаете текст по умолчанию в левой части, и все, тогда вы сами!
• Каждый в сообществе flutter, например, в каждом выпуске будет похож: О Боже, это так круто, что они сделали, С другой стороны, XF com будет похож: давайте посмотрим, что они сломали или что они добавили, что требуется только 10% com!
• Начальное путешествие с использованием XF - это серия чертовски, примером может быть: недавно мне пришлось сделать один из общих элементов управления во всех приложениях в Playstore, который представляет собой только простой значок нижней вкладки. Использование оболочки со значком только имеет большой запас внизу, которые выглядят некрасиво и, как и все, я создал проблему только для того, чтобы заметить, что аналогичная проблема была решена более 6 месяцев назад ... И никаких исправлений на пути
• Подумайте о приложении, хорошо? Любое приложение? Есть ли у него покупка в приложении или какая-то услуга премиум-класса? Конечно, есть. Итак, вы начали искать плагин для Google Pay и Apple Pay, верно? Или даже PayPale, верно? Позвольте мне сказать вам кое-что, нет !!! Когда вы спросите официальную команду XF, вы знаете, что они ответят? Они отправляют вам ссылку на устаревший неофициальный плагин, созданный одним человеком (которого я уважаю) 2 года назад без обновлений, WTF (извините) !!

Не технический

• О, да, даже официальная документация очень плохая, они посвящены функциям уровня приложения и практическим руководствам.
• Я ненавидел XF еще до того, как его использовал, знаете почему? Все говорят, что даже MS не использует, так зачем вам это использовать?
• Очень медленный ответ на вопросы и PR, которые сообщество делает в свое время и за свои деньги, чтобы помочь команде XF !!!

Решения

• Команда XF очень и очень мала. Как компания может быть огромной, если Microsoft не нанимает достаточно людей, чтобы сделать свой собственный продукт лучше? Во всем мире есть таланты, которые любят Microsoft так же сильно, как и я!
• XF должен решить проблемы высокого уровня перед выпуском, он только показывает, насколько незрелая команда, как просто корабль, которому все равно ...
• Microsoft больше всего и обязана использовать XF для своих продуктов! Если это не просто способ сказать, что XF хорош, но нет, мне это не нравится, юх
• Сделайте очень богатую документацию! Документ, который является первым помощником в большинстве ситуаций, нанимайте больше людей! это так просто, есть много опытных разработчиков, которые ведут блоги, с которыми вы можете работать
• 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.

О документации: Я лично считаю , что это в основном нормально, за исключение примечания к выпуску, которые полностью е * d до исключения;) (всегда с опозданием или неполным)
Опять же, я не говорю конкретно о XF, а в целом обо всей структуре xamarin (xamarin.android, xamarin.ios, visual studio, mono, components ...).

Вот пример: примечания к выпуску xamarin ios

@melimion

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

Это абсолютно верно.
Вы добавили CollectionView. Результат - куча ошибок на Android, на iOS вообще невозможно использовать (Disposed исключение, исключение NSinconsistency и т. Д. И это если вы все делаете по официальным руководствам (!).
Вы добавили CarouselView - ошибки такие же.
Мы должны использовать устаревший, но более стабильный Listview.

Теперь, когда я вижу заголовок «мы добавили», я сразу же прокручиваю дальше.
А еще у вас есть другие элементы, например
Swipeview, Expander, в которых тоже много ошибок.
А еще есть, как писал выше человек, моно, визуальная студия со своими ошибками.

Отмените новые функции в 4.7-4.8, обратите внимание на исправления ошибок.
Разработка на Xamarin похожа на поиск обходных путей, временных решений.
Прошу прощения за мой плохой английский

Вчера проверил. Существует более 200 проблем, имеющих большое значение. Нет смысла выпускать новые функции, когда критические ошибки еще не исправлены. Я согласен с предыдущим предложением. Остановите новые функции. Найдите время, чтобы исправить и уменьшить количество проблем. Я застрял на 4.4, например, из-за проблемы. Представьте себе, что в этой ситуации гораздо больше людей. Стабильность и производительность на первом месте, если нет людей для инноваций и обслуживания, ИМХО.

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

Лично мне хотелось бы, чтобы больше усилий было вложено в MAUI, что звучит как разумный сброс архитектуры XF, а вторые по величине усилия были направлены на устранение серьезных ошибок. Добавление новых функций даже не попало бы в мой список - я бы предпочел добавить их, когда у нас будет лучшая платформа для их добавления.

@freever Полностью согласен!
Это не только сделает текущих разработчиков Xamarin более счастливыми, но и устранит эти ошибки для MAUI!

Я не знаю, будут ли исправлены эти ошибки здесь, в MAUI, или они будут исправлены в Xamarin.Forms.

Я чувствую, что @davidortinau раскрыл суть этой проблемы здесь

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

Я обновил описание его комментарием

Я действительно хочу подчеркнуть эту часть того, что он сказал еще раз для всех

мы тратим большую часть наших текущих спринтов на проблемы CollectionView, и мы предлагаем приостановить разработку функций в Xamarin.Forms 5, чтобы с сентября 2020 года по ноябрь 2021 года мы могли сосредоточить больше внимания на решении проблем.

PureWeen закрыл это 10 часов назад

Десятки разработчиков xamarin выразили свое мнение в этом тикете, и у меня нет ощущения, что их услышали.
К сожалению, вы только что доказали мою точку зрения

@PureWeen Этот выпуск касается не только количества ошибок. Они даже перечислены в балльной форме.

@ tranb3r

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

Чем вам не нравится комментарий

@ Happypig375

@pauldipietro обратился к человеку, опубликовавшему эту проблему, чтобы он мог начать решать эти проблемы напрямую с ним.

Суть этой проблемы в том, что XF имеет слишком много ошибок и игнорирует сообщество. Итак, мы замедляем новую разработку, чтобы больше сосредоточиться на существующих ошибках и открытых PR.

Если есть другие проблемы, помимо открытых ошибок, давайте откроем для них проблемы. Но эта проблема заключается в том, что в них слишком много открытых ошибок, и у нас есть план по их устранению.

С MAUI у нас должен быть максимально быстрый процесс исправления ошибок. Есть мысли о том, как улучшить?

Мы удаляем кучу устаревших аспектов из Form с помощью .NET Maui, и в этом году мы потратим этот год, прежде чем он будет сосредоточен на ошибках и открытых PR, чтобы мы могли быть более продуктивными с .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

Не могли бы вы указать мне на проблему, о которой вы говорите, чтобы я мог на нее взглянуть?

@PureWeen

Чем вам не нравится комментарий

Как упоминалось ранее, эта проблема касается не только количества ошибок в XF.

Если есть другие проблемы, помимо открытых ошибок, давайте откроем для них проблемы. Но эта проблема заключается в том, что в них слишком много открытых ошибок, и у нас есть план по их устранению.

Уже слишком много открытых вопросов !!! Какой смысл открывать новые, если их просто игнорировать ...

Например, одним из важных моментов, упомянутых ранее, является то, что команды Microsoft должны использовать xamarin при разработке приложений.
Вы слышите этот отзыв? Что нам делать, чтобы убедить вас в том, что это хорошая идея? Мы должны открывать для этого вопрос ???

Как упоминалось ранее, эта проблема касается не только количества ошибок в XF.

Давайте создадим для них разные задачи. Объединение нескольких вещей в одну проблему не будет продуктивным.

Какие еще комментарии здесь, которые не имеют ничего общего с открытыми ошибками / проблемами / проблемами хрупкости вокруг XF, вы хотите прояснить?

Например, одним из важных моментов, упомянутых ранее, является то, что команды Microsoft должны использовать xamarin при разработке приложений.
Вы слышите этот отзыв? Что нам делать, чтобы убедить вас в том, что это хорошая идея? Мы должны открывать для этого вопрос ???

Да, мы пытаемся убедить буквально всех использовать Xamarin

Мы много говорим с внутренними командами о выборе приложений, и это постоянное обсуждение. Многие из этих внутренних обсуждений также будут определять направление .NET Maui.

Я не уверен, что еще я могу прокомментировать по этому поводу. Здесь нет ничего особенного, что я могу сделать, чтобы помочь вам конкретно как пользователь.

@PureWeen Суть этой проблемы в том, что XF содержит слишком много ошибок и игнорирует сообщество. Итак, мы замедляем новую разработку, чтобы больше сосредоточиться на существующих ошибках и открытых PR.

Так что мы ожидаем немного более быстрого исправления ошибок в течение некоторого времени. Это хорошо, но не решает полностью эту проблему. Перевести XF из бета-версии в стабильную - очень большая задача, и ни одно быстрое решение или единая стратегия не помогут ее решить. Потребуются серьезные организационные, философские и архитектурные изменения. Я бы посоветовал:

1. Упростите репозиторий, чтобы упростить внесение и обзор вкладов. Новая архитектура средства визуализации может помочь, если она вытесняет XAML из ядра и обеспечивает более безопасный для типов подход к средствам визуализации.
2. Ставьте в приоритет исправление ошибок и чистый код над функциями. Учитывая, что культура Xamarin заключается в добавлении новых функций при игнорировании ошибок, лучший способ - полностью запретить новые функции до тех пор, пока не будет достигнут порог качества для существующих функций.
3. Разрешить критические изменения, которые исправляют ошибки и очищают код.
4. В полной мере используйте .Net, чтобы уменьшить количество ошибок. По возможности держите вещи внутри системы типов и применяйте NRT C # 8.
5. Сначала исправьте основные элементы управления , а затем оставшиеся элементы управления.
6. Освободите старые целевые ОС и старые редакторы, чтобы очистить репозиторий, упростить тестирование и освободить ресурсы для исправления ошибок.
7. Публично сообщайте о метрике ошибок. Это поможет сосредоточить внимание организации на ошибках. Поместите прогресс по ошибкам в первый раздел любого блога, посвященный обновлению.
8. Удалите функции, чтобы уменьшить размер репозитория и сделать его более удобным в обслуживании.

Наш опыт: мы используем только базовые представления XF, потому что не доверяем ничему другому. Метка, запись, кнопка, средство выбора, переключатель, DatePicker, слайдер, StackLayout, ScrollView, ContentView, Grid, ContentPage. Но даже тогда ошибки возникают и остаются месяцами. В XF так сложно вносить исправления, что вместо этого мы просто копируем и вставляем средства визуализации в наш код.

Упростите репозиторий, чтобы упростить внесение и обзор вкладов. Новая архитектура средства визуализации может помочь, если она вытесняет XAML из ядра и обеспечивает более безопасный для типов подход к средствам визуализации.

Это наш план. Я создал здесь проблему с заполнителем, за которой вы можете следить или предлагать свои предложения https://github.com/dotnet/maui/issues/147

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

Это в основном наш план.

Разрешить критические изменения, которые исправляют ошибки и очищают код.
В полной мере используйте .Net, чтобы уменьшить количество ошибок. По возможности держите вещи внутри системы типов и применяйте NRT C # 8.

Это постепенно наш план. Но важно понимать весь круг пользователей, которые используют наши продукты. Например, после того, как мы прекратили поддержку vs2017, здесь возникла эта проблема, которая получила массу комментариев от пользователей.
https://github.com/xamarin/Xamarin.Forms/issues/7602

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

Но мы все же последовательно предпринимаем шаги, чтобы быть готовыми к этому скачку. Например PR здесь
https://github.com/xamarin/Xamarin.Forms/pull/10937

Позволит мне запустить внутренний процесс CI для тестирования на C # 8 и другие бета-функции, так что, как только мы сможем сделать скачок, это будет легко сделать.

Сначала исправьте основные элементы управления, а затем оставшиеся элементы управления.
Освободите старые целевые ОС и старые редакторы, чтобы очистить репозиторий, упростить тестирование и освободить ресурсы для исправления ошибок.

Это наш план, как я уже упоминал выше

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

Изучая это. @samhouts запускает множество этих отчетов для нас каждый спринт, поэтому у нас есть представление обо всем, но мы лучше рассмотрим это для сообщества.

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

Это наш план с .net MAUI. Перед тем, как запустить наш план .NET MAUI, мы подготовили списки областей, которые можно сократить, чтобы повысить эффективность. Огромную часть этого будет выполнять рендерер.

Привет, в дополнение к упомянутым проблемам, есть много ошибок, связанных с языками справа налево. Кажется, что эти ошибки менее важны с точки зрения команды Xamarin Forms (вероятно, из-за меньшего использования языков справа налево, чем английский или другие языки слева направо. Правые языки), но отсутствие полной поддержки культур справа налево обескураживает и разочаровывает и фактически мешает разработчикам использовать XF в международных / многоязычных / справа налево приложениях.
Спасибо.

Следующие два месяца назад проблема: https://github.com/xamarin/Xamarin.Forms/issues/11166
Ошибка создана 22 июн.
PR открылся 25 июня.
Статус ошибки 17 августа: все еще не слито. Почему? ; (

@PawKanarek добро пожаловать в Xamarin. обычно они объединяют только исправления или Prs, сделанные командой. вот почему не рекомендуется вносить свой вклад в Xamarin. Считаю, что они сократили состав команды. всего 2-3 человека активно работают над проектом. если вам нужно быстрое исправление, создайте свои собственные пакеты xamarin nuget.

@EmilAlipiev Но на этот раз PR (для # 11166) был открыт членом команды Xamarin и до сих пор не был объединен xD

Если вы посмотрите наши примечания к выпуску и идеи GitHub, мы объединим множество PR от сообщества. На самом деле, я вижу ваше имя в последнем списке , @EmilAlipiev :)

Вы можете видеть, что за последний месяц 18 разных людей открыли 40 новых запросов на вытягивание . Запросы на извлечение должны быть полностью протестированы и рассмотрены, и с учетом того количества, которое мы получаем, мы должны определять приоритеты проблем с блокировкой и серьезных регрессий без каких-либо обходных путей.

Я знаю, что мы не всегда идеальны, но мы работаем над улучшением каждый день. Спасибо за терпение и за то, что оставались с нами. Мы сможем сделать это вместе!

@ 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, спасибо за ответ. 1-2 слияния в день - это крайне меньше. Я работаю над другим кроссплатформенным инструментом, и в прошлом месяце у них было 15 слияний в день, 455 слияний. Я все еще больше люблю Xamarin как инструмент, и я всегда готов внести свой вклад, но мое слияние заняло более 2 месяцев, и мне пришлось создать это слияние 3 раза с перебазированием из другой ветки.
Кроме того, на вашей стороне есть приоритетный вопрос. Люди отчаянно ищут исправления для основных инструментов, таких как ошибка Device.Idiom .. или ошибки CollectionView и т. Д.
Сегодня был действительно большой прогресс - 8 слияний. Но, честно говоря, ниже слияния меньше людей интересуют смахивания, градиентные кисти или темы и т. Д., Когда такие критические PR стоят в очереди в течение нескольких месяцев. Я считаю, что это самое большое разочарование

Любая открытая и проверенная ошибка в github должна быть исправлена ​​как можно скорее.

Это явно нереально; даже если Microsoft резко увеличила размер команды Xamarin.Forms.
Они говорят, что работайте умнее, а не усерднее (в этом случае это должно означать, что PR должны включать регрессионное тестирование, чтобы убедиться, что ошибки не появляются снова; однако, как и в любом другом случае, это тоже компромисс, потому что обзоры внесенных PR будет становиться все длиннее и сложнее).

Пожалуйста, исправьте больше ошибок, не добавляйте больше функций

Я тоже разделяю это мнение. Однако, строго говоря, план перехода MAUI <> Xamarin.Forms уже охватывает это: Xamarin.Forms перейдет только в режим исправления ошибок, а новые функции появятся только на Maui.

(в этом случае это должно означать, что PR должны включать регрессионное тестирование, чтобы убедиться, что ошибки не появляются снова; однако, как и в любом другом случае, это также компромисс, потому что обзоры предоставленных PR будут становиться все длиннее и сложнее).

Абсолютно. Это компромисс, с которым мы тоже боролись. У нас есть тысячи (!) Автоматизированных тестов, и мы запускаем их на нескольких устройствах. Проблема в том, что для их завершения требуются часы (в настоящее время около 4 часов на запуск на каждое устройство), и иногда, к сожалению, они немного нестабильны по любому количеству причин. Например, вчера я просто связался с одним из участников по поводу теста, который, по моему мнению, не прошел на законных основаниях, только для того, чтобы понять, что на самом деле он не прошел, потому что Chrome просил нас принять новые условия обслуживания. 🤦

Это приводит к большому количеству задержек, а это означает, что PR иногда может занять несколько дней только для прохождения тестов. Это на нас, и это проблема, которую нам нужно решить.

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

Что касается добавления новых функций и исправления ошибок ... как говорит @knocte , план перехода разработан с учетом этого. Наша цель - сделать .NET MAUI компактным, быстрым и надежным. В рамках этого мы оцениваем, какие функции на самом деле входят в основной проект и какие функции лучше подходят для нового набора инструментов сообщества, который по-прежнему поддерживается Microsoft, но в значительной степени поддерживается сообществом.

Пожалуйста, знайте, что мы всегда думаем о вас и ваших клиентах, когда вносим какие-либо изменения, и мы прислушиваемся к вашим отзывам.