Maui: 关于 Xamarin.Forms 中的 1675 个打开的错误

创建于 2020-05-25  ·  52评论  ·  资料来源: dotnet/maui

请阅读@davidortinau 的评论

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

通读这里我想知道我可以在这里学到什么来提高 Xamarin.Forms 的质量。 我很想回到@Happypig375的原始问题:

关于如何改进的任何想法?

从现在到发布 .NET MAUI,我们的主要目标之一是改善基础和起点。 出于这个原因,我们将当前的大部分 sprint 花费在 CollectionView 问题上,我们建议暂停 Xamarin.Forms 5 中的功能开发人员,以便我们从 2020 年 9 月到 2021 年 11 月将更多的注意力转移到问题解决上。

这在我们的 sprint项目板上都可以看到。

原始描述

众所周知,Xamarin.Forms 存在漏洞。 它目前有 1675 个未解决的错误,有望超过Mono 的 1676 个未解决的问题。 通过比较这些数字,很容易看出 Xamarin.Forms 比“历史上有问题的”mono 框架有问题。

现在 MAUI 的源代码是从 Xamarin.Forms 复制的,这意味着 MAUI 开始与 Xamarin.Forms 一样有缺陷。 每个人似乎都关注通过遵循 Flutter 使 MAUI 架构尽可能无错误,但是 Xamarin.Forms 错误修复非常缓慢的事实,即使对于影响很大的错误似乎也被忽略了。 例如

打开拉取请求仍然可能导致请求陷入困境,直到 Xamarin 的官员抽出时间查看更改的文件。

随着时间的推移,人们会开始依赖这个 bug,导致 bug 修复被认为是引入了一个新的 bug。

Xamarin.Forms 在 2015 年有问题Xamarin.Forms 在 2018 年有问题,如果缓慢修复错误,Xamarin.Forms 将在 2021 年 MAUI 发布时仍然有问题。

对于那些在紧迫的期限内工作并且需要浪费时间寻找变通方法并应用它们的人来说,这简直是不可接受的。

对于 MAUI,我们应该有一个尽可能快的错误修复过程。 关于如何改进的任何想法?

最有用的评论

同意,质量一直是 Xamarin 开发各个方面的问题。 很多时候我发现自己很沮丧,因为组件之间不兼容,无法在 VS 中构建,或者我的应用程序在更新到新版本的 Forms 后崩溃。 东西应该只是工作。 我不应该被迫第三次重建我的布局,因为某些控件或布局根本不能很好地协同工作。

我看到几个相关的点

1) 我不知道有多少人在使用 Forms,但在我看来,团队太小,无法跟上新错误或 PR 的快速增长步伐。 这只会变得更糟,因为他们将不得不在 Forms 和 Maui 之间分散注意力。 我真的希望团队尽快得到实质性的推动。

2) 如果 Microsoft 开始在他们自己的应用程序上实际使用 Forms,那真的会有所帮助。 我指的不是简单的演示或会议应用程序。 我的意思是真正的应用程序,如 Teams 或 Outlook。 如果我在这个上错了,我会很高兴,但我没有设法在商店中找到任何 MS Forms 应用程序,并且根据此推文之类的一些来源https://twitter.com/safaiyeh/status/1219294459298344961他们主要使用反应本国的。

  • 这确实没有发出好的信号,因为如果 MS 不使用他们自己的技术 (XF) 那么我们为什么要使用?

  • 在复杂的应用程序内部使用 Forms 可能是额外的测试层,并且可以减少影响公开发布的问题的数量。 此外,他们可以看到使用 Forms 并不像他们告诉我们的那么容易

3) 我看到另一个问题是,MS 一直试图以 XF Xaml 的形式重新发明轮子,而不是使用已经证明的和现有的解决方案,如 Win UI Xaml。 他们必须投入时间开发已经存在的功能并修复由此引入的错误,然后用于其他功能和错误修复的时间就会减少。

所有52条评论

即使在错误报告后 7 天合并 PR,7049 也花了 1 个月的时间才推出

打开拉取请求仍然可能导致请求陷入困境,直到 Xamarin 的官员抽出时间查看更改的文件。

希望团队有一个计划来消除围绕 PR + 发布过程的一些瓶颈。

打开拉取请求仍然可能导致请求陷入困境,直到 Xamarin 的官员抽出时间查看更改的文件。

看看那个,在高可见性问题中被提及后,Xamarin.Forms 团队中的某个人终于回应了xamarin/Xamarin.Forms#7728

我对团队感同身受。 许多问题不容易分类/管理/修复。 话虽如此,肯定需要专注于消除瓶颈并减少未解决的问题和 PR。

同意,质量一直是 Xamarin 开发各个方面的问题。 很多时候我发现自己很沮丧,因为组件之间不兼容,无法在 VS 中构建,或者我的应用程序在更新到新版本的 Forms 后崩溃。 东西应该只是工作。 我不应该被迫第三次重建我的布局,因为某些控件或布局根本不能很好地协同工作。

我看到几个相关的点

1) 我不知道有多少人在使用 Forms,但在我看来,团队太小,无法跟上新错误或 PR 的快速增长步伐。 这只会变得更糟,因为他们将不得不在 Forms 和 Maui 之间分散注意力。 我真的希望团队尽快得到实质性的推动。

2) 如果 Microsoft 开始在他们自己的应用程序上实际使用 Forms,那真的会有所帮助。 我指的不是简单的演示或会议应用程序。 我的意思是真正的应用程序,如 Teams 或 Outlook。 如果我在这个上错了,我会很高兴,但我没有设法在商店中找到任何 MS Forms 应用程序,并且根据此推文之类的一些来源https://twitter.com/safaiyeh/status/1219294459298344961他们主要使用反应本国的。

  • 这确实没有发出好的信号,因为如果 MS 不使用他们自己的技术 (XF) 那么我们为什么要使用?

  • 在复杂的应用程序内部使用 Forms 可能是额外的测试层,并且可以减少影响公开发布的问题的数量。 此外,他们可以看到使用 Forms 并不像他们告诉我们的那么容易

3) 我看到另一个问题是,MS 一直试图以 XF Xaml 的形式重新发明轮子,而不是使用已经证明的和现有的解决方案,如 Win UI Xaml。 他们必须投入时间开发已经存在的功能并修复由此引入的错误,然后用于其他功能和错误修复的时间就会减少。

我 100% 同意@Reveon
哦,我不得不说将 VisualStudio for Windows 与 Xamarin 一起使用是一种非常令人沮丧的体验。

他们不断添加突出的、阻塞的、错误的……我什至不知道这是怎么可能的(比如破坏所有 ios 设备构建、破坏配置文件、破坏手势识别器……像这样的错误如何进入生产然后需要数周或数月才能在发布版本中修复?不知道......)

我为此切换到 Rider,现在我到处都在使用 Jetbrains 产品:) 至少我可以使用在 iOS 和 Windows 中完全相同的 IDE,并继续高效地工作。

我相信随着 MAUI 这些事情会改变,微软迟早会开始在内部使用 MAUI 进行严肃的项目

另一个见证:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@埃米尔阿里皮耶夫

我一直在等待我的PR在 1.5 个月内为此问题合并。 Ios 已经存在问题,而 android 已于 2019 年 7 月修复,没有人接触 uwp。 我在 4 月修复并多次请求审查和合并。 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% 的人需要这个花哨的工具?),并且图像控制已损坏。 问题是在 3 月初报告的,直到今天仍未解决。 同样的“捆绑到本机程序集”被破坏。 由于这些关键原因,我无法升级到 4.5 和 4.6。 他们不断开发 4.7,添加新功能。 我和我们中的大多数人都关注发行说明是否解决了我们的错误,我什至不再阅读添加了什么功能。
  2. Xamarin 团队必须了解这一点。 许多人选择 Xamarin 的最大原因是“UWP”。 我是自由职业者。 我问我的客户为什么不颤动或做出原生反应? 他说是因为 Xamarin 有 UWP。 我也想要 UWP。 但是 Uwp 在 Xamarin.forms 中主要存在问题。 他们引入了 CollectionView,它真的很棒,但一年以来它一直没有解决这个错误。 我修好了,没人评论。 我不鼓励做任何进一步的贡献。
  3. Hotreload 根本不起作用。 我在 twitter 上读到所有“kisskiss”hotreaload 有多棒。 我想我应该有问题,或者他们使用其他工具。 因为经常hotreload 不更新。 我仍在使用 livexaml 等 3rd 方工具。我什至创建了一个简单的控制台应用程序来执行我自己的热重载。 它花费我 1 天。 比 Xamarin 好得多,甚至适用于 uwp。 他们怎么能不送呢? 他们让 livereload 工作。
  4. 最重要的一点; @Reveon提到了什么。 他们需要一个真正的企业应用程序与 xamarin.forms 一起工作,他们应该用新版本更新它以检测真正的问题。 他们抱怨“提供repro 并不难”。 是的,如果这个问题只发生在您的企业应用程序上,而不是在待办事项应用程序上,那将是非常困难的。 您需要尝试复制相同的 ui。 它可能会花费您的时间,直到您弄清楚为止。 这就是为什么有人拥有大型应用程序非常重要。 我真的想知道我们在 twitch、youtube、twitter 等上看到的那些 Xamarin 开发人员是否曾经使用 xamarin.forms 开发过大型应用程序。

  5. 我不得不承认,虽然我不喜欢使用非开源工具,但我 50% 以上的应用程序都使用了同步融合工具。 如果没有 Syncfusion,我认为很难获得企业级应用程序。 他们拥有 xamarin 没有或 xamarin 越野车的一切。 例如,我多年来一直在寻找具有拖放、滑动视图、线性和网格布局、更好的虚拟化等功能的 sfListView 替代品。 最后 xamarin 推出了 CollectionView,他们把它作为 Listview 的“酷版”扔到了我们的脸上,但后来是它越野车。 不适用于 Uwp。 许多缺失的功能。 只需在问题中搜索 CollectionView,你就会得到几十个。

我仍然相信 Xamarin 是跨平台的最佳工具,我希望他们将这个问题作为建设性的反馈。

到目前为止,伟大而有建设性的评论。 我正在阅读列表,感觉和其他开发人员一样。 这些问题在我们这些使用 Xamarin.Forms 开发企业应用程序的人中很常见。 错误跟踪和修复需要更多关注,但特别是,有一点很清楚,我多次问自己为什么没有使用 Xamarin.Forms 构建的企业 MS 应用程序。 MS Teams 或任何其他。 如果答案是:使用 Xamarin.Forms 变得复杂或不可能,那么有一个很好的内部洞察力来改进整个平台并尝试解决这些问题。 Xamarin/MAUI 肯定会随着更多开发人员的测试、贡献和传播而获益,但这应该是一条双向的道路。 再说一次,我不是在抱怨,但在今年、明年看到使用 MAUI 或 Xamarin 构建的移动应用程序的优秀 MS 版本将是巨大的。 还要检查开发人员的挫折或可能的改进,并将跨平台开发提升到一个新的水平。

因为,有人提到我...

我为 Android 和 Windows 桌面 (WPF) 之间的跨平台应用程序领导了一个小项目。

我们发现了很多错误,我们必须进行一轮或修复。 目前,我开始了一个修复和性能改进的内部项目,因为共享我们的解决方案是不可能的。 我们也有死线。

对于我们这个小团队来说,在官方管道中引入 bug 真的很昂贵,所以得到更多关注会很好,也许你从社区中得到更多。

在 xamarin 的 wpf 部分有很多事情要做。 性能很差,而且是一堆简单的错误。 但背后的想法和基础已经确定。 看到目前的状态很难过,因为它可能会更好......

同意,质量一直是 Xamarin 开发各个方面的问题。 很多时候我发现自己很沮丧,因为组件之间不兼容,无法在 VS 中构建,或者我的应用程序在更新到新版本的 Forms 后崩溃。 东西应该只是工作。 我不应该被迫第三次重建我的布局,因为某些控件或布局根本不能很好地协同工作。

我看到几个相关的点

  1. 我不知道有多少人在 Forms 上工作,但在我看来,团队太小,无法跟上新错误或 PR 的快速增长步伐。 这只会变得更糟,因为他们将不得不在 Forms 和 Maui 之间分散注意力。 我真的希望团队尽快得到实质性的推动。
  2. 如果 Microsoft 开始在他们自己的应用程序上实际使用 Forms,那将非常有帮助。 我指的不是简单的演示或会议应用程序。 我的意思是真正的应用程序,如 Teams 或 Outlook。 如果我在这个上错了,我会很高兴,但我没有设法在商店中找到任何 MS Forms 应用程序,并且根据此推文之类的一些来源https://twitter.com/safaiyeh/status/1219294459298344961他们主要使用反应本国的。
  • 这确实没有发出好的信号,因为如果 MS 不使用他们自己的技术 (XF) 那么我们为什么要使用?
  • 在复杂的应用程序内部使用 Forms 可能是额外的测试层,并且可以减少影响公开发布的问题的数量。 此外,他们可以看到使用 Forms 并不像他们告诉我们的那么容易
  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 时遇到的许多问题得到解决。 当它出来时,我会玩和试验它。 但如果微软出来并使用 MAUI 制作企业应用程序而不是制作简单的演示应用程序,我会更有信心。

有人可以启发我们有关 Xamarin Forms 和 MAUI 路线图的信息吗? 它们会并行维护吗? Xamarin Forms 支持是否有硬性限制,Microsoft 是否会在未来的 Visual Studio 更新中将 MAUI 推入我们的喉咙?

谢谢

@SunnyMukherjee从常见问题解答中,

Xamarin.Forms 的未来是什么?

Xamarin.Forms 的下一个主要版本将在 2020 年 9 月左右,并通过 .NET MAUI 和 .NET 6 的发布继续更新。此后,Xamarin.Forms 将继续获得优先服务 12 个月。

基本上,Xamarin.Forms 将在第 5 版之后终止。

@SunnyMukherjee从常见问题解答中,

Xamarin.Forms 的未来是什么?

Xamarin.Forms 的下一个主要版本将在 2020 年 9 月左右,并通过 .NET MAUI 和 .NET 6 的发布继续更新。此后,Xamarin.Forms 将继续获得优先服务 12 个月。

基本上,Xamarin.Forms 将在第 5 版之后终止。

到 2021 年年中。 . . 如果在那之前 Covid 没有杀死我,那么 Maui 或 Xamarin Forms 都可以完成这项工作。

@SunnyMukherjee我听到了你的痛苦。 自从 Xamarin.Forms 首次出现以来,我一直在使用它,并且从那时起它就一直在使用。 请记住,微软并没有创建 Xamarin.Forms,他们只是在 2018 年购买了 Xamarin。因此,MAUI 是微软的项目,旨在将其重写为更好并使其与整个 .net 无缝协作。 使用 Xamarin.Forms 并非微不足道,因为它必须做的事情并非微不足道。 很多人都说他们应该做 Uno 或 Flutter 所做的事情并完全自己制作控件 - 但这与 Xamarin.Forms 是相反的。 它是一个本机开发框架 - 以一种通用的方式公开本机控件。 这不是一个小任务。 我也有很多关于 Xamarin.Forms 的问题,但总的来说,使用它而不是用多种语言编写相同的应用程序节省的时间远远超过了麻烦。 此外,能够与后端 ASP.Net 核心项目共享 90% 的代码使其更有价值。
虽然让微软知道我们想要在 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,我们的主要目标之一是改善基础和起点。 出于这个原因,我们将当前的大部分 sprint 花费在 CollectionView 问题上,我们建议暂停 Xamarin.Forms 5 中的功能开发人员,以便我们从 2020 年 9 月到 2021 年 11 月将更多的注意力转移到问题解决上。

这在我们的 sprint项目板上都可以看到。

简而言之:

  • 更快地处理社区拉取请求。

几天前我重新调整了拉取请求树的基础。 为什么审核需要这么长时间?

WPF-Renderer,潜在错误点:

  • 测量/排列控件
  • 逻辑/视觉子树坏了
  • 表现

@davidortinau ,我认为解决这个问题的一个好方法是公开让某人完全参与:

  • 错误问题分类
  • 管理、调度和推动 PR 审查和合并。

如果事情进展太慢,他/她将成为我们的联系人,他/她可以解释发生了什么。
此外,如果存在非法律障碍,如果我们能有一个 Twitch 频道,然后有人在那里修复错误或在线审查公关,那就太棒了。 IHMO,这可能会对外部开发人员的兴趣和协作产生巨大影响。
这对 .NET MAUI 和 Xamarin Forms 都有效。 但也许我只是一个梦想家😄

考虑到 Xamarin.Forms 在其上运行的平台数量以及来自平台或自身开发的更改,我对 Xamarin.Forms 有很多错误并不感到惊讶。

令我惊讶的是回归错误的数量,之前工作或之前修复的东西,然后在下一个版本中中断。
对我来说,这是测试不够的明显迹象。 更严格的测试制度可能会导致一些更改不会出现在下一个版本中,但坦率地说,为了避免产品不可靠的污名,尽早发现它们确实是必要的。

更多的测试是我希望从 Xamarin.Forms for MAUI 中吸取的教训。 它可以避免大量报告的问题和浪费资源,因为有问题的代码花费了很长时间,而不是立即通过创建的 PR 来解决。

当我说“核心功能”和“关键错误”时。 这就是我的意思,像这样的问题。 这现在超级烦人。 我在一周前发布了一个版本,但实际上并不知道这个问题。 我想知道为什么应用程序保留率急剧下降。 想象一下,我主要是非英语人士,西班牙语或德语用户打开应用程序,由于这个错误,它是英语的。 尽管我的应用程序已翻译成这些语言,但他会立即卸载它。 这个错误可能会发生,但它是在装载前报告的? 为什么没有修复。 甚至 Appcenter 和 Azure Pipelines 也有这个错误。

完善框架。 我想补充:

提高编写自己的渲染器的可能性。 避免使用关键字internal

Microsoft 不仅可以在 GitHub 上发布示例项目,还可以使用 Xamarin Forms、iOS 或 Android 创建专业的企业应用程序,例如 OneDrive 或 Xbox 应用程序,并将其发布到 App Store,以便开发人员以外的其他人可以使用它。 微软之前已经通过将 Visual Studio 从 C++ 迁移到 C# 和 WPF(在这种情况下授予客户是开发人员)来完成它。 这将告诉微软我们的痛点,如果他们成功,它将给开发者社区带来巨大的信心,相信 Xamarin 一切皆有可能。

我很高兴有关于此的帖子,我想权衡一下我的挫败感。 我经常是在发帖回复现有的问题,被动的,但什么触发我的是这个问题,相对于BundleAssemblies ; 在这个高影响问题发生 2 个多月之后,我仍然没有明确的迹象表明 Xamarin 成员的解决方案、状态或前进的道路是什么。

我管理敏捷 Scrum 团队,KPI 通常是速度(完成的工作量)。 有时,当我们将问题升级到某个激烈程度时,我的结束语总是“......我想知道我可以在这里学到什么来提高“[我们的产品]的质量。 没有冒犯(真的),但这只是为了光顾我的老板或我们的客户。 当我在那种讨论环境中这么说时,它只会意味着我或我的产品负责人不能胜任这份工作,或者我们处于拒绝或最糟糕的状态,我们真的不知道发生了什么。 (感谢我们的一位利益相关者,他让我失去了理智)

真正让我烦恼的是回归错误以及对该问题缺乏任何简洁的响应/解释。 每一个 XF 版本都容易破坏某些东西; 它打破了一些明显的东西 - 对齐错误,图像不显示,文本截断不起作用等等。 我们一半的测试用例只是为了检查这些 XF 回归; 这很荒谬。 显然,XF 内部测试有问题。 即使确认了一个显示阻止错误,仍然可以有几个后续的新版本; 当我们不能使用这些新版本时,它的意义何在? 那些新版本不应该进入您的 Beta 版吗?

说了这么多,我和我们的利益相关者对 XF 的“有毒文化”感到非常厌倦。 这就像 Windows 10 可以发布删除用户文件或砖用户系统的更新(但至少他们的响应和修补程序是快速的)。 我相信我们在这里感到沮丧的不是 XF 中缺少功能,而是发布的质量。 至于XF如何提升画质? 您可以在线搜索并获得数百万条结果; 我什至不知道从哪里开始,而不是傲慢地破坏微软对“质量保证”的理解。 我确信微软知道如何进行质量保证(嘿,我阅读了微软的白皮书)。 这归结为负责人; 他/她需要责任、问责和承诺来改进(或实施)质量检查。

我认为关于 XF 最令人沮丧的事情是当我们的贡献(无论是新 PR、新问题,甚至是简单的问题或反馈)被团队忽略时。
团队可能太小了。 但是让一个人在合理的时间内致力于提供答案肯定会有所帮助。

一个很好的例子是关于 BundleAssemblies 的回归(已经多次提及)。
另一个很好的例子是关于 CollectionView 的这个问题

我担心的另一个问题是,XF 应用程序当然会受到 XF 变化的影响,但也会受到 Mono、Visual Studio、Xamarin Framework、DotNet 甚至一些 Microsoft 库的影响。
我感觉这些团队在内部没有很好的沟通。
在我看来,让 Microsoft 在其应用程序内部使用 XF 肯定会有所帮助。

同样,一个很好的例子是回归,其根本原因实际上是 Mono 和 AndroidX。
但我也可以提这个问题在DOTNET扩展冲击iOS应用,甚至这个问题在社会事务和劳工部。
当然,这个问题Visual Studio 中,关于源链接。

这里的人做得很好,详细地讲了我要说的大部分内容,所以我要快点

技术问题

  • 使用 XF 时,Visual Studio 崩溃超过 3 次/分钟。
  • 缺少许多基本控件,或者需要像他们应该的那样塑造它们。
  • 当你说 XF 时,你只是在说性能最差的跨平台框架,让我清楚地告诉人们说 XF 处理原生 android/ios ......而且很难。 只是看看! 敬请期待! 为了上帝的爱! 在 flutter、RN、NativeScript……他们都有着相同的目标,但 XF 远远落后
  • 只有当您创建一个新项目并在左侧设置默认文本时,热重载才有效,仅此而已,然后您自己!
  • 例如,在每个版本中,flutter 社区中的每个人都像:哦,天哪,他们所做的太酷了,另一方面,XF com 就像:让我们看看他们破坏了什么或他们添加了什么,只有 10% 的 com 需要!
  • 使用 XF 的开始是一系列的麻烦,一个例子是:最近我不得不在 Playstore 上的所有应用程序中制作一个通用控件,它只是一个简单的底部选项卡图标,使用带有图标的外壳只有很大的余量在底部看起来很丑,和每个人一样,我创建了一个问题,只是注意到一个类似的问题在 6 个月前已经解决了......而且没有解决方法
  • 想想一个应用程序好吗? 任何应用程序? 它是否有应用内购买或某种高级服务? 当然可以。 所以你开始寻找谷歌支付和苹果支付的插件吗? 甚至贝宝对吗? 让我告诉你一件事,没有!!! 当你问 XF 官方团队时,你知道他们会怎么回答吗? 他们向您发送了一个链接,指向一个人(我尊重)2 年前创建的一个过时的非官方插件,没有更新,WTF(抱歉)!!

不是技术

  • 哦,来吧,即使官方文档也很差,他们解决了待办事项应用程序级别的功能和操作教程
  • 我什至在使用 XF 之前就讨厌它,知道为什么吗? 每个人都说即使是 MS 也不用,那你为什么要使用 F 呢?
  • 社区对问题和 PR 的响应非常缓慢,这些问题和 PR 是社区利用自己的时间和费用来帮助 XF 团队的!!!

解决方案

  • XF 团队非常非常小,微软怎么能不雇佣足够多的人来让自己的产品变得更好? 全球各地都有和我一样热爱微软的人才!
  • XF 应该在发布之前解决高层次的问题,它只能表明团队是多么不成熟,就像只是在乎的人...
  • Microsoft 大多数并且有义务将 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 相关的错误。

关于文档:我个人认为基本上没问题,除了发行说明,它们完全是 f * d up ;)(总是迟到或不完整)
再说一次,我不是专门谈论 XF,而是更一般地说整个 xamarin 框架(xamarin.android、xamarin.ios、visual studio、mono、components...)。

这是一个示例: xamarin ios 发行说明

@melimion

当您添加可提高性能的新功能时 - 这太棒了! 但是当这些功能无法使用时,那是非常令人失望的。

这是绝对正确的。
您已经添加了一个 CollectionView。 结果是在 Android 上出现一堆错误,在 iOS 上它通常无法使用(已处理异常、NSinconsistency 异常等。如果您按照官方指南进行所有操作(!)。
您添加了 CarouselView-错误是相同的。
我们必须使用过时但更稳定的 Listview。

现在,当我看到标题“我们添加”时,我立即进一步滚动。
你还有其他元素,例如
Swipeview,Expander,其中也有很多错误。
然后,正如上面那个人所写的那样,有自己的错误的单声道视觉工作室。

取消4.7-4.8的新特性,注意bug修复。
在 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 年 9 月到 2021 年 11 月将更多的注意力转移到问题解决上。

PureWeen 已于 10 小时前关闭

数十名 xamarin 开发人员在这张票中表达了他们的意见,我没有听到他们的感觉。
可悲的是,你刚刚证明了我的观点

@PureWeen这个问题涵盖的不仅仅是错误数量。 它们甚至以点的形式列出。

@tranb3r

我认为关于 XF 最令人沮丧的事情是当我们的贡献(无论是新 PR、新问题,甚至是简单的问题或反馈)被团队忽略时。

@davidortinau的评论对你来说有什么不足? 我要说的主要观点是我们正在放慢新功能的开发速度,以便我们可以更多地关注开放 PR 和错误,然后最终到达 .net maui,这将是我们基于 .net 6 的新产品

@Happypig375

@pauldipietro 联系了发布该问题的个人,以便他可以开始更直接地与他们解决这些问题。

这个问题的精神是XF的bug太多,无视社区。 因此,我们正在放慢新的开发速度,以更多地关注现有错误和公开 PR

如果在未解决的错误之外还有其他问题,让我们为这些问题打开问题。 但是这个问题是关于他们有太多开放的错误,我们有一个计划来解决这个问题。

对于 MAUI,我们应该有一个尽可能快的错误修复过程。 关于如何改进的任何想法?

我们正在使用 .NET Maui 从 Form 中去除大量遗留方面,今年我们将在重点关注错误和开放 PR 之前花费,以便我们可以使用 .NET Maui 提高工作效率

这是我们的项目板

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

您可以看到我们在每个 sprint 中添加的内容
https://github.com/xamarin/Xamarin.Forms/projects/70

这是我们的路线图
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
我们尽量对我们正在做的事情保持透明

如果这些 repos 上的问题被 ping 或高度关注,我们会尝试将它们放到顶部,但有时这些算法并不完美。

@Amine-Smahi 这是 shell 的项目板以及我们所看到的阻止程序
https://github.com/xamarin/Xamarin.Forms/projects/54

你能指出我所指的问题,以便我看一看吗?

@PureWeen

@davidortinau的评论对你来说有什么不足? 我要说的主要观点是我们正在放慢新功能的开发速度,以便我们可以更多地关注开放 PR 和错误,然后最终到达 .net maui,这将是我们基于 .net 6 的新产品

如前所述,这个问题不仅仅涉及 XF 中的错误数量。

如果在未解决的错误之外还有其他问题,让我们为这些问题打开问题。 但是这个问题是关于他们有太多开放的错误,我们有一个计划来解决这个问题。

已经有太多未解决的问题了!!! 如果你只是忽略它们,打开新的有什么意义......

例如,前面提到的重点之一是微软团队在开发应用程序时应该使用 xamarin。
你听到这个反馈了吗? 我们应该怎么做才能让您相信这是个好主意? 我们应该为此打开一个问题吗???

如前所述,这个问题不仅仅涉及 XF 中的错误数量。

让我们为这些创建不同的问题。 将多个事情处理成一个问题不会有成效。

这里还有哪些与围绕 XF 的开放性错误/prs/脆弱性问题无关的其他评论,您想澄清一下吗?

例如,前面提到的重点之一是微软团队在开发应用程序时应该使用 xamarin。
你听到这个反馈了吗? 我们应该怎么做才能让您相信这是个好主意? 我们应该为此打开一个问题吗???

是的,我们试图说服每个人都使用 Xamarin

我们与内部团队就应用程序的选择进行了很多讨论,这是一个持续的讨论。 许多这些内部讨论也将指导 .NET Maui 的方向。

我不确定我还能对此发表什么评论。 这里没有太多可操作的,我可以做些什么来专门帮助您作为用户。

@PureWeen这个问题的精神是 XF 有太多的错误,而忽略了社区。 因此,我们正在放慢新的开发速度,以更多地关注现有错误和公开 PR

因此,我们预计在一段时间内修复错误的速度会稍快一些。 这很好,但并没有完全解决这个问题。 将 XF 从 beta 质量提升到稳定是一项非常艰巨的任务,没有快速修复或单一策略可以实现这一目标。 这将需要重大的组织、哲学和架构变革。 我会建议:

  1. 简化存储库,使其更容易贡献和审查贡献。 如果新的渲染器架构从核心取代 XAML 并为渲染器提供更类型安全的方法,它可能会有所帮助。
  2. 优先考虑错误修复和清理代码而不是功能。 鉴于 Xamarin 的文化是在忽略错误的同时添加新功能,最好的方法是完全禁止新功能,直到满足现有功能的质量阈值。
  3. 允许修复错误和清理代码的
  4. 充分利用.Net来减少bug。 尽可能将内容保留在类型系统内,并采用 C# 8 NRT。
  5. 首先修复最基本的控件,然后是其余控件。
  6. 抛弃旧的目标操作系统和旧的编辑器,以清理存储库、简化测试并释放资源以修复错误。
  7. 公开报告错误指标。 这将有助于将组织重点放在错误上。 在任何关于更新的博客中,将错误进展作为第一部分。
  8. 删除功能以减小存储库的大小,使其更易于维护。

我们的经验:我们只使用基本的 XF 视图,因为我们不相信任何其他可用的东西。 标签、条目、按钮、选择器、开关、DatePicker、滑块、StackLayout、ScrollView、ContentView、网格、ContentPage。 但即便如此,错误还是会出现并持续数月之久。 修复 XF 非常困难,我们只是将渲染器复制并粘贴到我们的代码中。

简化存储库,使其更容易贡献和审查贡献。 如果新的渲染器架构从核心取代 XAML 并为渲染器提供更类型安全的方法,它可能会有所帮助。

这就是我们的计划。 我在这里创建了一个占位符问题,您可以关注或提供您的建议https://github.com/dotnet/maui/issues/147

优先考虑错误修复和清理代码而不是功能。 鉴于 Xamarin 的文化是在忽略错误的同时添加新功能,最好的方法是完全禁止新功能,直到满足现有功能的质量阈值。

这主要是我们的计划。

允许修复错误和清理代码的破坏性更改。
充分利用.Net来减少bug。 尽可能将内容保留在类型系统内,并采用 C# 8 NRT。

这就是我们的计划。 但了解使用我们产品的全部用户范围很重要。 例如,一旦我们打破了 vs2017 支持,这里就会弹出这个问题,收到了大量用户的评论
https://github.com/xamarin/Xamarin.Forms/issues/7602

所以我们不能只是跳槽。 我 100% 愿意采取这一飞跃,但我们不能只是打破人们。

但我们始终采取措施为这一飞跃做好准备。 例如这里的公关
https://github.com/xamarin/Xamarin.Forms/pull/10937

将允许我运行内部 CI 流程来测试 C# 8 和其他 beta 功能,以便一旦我们能够实现飞跃,它将是一个轻松的飞跃。

首先修复最基本的控件,然后再修复其余控件。
抛弃旧的目标操作系统和旧的编辑器,以清理存储库、简化测试并释放资源以修复错误。

这就是我上面提到的我们的计划

公开报告错误指标。 这将有助于将组织重点放在错误上。 在任何关于更新的博客中,将错误进展作为第一部分。

调查此事。 @samhouts每次冲刺都会为我们运行大量这些报告,因此我们对所有事情都有看法,但我们会更好地向社区展示这一点。

删除功能以减小存储库的大小,使其更易于维护。

这是我们与 .net MAUI 的计划。 在我们启动 .NET MAUI 计划之前,我们准备了可以减少的区域列表,以便更有效。 其中很大一部分将是渲染器工作。

嗨,除了提到的问题,还有许多与从右到左语言相关的错误。从 Xamarin Forms 团队的角度来看,这些错误似乎不太重要(可能是因为从右到左语言的使用比英语或其他从左到右的语言少正确的语言),但缺乏对从右到左文化的全面支持,令人沮丧和失望,实际上阻止开发人员在国际/多语言/从右到左应用程序中使用 XF。
谢谢。

接下来两个月大的问题: https :
错误创建于 6 月 22 日。
PR 于 6 月 25 日开业。
错误状态 8 月 17 日:仍未合并。 为什么? ;(

@PawKanarek欢迎来到 Xamarin。 通常他们只合并团队所做的修复或 Prs。 这就是为什么不鼓励为 Xamarin 做出贡献的原因。 我认为他们降低了团队能力。 只有 2-3 人积极参与该项目。 如果您需要快速修复,请构建您自己的 xamarin nuget 包。

@EmilAlipiev但是这次 PR(对于#11166)是由 Xamarin 团队的成员打开的,但仍未合并 xD

如果您查看我们的发行说明和 GitHub 见解,我们会合并来自社区的大量 PR。 事实上,我在最新的名单上看到了你的名字, @EmilAlipiev :)

您可以看到,在过去一个月中, 18 个不同的人打开了 40 个新的拉取请求。 拉取请求必须经过全面测试和审查,并且根据我们收到的数量,我们必须优先考虑阻塞问题和重大回归,而没有解决方法。

我知道我们并不总是完美的,但我们每天都在努力改进。 感谢您的耐心和对我们的支持。 我们可以一起做这件事!

@hamiddd1980你会很高兴知道我们在过去几个月里在 RTL 上做了很多工作。 我希望它可以改善您的体验!

@samhouts请记住,您不是 Xamarin 的最终产品。 我们不仅需要耐心,还需要大量的人力和金钱。 github 中任何公开和验证的错误都应该尽快修复,因为它会以技术债务、愤怒和与客户不必要的紧张关系的形式产生滚雪球效应。

请修复更多错误,不要添加更多功能。 稳定性大于功能。 您仍有 1,590 个经过验证的错误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 次合并。 但老实说,在合并之下,很少有人对滑动视图、渐变画笔或主题等感兴趣。 这是我认为最大的挫折

image

github 中任何打开和验证的错误都应尽快修复

这显然是不现实的; 即使 Microsoft 显着增加了 Xamarin.Forms 团队规模。
他们说,更聪明,而不是更努力地工作(在这种情况下,这应该意味着要求 PR 包括回归测试以确保错误不会再次出现;但是,与任何事情一样,这也是一种权衡,因为对贡献的评论PR 会变得更长更难)。

请修复更多错误,不要添加更多功能

这也是我分享的一个观点。 但是,严格来说,MAUI<>Xamarin.Forms 过渡计划已经涵盖了这一点:Xamarin.Forms 将过渡到仅错误修复模式,而新功能将仅登陆 Maui。

(在这种情况下,这应该意味着要求 PR 包括回归测试以确保错误不会再次出现;但是,与任何事情一样,这也是一种权衡,因为对贡献的 PR 的审查会变得越来越长,越来越难)。

绝对地。 这也是我们一直在努力的权衡。 我们有数千个 (!) 自动化测试,并且我们在多个设备上运行它们。 问题是它们需要数小时(目前每台设备每次运行大约需要 4 小时)才能完成,不幸的是,由于各种原因,它们有时会有点不稳定。 例如,我昨天刚刚向贡献者发送了一个我认为合法失败的测试,结果发现它实际上失败了,因为 Chrome 要求我们接受新的服务条款。 🤦

这会导致很多延迟,这意味着 PR 有时可能需要数天才能通过测试。 这取决于我们,这是我们需要解决的问题。

幸运的是,我们正在解决这个问题。 我们正在开发一种测试平台渲染器的新方法,它更像是单元测试,而不是实际自动化 UI,它更可靠、更快速。

至于添加新功能与修复错误……正如@knocte所说,过渡计划的设计考虑到了这一点。 我们的 .NET MAUI 目标是精简、快速和可靠。 作为其中的一部分,我们正在评估哪些功能实际上属于核心项目,哪些功能更适合新的社区工具包——它仍然有微软的支持,但在很大程度上得到了社区的支持。

请注意,我们在进行任何更改时始终将您和您的客户放在心上,并且我们会听取您的反馈。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

sim756 picture sim756  ·  16评论

PureWeen picture PureWeen  ·  21评论

mhrastegary77 picture mhrastegary77  ·  3评论

probonopd picture probonopd  ·  50评论

handicraftsman picture handicraftsman  ·  4评论