バグレポートの7日後にPRがマージされた場合でも、7049の展開には1か月以上かかりました

また、プルリクエストを開くと、Xamarinの担当者が変更されたファイルを確認する時間を割くまで、リクエストが滞り続ける可能性があります。

うまくいけば、チームはPR +リリースプロセスに関するボトルネックのいくつかを取り除く計画を持っています。

また、プルリクエストを開くと、Xamarinの担当者が変更されたファイルを確認する時間を割くまで、リクエストが滞り続ける可能性があります。

そして、それを見てください。視認性の高い問題で言及された後、Xamarin.Formsチームの誰かが最終的に。

また、プルリクエストを開くと、Xamarinの担当者が変更されたファイルを確認する時間を割くまで、リクエストが滞り続ける可能性があります。

そして、それを見てください。視認性の高い問題で言及された後、Xamarin.Formsチームの誰かが最終的にxamarin / Xamarin.Forms＃7728に応答し

私はチームに共感します。 その多くの問題は、トリアージ/管理/修正するのは簡単ではありません。 そうは言っても、ボトルネックを取り除き、未解決の問題やPRを整理することに焦点を当てる必要があることは間違いありません。

同意しましたが、Xamarin開発のあらゆる側面で品質が常に問題になっています。 コンポーネント間の非互換性、VSでのビルドが機能しない、または新しいバージョンのフォームへの更新後にアプリがクラッシュするために、何度もイライラします。 ものはうまくいくはずです。 一部のコントロールまたはレイアウトは単に一緒にうまく機能しないため、3回目のレイアウトの再構築を強制されるべきではありません。

関連する点がいくつかあります

1）フォームで作業している人の数はわかりませんが、チームが小さすぎて、急速に増加している新しいバグやPRのペースに追いつくことができないようです。 フォームとマウイの間で注意を分割する必要があるため、これはさらに悪化するだけです。 チームがすぐに大幅に後押しされることを本当に望んでいます。

2）Microsoftが実際に独自のアプリでFormsを使い始めたら、本当に役に立ちます。 そして、私は単純なデモや会議アプリを意味するものではありません。 TeamsやOutlookのような実際のアプリを意味します。 これが間違っていれば嬉しいですが、ストアでMS Formsアプリを見つけることができず、このツイートのようなソースによるとhttps://twitter.com/safaiyeh/status/1219294459298344961彼らは主に反応しますネイティブ。

• MSが独自のテクノロジー（XF）を使用していない場合、なぜこれを行う必要があるのでしょうか。

• 複雑なアプリでFormsを内部的に使用することは、テストの追加レイヤーになる可能性があり、公開リリースにヒットする問題の数を減らす可能性があります。 さらに、Formsの操作は、彼らが私たちに言っているほど簡単ではないことがわかりました。

3）MSが、Win UI Xamlのような実績のある既存のソリューションを使用する代わりに、XF​​ Xamlの形式で車輪の再発明を常に試みているという事実に、別の問題があります。 彼らは、既存の機能の開発と、そのために導入されたバグの修正に時間を費やす必要があり、そうすれば、他の機能やバグ修正のための時間が少なくなります。

@Reveonに100％同意します
ああ、XamarinでVisualStudio for Windowsを使用することは、非常に苛立たしい経験であると言わざるを得ません。

彼らは未解決のブロッキングバグを追加し続けています...私はそれがどのように可能であるかさえ知りません（すべてのiOSデバイスビルドの破壊、プロビジョニングプロファイルの破壊、ジェスチャーレコグナイザーの破壊など...これらのようなバグはどのように本番環境に移行し、その後どのようになりますか？リリースビルドで修正されるまでに数週間または数か月かかりますか？わからない....）

そのためにRiderに切り替えましたが、今ではどこでもJetbrains製品を使用しています:)少なくともiOSとWindowsでまったく同じIDEを使用して、生産的に作業を続けることができます。

MAUIによってそのようなことが変わると確信しており、遅かれ早かれマイクロソフトは深刻なプロジェクトのためにMAUIを社内で使用し始めるでしょう。

別の証言：
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@EmilAlipiev ：

私はこの問題のために私のPRが1.5ヶ月間マージされるのを待っていました。 Iosにはすでに問題があり、Androidは2019年7月に修正され、誰もuwpに触れませんでした。 私は4月に修正し、レビューとマージを数回要求しました。 xamarinチームがどのように機能しているかは本当に迷惑です。 あなたは彼らが1日あたり1〜2のPRしかレビューしていないのを見ることができます。
＃10316

私はしばしばイライラしますが、「Xamarinはバグが多い」というのは厳しい発言です。 フラッターに5000以上の未解決の問題があることを確認すると、今日2000以上の未解決の問題があります。 数字はそれほど重要ではありません。 Xamarin.formsは、uwp（xboxを含む）、wpf、mac、gtk、tizenなどの他のクロスプラットフォームよりも多くのものを提供します。 したがって、たとえばWpfには多くの未解決の問題がありますが、これは私たちのほとんどにとって優先度が低くなっています。
Xamarin.formsのコアはios、android、uwpである必要がありますが、Xamarinチームはuwpを無視することがよくあります。

1. レイアウト、リストビュー、カルーセル、コレクションビュー、画像、マップ、ラベル、エディターなどのコア要素が必要です。これらにはバグがない必要があります。 それらを新しいリリースまたは更新する場合は、ショートッパーのバグがないことを確認する必要があります。 バグがある場合は、最大1週間以内に解決する必要があります。 しかし、Xamarinチームは、クールな機能を備えたクールな「4.5-4.6」をリリースしており（コミュニティの10％がこの素晴らしいツールを必要としているのは誰ですか？）、画像制御は壊れています。 問題は3月の初めに報告されましたが、今日まで解決されていません。 同じ「ネイティブアセンブリへのバンドル」が壊れています。 これらの重大な理由により、4.5および4.6にアップグレードすることはできません。 彼らは4.7で新しい機能を追加して開発を続けています。 私と私たちのほとんどは、バグが解決されたかどうかのリリースノートを監視しています。追加された機能については、もう読んでいません。
2. Xamarinチームはこれを理解する必要があります。 多くの人がXamarinを選択する最大の理由は「UWP」です。 私はフリーランサーです。 私は顧客に、なぜネイティブにバタバタしたり反応したりしないのかと尋ねます。 XamarinにはUWPがあるため、彼は言います。 UWPも欲しいです。 しかし、UwpはXamarin.formsでほとんどバグがあります。 彼らはCollectionViewを導入しました、それは本当に素晴らしいです、しかし1年以来それはそのバグが解決されていません。 私はそれを修正しました、誰もレビューしていません。 私はそれ以上の貢献をすることを思いとどまらせました。
3. Hotreloadがまったく機能していません。 私はツイッターですべての「キスキス」を読んだ。 私に何か問題があるか、他のツールを使用しているはずだと思っています。 多くの場合、hotreloadが更新されていないためです。 私はまだlivexamlなどのサードパーティツールを使用しています。独自のホットリロードを実行するための単純なコンソールアプリケーションも作成しました。 それは私に1日かかります。 Xamarinよりもはるかにうまく機能し、uwpでも機能します。 どうして彼らはそれを届けられないのでしょうか？ 彼らはlivereloadが機能していた。

4. 最も重要なポイント。 @Reveonが言ったこと。 xamarin.formsで動作する実際のエンタープライズアプリケーションが必要であり、実際の問題を検出するために新しいリリースで更新する必要があります。 彼らは「再現するのはそれほど難しいことではない」と不平を言う。 はい、この問題がtodoアプリではなく、エンタープライズアプリケーションでのみ発生する場合は非常に困難です。 同じUIを複製する必要があります。 あなたが理解するまでそれはあなたの日を要するかもしれません。 そのため、大規模なアプリケーションを持っている人がいることが非常に重要です。 twitch、youtube、twitterなどで見られるXamarin開発者のいずれかが、xamarin.formsを使用して大規模なアプリケーションを開発したことがあるかどうか本当に疑問に思っています。

5. オープンソース以外のツールを使用したくないのですが、何かを認める必要があります。私のアプリの50％以上がsyncfusionツールを使用しています。 Syncfusionがなければ、エンタープライズで動作するアプリケーションを入手するのは非常に難しいと思います。 xamarinにはないもの、またはxamarinバギーとは何かがすべて揃っています。 たとえば、ドラッグアンドドロップ、スワイプビュー、線形およびグリッドレイアウト、より優れた仮想化などを備えたsfListViewの代替品を何年も探していました。最後に、xamarinがCollectionViewとともに登場し、Listviewの「クールバージョン」として私たちの顔に投げました。それはバギーです。 Uwpでは機能しません。 多くの不足している機能。 課題内でCollectionViewを検索するだけで、数十になります。

私はまだXamarinがクロスプラットフォームに最適なツールであると信じており、建設的なフィードバックとしてこの問題を取り上げてくれることを願っています。

これまでのところ、素晴らしい建設的なコメント。 私はリストを読んでいて、他の開発者と同じように感じていました。 この問題は、Xamarin.Formsを使用してエンタープライズアプリを開発する私たちに共通しています。 バグの追跡と修正にはもっと注意が必要ですが、特に明確な点が1つあり、Xamarin.Formsで構築されたエンタープライズMSアプリケーションがない理由を何度も自問しました。 MSTeamsまたはその他。 答えが「Xamarin.Formsを使用して複雑または不可能にする方法」である場合、プラットフォーム全体を改善し、それらの問題を修正しようとする優れた内部洞察があります。 Xamarin / MAUIは、より多くの開発者がこの言葉をテストし、貢献し、広めることで確実に利益を得るでしょうが、これは双方向の道であるはずです。 繰り返しになりますが、私は文句を言いませんが、今年、来年、MAUIまたはXamarinで構築されたモバイルアプリケーションの素晴らしいMSリリースを見るのは非常に大きなことです。 また、開発者のフラストレーションや改善の可能性を確認し、クロスプラットフォーム開発を新しいレベルに引き上げます。

なぜなら、私は言及されました...

私は、AndroidとWindowsデスクトップ（WPF）間のクロスプラットフォームアプリケーションの小さなプロジェクトを主導しています。

たくさんのバグを見つけたので、ラウンドまたは修正する必要がありました。 現在、私は修正とパフォーマンスの改善のための内部プロジェクトを開始しています。なぜなら、私たちのソリューションを共有することは、この遅い進歩では不可能だからです。 締め切りもあります。

公式パイプラインにバグを持ち込むことは、私たちの小さなチームにとって本当に費用がかかるので、もっと注目を集めるのはいいこと

xamarinのwpf部分では、やるべきことがたくさんあります。 パフォーマンスが悪く、単純なバグの地獄です。 しかし、背後にある考え方と基盤は設定されています。 それがはるかに良いかもしれないので、現在の状態を見るのは悲しいです...

同意しましたが、Xamarin開発のあらゆる側面で品質が常に問題になっています。 コンポーネント間の非互換性、VSでのビルドが機能しない、または新しいバージョンのフォームへの更新後にアプリがクラッシュするために、何度もイライラします。 ものはうまくいくはずです。 一部のコントロールまたはレイアウトは単に一緒にうまく機能しないため、3回目のレイアウトの再構築を強制されるべきではありません。

関連する点がいくつかあります

1. フォームで作業している人の数はわかりませんが、チームが小さすぎて、急速に増加している新しいバグやPRのペースに追いつくことができないようです。 フォームとマウイの間で注意を分割する必要があるため、これはさらに悪化するだけです。 チームがすぐに大幅に後押しされることを本当に望んでいます。
2. Microsoftが実際に独自のアプリでFormsを使い始めたら、それは本当に役に立ちます。 そして、私は単純なデモや会議アプリを意味するものではありません。 TeamsやOutlookのような実際のアプリを意味します。 これが間違っていれば嬉しいですが、ストアでMS Formsアプリを見つけることができず、このツイートのようなソースによるとhttps://twitter.com/safaiyeh/status/1219294459298344961彼らは主に反応しますネイティブ。

• MSが独自のテクノロジー（XF）を使用していない場合、なぜこれを行う必要があるのでしょうか。
• 複雑なアプリでFormsを内部的に使用することは、テストの追加レイヤーになる可能性があり、公開リリースにヒットする問題の数を減らす可能性があります。 さらに、Formsの操作は、彼らが私たちに言っているほど簡単ではないことがわかりました。

1. MSが、Win UI Xamlのような実績のある既存のソリューションを使用する代わりに、XF​​ Xamlの形式で車輪の再発明を常に試みているという事実に、別の問題があります。 彼らは、既存の機能の開発と、そのために導入されたバグの修正に時間を費やす必要があり、そうすれば、他の機能やバグ修正のための時間が少なくなります。

私はあなたが言及した問題の多くに同意します。 Microsoftは、Xamarin Forms、iOS、またはAndroidを使用してエンタープライズアプリを作成する必要があります。 エンタープライズアプリの例が機能するようになったら、プロフェッショナルなアプリを作成するのがイライラすることは不満ではありません。

Xamarin Formsは、一度アプリを作成してどこでも機能したい人にとって、優れたクロスプラットフォームフレームワークです。 シンプルなアプリを作成する場合に最適です。 しかし、アニメーション、セグメント化されたタブ、データ仮想化、複雑なレイアウトなど、より多くの機能を備えたよりプロフェッショナルなアプリの作成を開始すると、機能を機能させるためにフレームワークとの戦いがますます進んでいます。 動作するはずの単純なことは明らかではないか、動作させるためにハックが必要であることがわかりました。

Xamarin Hot Reloadのような機能は、開発段階ではまだ時期尚早です。 たとえば、App.xamlまたはApp.xamlから参照されるリソースディクショナリでスタイルを変更すると、そこにスタイルとリソースが保存されます。HotReloadは、シミュレーター内のアプリのレイアウトを台無しにするか、クラッシュするアプリ。

Xamarinアプリを開発するとき、VisualStudioは非常にバグが多いことがわかりました。 たとえば、Androidプロジェクトをスタートアッププロジェクトとして選択し、それを使用してテストしてから、スタートアッププロジェクトとしてiOSプロジェクトに切り替えると、あらゆる種類の誤ったエラーが表示されます。 binまたはobjフォルダーを破棄しても役に立ちません。 VSを再起動する必要があります。 別の例では、アプリのデバッグ中にVSがMacへの接続をランダムに失います。 VSがフリーズします。 私は気性のタントラムを投げ、私の趣味とモバイル開発者としての私の人生に疑問を投げかけ、タスクマネージャーを使用してVSを強制的に殺します。 さらに、Visual Studioの将来のバージョンでは、以前のバージョンで修正されたバグが再導入されていることがわかりました。 最新バージョンがリリースされた後、以前のバージョンのVSをインストールする方法がわからないので、インストールします。 アンインストールしてインストーラーを使用して再インストールを試みることはできますが、常に最新バージョンがインストールされます。 これは、任意のバージョンをインストールできるNuGetパッケージとは異なります。

最後に、セグメント化されたタブコントロールがXamarinツールキットの一部ではないのはなぜですか？ セグメント化されたタブはほとんどどこでも使用されます。 非常に一般的なコントロールを使用するために、Syncfusionツールキットや別のツールキットを使用する必要はありません。

XamarinとVisualStudioを使用するこれらの開発者のフラストレーションの多くが解決されるまで、私が開発するプロのアプリでMAUIを使用することを採用するのは、緊張しています。 出てきたら遊んで実験します。 しかし、Microsoftが出てきて、単純なデモアプリを作成する代わりに、MAUIを使用してエンタープライズアプリを作成すると、自信がつきます。

XamarinフォームとMAUIロードマップについて誰かに教えてもらえますか？ それらは並行して維持されますか？ Xamarin Formsのサポートにハードストップはありますか？また、Microsoftは将来のVisual StudioアップデートでMAUIを徹底的に排除しますか？

ありがとうございました

@SunnyMukherjee FAQから、

Xamarin.Formsの将来は何ですか？

Xamarin.Formsの次のメジャーバージョンは2020年9月頃に更新され、.NETMAUIと.NET6のリリースを通じて更新されます。その後、Xamarin.Formsは12か月間優先サービスを受け続けます。

基本的に、Xamarin.Formsはバージョン5以降で強制終了されます。

@SunnyMukherjee FAQから、

Xamarin.Formsの将来は何ですか？

Xamarin.Formsの次のメジャーバージョンは2020年9月頃に更新され、.NETMAUIと.NET6のリリースを通じて更新されます。その後、Xamarin.Formsは12か月間優先サービスを受け続けます。

基本的に、Xamarin.Formsはバージョン5以降で強制終了されます。

2021年半ばまでに。 。 。 それまでにCovidが私を殺さなければ、MauiまたはXamarinFormsのどちらかがその仕事をします。

@SunnyMukherjeeあなたの痛みが聞こえます。 Xamarin.Formsは最初にリリースされてから使用しており、その後も使用されています。 MicrosoftはXamarin.Formsを作成せず、2018年にXamarinを購入しただけであることを忘れないでください。したがって、MAUIは、Xamarinをより良く書き直し、.net全体とシームレスに連携させるためのMicrosoftのプロジェクトです。 Xamarin.Formsの操作は簡単ではありません。これは、Xamarin.Formsの操作が簡単ではないためです。 多くの人が、UnoまたはFlutterが行ったことを実行し、コントロールを完全に作成する必要があると言っていますが、それはXamarin.Formsとは異なります。 これはネイティブ開発フレームワークであり、一般的な方法でネイティブコントロールを公開します。 これは簡単な作業ではありません。 Xamarin.Formsにも多くの問題がありましたが、同じアプリを複数の言語で作成する代わりにXamarin.Formsを使用することで節約できた時間は、全体として問題をはるかに上回ります。 さらに、コードの90％をバックエンドASP.Netコアプロジェクトと共有できるため、さらに価値があります。
マイクロソフトにMAUIに何を求めているかを知らせることは重要ですが、それは彼らにとって小さな仕事ではないことを理解する必要があります。MAUIが正しい方向への大きな一歩になることを願っています。
デモのMAUIの最近のビルドからのこのビデオを見て、ロードマップにどのように適合するか、また、Xamarin.Formsで何を実行してサポートするかについて説明します。
https://channel9.msdn.com/Events/Build/2020/BOD106?ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

ここを読んで、Xamarin.Formsの品質を向上させるためにここで何を学ぶことができるのか疑問に思っています。 @ Happypig375の元の質問に戻りたいと思います。

改善する方法について何か考えはありますか？

現在から.NETMAUIを出荷するまでの主な目標の1つは、基盤と出発点を改善することです。 このため、現在のスプリントの多くをCollectionViewの問題に費やしており、Xamarin.Forms 5で機能開発者を一時停止することを提案しているため、2020年9月から2021年11月まで、問題の解決に焦点を移す必要があります。

これはすべて、スプリントプロジェクトボードに表示されます。

要するに：

• コミュニティプルリクエストをより迅速に。

数日前にプルリクエストツリーをリベースしました。 レビューに時間がかかるのはなぜですか？

WPF-レンダラー、潜在的なバグのポイント：

• コントロールの測定/配置
• 論理/ビジュアル-チャイルドツリーが壊れています
• パフォーマンス

こんにちは@davidortinau 、これに取り組む良い方法は、誰かが完全に関与することに公に専念することだと思います：

• バグ問題のトリアージ
• PRレビューとマージを管理、ディスパッチ、プッシュします。

何かが遅すぎる場合、彼/彼女は私たちの連絡先になり、彼/彼女は何が起こっているのかを説明することができます。
さらに、法的な障害がない場合は、Twitchチャネルを作成して、誰かがバグを修正したり、オンラインでPRを確認したりできると便利です。 IHMO、これは外部の開発者の関心とコラボレーションに多大な影響を与える可能性があります。
これは、.NETMAUIフォームとXamarinフォームの両方に有効です。 しかし、たぶん私はただの夢想家です😄

Xamarin.Formsには、実行されているプラ​​ットフォームの数や、プラットフォームからの変更、または独自の開発による変更を考慮すると、多くのバグがあることにそれほど驚いていません。

しかし、私にとって驚くべきことは、リグレッションバグの数です。これは、以前に機能していた、または以前に修正され、次のリリースで壊れたものです。
私にとって、これは十分なテストが行​​われていないことの明らかな兆候です。 より厳格なテスト体制は、次のリリースにないいくつかの変更につながる可能性がありますが、率直に言って、信頼できない製品の汚名を避けるために、それらを早期にキャッチすることが本当に必要です。

Xamarin.Forms for MAUIからのレッスンとして、さらにテストを行いたいと思います。 バグのあるコードは、作成されたPRですぐに対処されるのではなく、長い道のりを要したため、報告された多くの問題やリソースの浪費を回避できました。

「コア機能」と「重大なバグ」と言ったとき。 これは私がこのような問題を意味する

フレームワークを改善するため。 追加したい：

独自のレンダラーを作成する可能性を高めます。 キーワードinternal避けてください。

Microsoftは、サンプルプロジェクトをGitHubに投稿するだけでなく、OneDriveやXamarin Forms、iOS、Androidを使用したXboxアプリなどのプロフェッショナルなエンタープライズアプリを作成し、開発者以外のユーザーが使用できるようにAppStoreに公開できます。 Microsoftは以前、VisualStudioをC ++からC＃およびWPFに移行することでこれを実現しました（その場合、顧客が開発者であることを認めています）。 それはマイクロソフトに私たちの問題点を伝え、それらが成功した場合、Xamarinで何でも可能であるという開発者コミュニティに大きな自信を与えるでしょう。

これに関する投稿があったことをうれしく思います。私は自分の欲求不満を評価したいと思います。 私は既存の問題への返信を投稿することに消極的であることがよくありますが、私をトリガーするのはBundleAssembliesに関連するこの問題です。 この影響の大きい問題が2か月以上続いた後も、Xamarinメンバーからの解決策、ステータス、またはパスフォワードが何であるかを明確に示すことはできません。

私はアジャイルスクラムチームを運営していますが、KPIはVelocity（実行された作業量）であることがよくあります。 時々、問題が特定の過熱レベルにエスカレートしたとき、私の最後の声明は常に「... [私たちの製品]の品質を向上させるためにここで何を学ぶことができるのか疑問に思っています。 （本当に）不快感はありませんが、それは私の上司や顧客をひいきにするためだけのものです。 そのような議論の文脈で私が言うとき、それは私または私の製品所有者が仕事に取り組んでいないか、私たちがまだ否定または最悪の状態にあることを意味するだけです、私たちは本当に何が起こっているのかわかりません。 （私から感覚を平手打ちした私たちの利害関係者の一人への称賛）

私を本当に悩ませているのは、回帰のバグと、問題に対する簡潔な応答/説明の欠如です。 すべてのXFリリースは何かを壊す傾向があります。 そして、それは明らかな何かを壊します-配置が間違っている、画像が表示されない、テキストの切り捨てが機能しないなど。 テストケースの半分は、これらのXF回帰をチェックすることだけです。 バカバカしい。 明らかに、XF内部テストに問題があります。 ショーストッパーのバグが認められた場合でも、その後にいくつかの新しいリリースが存在する可能性があります。 私たちがそれを使用できないとき、それらの新しいリリースのポイントは何ですか？ それらの新しいリリースをベータ版に入れるべきではありませんか？

これらすべてを言っても、私と私たちの利害関係者は、XFの「有毒な文化」に非常にうんざりしています。 これは、Windows 10がユーザーのファイルまたはブリックユーザーのシステムを削除する更新プログラムをリリースする方法と似ています（ただし、少なくともユーザーの応答と修正プログラムは迅速です）。 ここでのフラストレーションは、XFの機能の欠如ではなく、リリースの品質にあると思います。 XFがどのように品質を向上させることができるかについては？ オンラインで検索して、何百万もの結果を得ることができます。 そして、マイクロソフトの「品質保証」の理解を損なうことなく、ここからどこから始めればよいのかさえわかりません。 マイクロソフトは品質保証の方法を知っていると確信しています（これに関するマイクロソフトのホワイトペーパーを読んでいます）。 要約すると、担当者になります。 彼/彼女は、品質チェックを改善（または実装）するための責任、説明責任、およびコミットメントを必要としています。

XFに関して最も苛立たしいことは、私たちの貢献（それが新しいPR、新しい問題、あるいは単純な質問やフィードバックであるかどうか）がチームによって無視されたときだと思います。
チームはおそらく小さすぎます。 しかし、妥当な時間内に回答を提供することに専念する1人の人がいることは間違いなく役立ちます。

1つの良い例は、BundleAssembliesに関するこのリグレッションです（すでに数回言及されています）。
もう1つの良い例は、CollectionViewに関するこの問題です。

私にとってもう1つの懸念は、XFアプリは、もちろんXFの変更だけでなく、Mono、Visual Studio、Xamarin Framework、DotNet、さらには一部のMicrosoftライブラリの影響を受けることです。
それらのチームは社内でうまくコミュニケーションをとっていないと感じています。
私の意見では、Microsoftにアプリの内部でXFを使用させることは間違いなく役立ちます。

繰り返しになりますが、1つの良い例はこの回帰であり、根本的な原因は実際にはMonoとAndroidXにあります。
しかし、iOSアプリに影響を与えるdotnet拡張機能でこの問題に言及することもできますし、msalでこの問題にさえ言及することもできます。
そしてもちろん、ソースリンクに関して、ビジュアルスタジオでのこの問題。

ここの人々は私が詳細に言うつもりだったことのほとんどを言って素晴らしい仕事をしたので、私はそれを速くするつもりです

技術的な問題

• XFを使用すると、VisualStudioが1分あたり3回以上クラッシュします。
• 多くの基本的なコントロールが欠落しているか、またはそれらを想定どおりに形作るために一体が必要です。
• XFと言うときは、クロスプラットフォームフレームワークで最悪のパフォーマンスを言っているだけです。XFがネイティブのandroid / iosに取り組んでいると言っている人たちのためにはっきりさせておきます...そしてそれは難しいことです。 見てください！ 見てください！ 神の愛のために！ フラッター、RN、NativeScriptで...それらはすべて同じ目標を持っていますが、XFははるかに遅れています
• ホットリロードは、新しいプロジェクトを作成し、左側にデフォルトのテキストを作成してそれを作成した場合にのみ適切に機能します。
• すべてのリリースの例として、フラッターコミュニティの誰もが次のようになります：ああOMGは彼らがしたことはとてもクールです、一方、XF comは次のようになります：彼らが何を壊したか、または彼らが何を追加したかを見てみましょう。
• XFを使用した最初の旅は、一連の問題です。例としては、最近、Playstoreのすべてのアプリで共通のコントロールの1つを作成する必要がありました。これは、単純な下部のタブアイコンのみであり、アイコン付きのシェルを使用すると、マージンが大きくなります。醜くてみんなのように見える下部で、私は問題を作成しましたが、同様の問題が6か月以上前に対処されたことに気づきました...そして途中で修正はありません
• アプリは大丈夫だと思いますか？ アプリはありますか？ アプリ内購入や何らかのプレミアムサービスはありますか？ もちろんそうです。 だからあなたはグーグルペイとアップルペイのプラグインを探し始めますか？ それともペイペールでしょ？ 私はあなたに何かを言わせてください、ありません!!! XFの公式チームに尋ねると、彼らが何に反応するか知っていますか？ 彼らはあなたに2年前に更新なしで一人の男（私が尊敬している）によって作成された古い非公式のプラグインへのリンクを送ります、WTF（申し訳ありません）!!

技術的ではない

• 公式ドキュメントでさえ非常に貧弱ですが、彼らはtodoアプリレベルの機能とハウツーチュートリアルに取り組んでいます
• XFを使う前から嫌いでしたが、理由はわかりますか？ 誰もがMSでさえ使用しないと言っているのに、なぜFがそれを使用するのでしょうか。
• XFチームを支援するためにコミュニティが自分の時間と費用で行う問題とPRに対する応答が非常に遅い!!!

ソリューション

• XFチームは非常に小さいですが、マイクロソフトが自社製品をより良くするのに十分な人員を雇っていないのに、どうして巨大な会社ができるのでしょうか。 私と同じようにマイクロソフトをだましている才能は世界中のいたるところにあります！
• 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関連のバグを修正する必要がある人物だと思います。

ドキュメントについて：私は個人的には、リリースノートを除いてほとんど問題ないと思います。リリースノートは完全にf * d upです;）（常に遅れているか不完全です）
繰り返しになりますが、私はXFについて具体的に話しているのではなく、より一般的にはxamarinフレームワーク全体（xamarin.android、xamarin.ios、ビジュアルスタジオ、モノラル、コンポーネントなど）について話します。

次に例を示します。xamariniosリリースノート

@melimion

パフォーマンスを向上させる新機能を追加すると、それは素晴らしいことです。 しかし、これらの機能が使用できない場合、それは非常に残念です。

これは絶対に真実です。
CollectionViewを追加しました。 その結果、Androidでは多数のエラーが発生し、iOSでは一般的に使用できなくなります（破棄された例外、NSinconsistency例外など。これは、公式ガイド（！）に従ってすべてを実行した場合です。
CarouselViewを追加しました-エラーは同じです。
古いがより安定したリストビューを使用する必要があります。

さて、「追加しました」というタイトルが表示されたら、すぐにさらにスクロールします。
そして、あなたは他の要素も持っています、例えば
Swipeview、Expander、これにも多くのエラーがあります。
そして、その人が上で書いたように、独自のバグを持つモノラルのビジュアルスタジオがあります。

4.7-4.8の新機能をキャンセルし、バグ修正に注意してください。
Xamarinでの開発は、回避策や一時的な解決策を見つけるようなものです。
英語が苦手なことをお詫びします

昨日チェックしました。 影響が大きいとマークされた200を超える問題があります。 重大なバグがまだ解決されていない場合、新機能をリリースしても意味がありません。 私は前の提案に同意します。 新機能を停止します。 時間をかけて修正し、問題の数を減らしてください。 たとえば、問題が原因で4.4でスタックしています。 この状況で非常に多くの人々を想像してみてください。 イノベーションとメンテナンスを私見する人力がない場合は、安定性とパフォーマンスが最優先されます。

XF開発者の間で、既存のバグをクリアするためのエンジニアリング作業を行うのか、4.7以降で計画されている機能を追加するのかを確認するための何らかの調査が行われるのではないかと思います。 つまり、新しい機能自体が新しいバグを追加して、より多くのやり直しと遅延を引き起こします...古き良き時代の機能のフリーズが必要になることがあります。

個人的には、MAUIに最も力を入れたいと思います。これは、XFアーキテクチャの賢明なリセットのように聞こえますが、2番目に大きな努力は影響の大きいバグのクリアに費やされます。 新しい機能を追加することは私のリストに載ることさえありません-それらを追加するためのより良いプラットフォームがあるときに私はむしろそれらを追加したいと思います。

@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とバグにさらに焦点を合わせ、最終的には新しい.net6ベースの製品となる.netmauiに到達できるようにすることです。

@ Happypig375

@pauldipietroは、その問題を投稿した個人に

この問題の精神は、XFにはバグが多すぎて、コミュニティを無視することです。 そのため、既存のバグとオープンPRに重点を置くために、新しい開発を遅らせています。

未解決のバグ以外に他の問題がある場合は、それらの問題を未解決にしましょう。 しかし、この問題は未解決のバグが多すぎることに関するものであり、私たちはそれに対処する計画を持っています。

MAUIを使用すると、可能な限り高速なバグ修正プロセスが必要になります。 改善する方法について何か考えはありますか？

Form with .NET Mauiから多くのレガシーな側面を取り除き、今年は.NET Mauiでより生産的になるように、バグとオープンPRに重点を置く前に費やしています。

これは私たちのプロジェクトボードです

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

各スプリントに何を追加しているかがわかります
https://github.com/xamarin/Xamarin.Forms/projects/70

これが私たちのロードマップです
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
私たちは、私たちが取り組んでいることについて可能な限り透明になるように努めています

それらのリポジトリの問題がpingされたり、焦点が絞られたりした場合は、それらを一番上にバブルしようとしますが、それらのアルゴリズムが完全でない場合があります。

@ Amine-Smahiは、シェルのプロジェクトボードと、ブロッカーと見なされるものです。
https://github.com/xamarin/Xamarin.Forms/projects/54

あなたが言及している問題を指摘して、私がそれを見ることができるようにできますか？

@PureWeen

@davidortinauのコメントはどのようにあなたに足りないのですか？ 私が主張している主なポイントは、新しい機能の開発を遅らせて、オープンPRとバグにさらに焦点を合わせ、最終的には新しい.net6ベースの製品となる.netmauiに到達できるようにすることです。

前述のように、この問題はXFのバグの数だけではありません。

未解決のバグ以外に他の問題がある場合は、それらの問題を未解決にしましょう。 しかし、この問題は未解決のバグが多すぎることに関するものであり、私たちはそれに対処する計画を持っています。

すでに未解決の問題が多すぎます!!! あなたがそれらを単に無視するならば、新しいものを開くことのポイントは何ですか...

たとえば、前述の重要なポイントの1つは、Microsoftチームがアプリを開発するときにxamarinを使用する必要があるということです。
このフィードバックを聞きますか？ これが良い考えであることをあなたに納得させるために私たちは何をすべきですか？ そのための問題を開くことになっていますか？

前述のように、この問題はXFのバグの数だけではありません。

それらのためにさまざまな問題を作成しましょう。 複数のことを1つの問題にまとめることは、生産的ではありません。

XFに関する未解決のバグ/ prs /脆弱性の懸念とは何の関係もない、ここで他にどのようなコメントを明確にしたいですか？

たとえば、前述の重要なポイントの1つは、Microsoftチームがアプリを開発するときにxamarinを使用する必要があるということです。
このフィードバックを聞きますか？ これが良い考えであることをあなたに納得させるために私たちは何をすべきですか？ そのための問題を開くことになっていますか？

はい、文字通りすべての人にXamarinを使用するように説得しようとしています

私たちはアプリの選択について社内チームとよく話し合っており、それは継続的な議論です。 これらの内部の議論の多くは、.NETマウイの方向性も導きます。

これについて他に何をコメントできるかわかりません。 特にユーザーとしてあなたを助けるために私ができることは、ここではあまり実用的ではありません。

@PureWeenこの問題の精神は、XFにはバグが多すぎて、コミュニティを無視することです。 そのため、既存のバグとオープンPRに重点を置くために、新しい開発を遅らせています。

そのため、しばらくの間、バグ修正の速度がわずかに速くなると予想されます。 それは良いことですが、この問題に完全には対処していません。 XFをベータ品質から安定化することは非常に大きな作業であり、迅速な修正や単一の戦略ではこれを達成できません。 組織的、哲学的、およびアーキテクチャ上の大きな変更が必要になります。 私は提案します：

1. リポジトリを
2. 機能よりもバグ修正とクリーンコードを
3. バグを修正し、コードをクリーンアップする重大な変更を
4. バグを減らすために.Netを最大限に活用してください。 可能な限り型システム内に物事を保持し、C＃8NRTを採用します。
5. 最初に修正します。
6. Jettisonの古いターゲットOSと古いエディターは、リポジトリをクリーンアップし、テストを合理化し、バグ修正のためにリソースを解放します。
7. バグの測定基準について公開して報告します。 これは、組織をバグに集中させるのに役立ちます。 更新に関するブログの最初のセクションとして、バグの進捗状況を確認してください。
8. 機能を

私たちの経験：私たちは基本的なXFビューのみを使用します。これは、他のものが使用可能であるとは信頼していないためです。 Label、Entry、Button、Picker、Switch、DatePicker、Slider、StackLayout、ScrollView、ContentView、Grid、ContentPage。 しかし、それでも、バグが発生し、数か月間残ります。 XFに修正を加えるのは非常に難しいため、代わりにレンダラーをコピーしてコードに貼り付けるだけです。

リポジトリを簡素化して、投稿や投稿の確認を容易にします。 新しいレンダラーアーキテクチャは、XAMLをコアから置き換え、レンダラーによりタイプセーフなアプローチを提供する場合に役立つ可能性があります。

それが私たちの計画です。 ここでプレースホルダーの問題を作成しました。フォローしたり、提案を提供したりできますhttps://github.com/dotnet/maui/issues/147

機能よりもバグ修正とクリーンコードを優先します。 Xamarinの文化がバグを無視して新しい機能を追加することであることを考えると、最良の方法は、既存の機能の品質のしきい値に達するまで、新しい機能を完全に禁止することです。

これは主に私たちの計画です。

バグを修正し、コードをクリーンアップする重大な変更を許可します。
バグを減らすために.Netを最大限に活用してください。 可能な限り型システム内に物事を保持し、C＃8NRTを採用します。

これはゆっくりと私たちの計画です。 ただし、当社の製品を使用するユーザーの全範囲を理解することが重要です。 たとえば、vs2017のサポートを解除すると、この問題がポップアップし、ユーザーから大量のコメントが寄せられました。
https://github.com/xamarin/Xamarin.Forms/issues/7602

だから私たちはただジャンプすることはできません。 私は100％飛躍したいと思っていますが、人々を壊すことはできません。

しかし、私たちは一貫してこの飛躍に備えるための措置を講じています。 たとえば、ここのPR
https://github.com/xamarin/Xamarin.Forms/pull/10937

内部CIプロセスを実行して、C＃8やその他のベータ機能に対してテストできるようになるので、飛躍できるようになると、簡単に飛躍できるようになります。

最初に最も基本的なコントロールを修正し、次に残りのコントロールを修正します。
Jettisonの古いターゲットOSと古いエディターは、リポジトリをクリーンアップし、テストを合理化し、バグ修正のためにリソースを解放します。

それが私が上で述べたように私たちの計画です

バグの測定基準について公開して報告します。 これは、組織をバグに集中させるのに役立ちます。 更新に関するブログの最初のセクションとして、バグの進捗状況を確認してください。

これを調べます。 @samhoutsは、すべてのスプリントでこれらのレポートを多数実行しているため、すべての見通しがありますが、コミュニティに対してこれをより適切に調査します。

機能を削除してリポジトリのサイズを縮小し、保守しやすくします。

これは、.netMAUIを使用した計画です。 .NET MAUIプランを開始する前に、より効果的にするために削減できる領域のリストを用意しました。 これの大部分はレンダラーの作業になります。

こんにちは、前述の問題に加えて、右から左への言語に関連する多くのバグがあります。これらのバグは、Xamarin Forms Teamの観点からはそれほど重要ではないようです（おそらく、英語や他の左から左への言語よりも右から左への言語の使用が少ないためです）右言語）、しかし右から左への文化に対する完全なサポートの欠如は、落胆と失望であり、実際には開発者が国際/多言語/右から左へのアプリでXFを使用することを妨げています。
ありがとう。

次の2か月前の問題： https ：
バグは6月22日に作成されました。
PRは6月25日にオープンしました。
バグステータス8月17日：まだマージされていません。 どうして？ ;（

@PawKanarekXamarinへようこそ。 通常、それらはチームによって作成された修正またはPrsのみをマージします。 そのため、Xamarinに貢献することはお勧めできません。 チームのキャパシティが減ったと思います。 プロジェクトに積極的に取り組んでいるのは2〜3人だけです。 迅速な修正が必要な場合は、独自のxamarinnugetパッケージをビルドしてください。

@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お返事ありがとう
それに加えて、あなたの側に優先順位の問題があります。 人々は、Device.Idiom ..やCollectionViewのバグなどのバグなどのコアツールの修正を必死に探しています。
今日、これまでに合計8つのマージが実際に大きな進歩を遂げました。 しかし、マージの下で正直に言うと、そのような重要なPRが数か月間待ち行列にある場合、スワイプビュー、グラデーションブラシ、またはテーマなどに関心を持つ人は少なくなります。 これは私が信じる最大の欲求不満です

githubで開いている検証済みのバグは、できるだけ早く修正する必要があります

これは明らかに非現実的です。 MicrosoftがXamarin.Formsチームのサイズを劇的に増やしたとしても。
彼らは、より賢く、難しくはない、と彼らは言います（この場合、これは、バグが再発しないことを確認するために回帰テストを含めることをPRに要求することを意味するはずです;しかし、他の場合と同様に、これはトレードオフでもあります。 PRはより長く、より困難になります）。

より多くのバグを修正してください、より多くの機能を追加しないでください

これも私が共有する意見です。 ただし、厳密に言えば、MAUI <> Xamarin.Forms移行計画はすでにこれをカバーしています。Xamarin.Formsはバグ修正モードのみに移行し、新機能はMauiにのみ適用されます。

（この場合、これは、バグが再発しないことを確認するために回帰テストを含めることをPRに要求することを意味するはずです。ただし、他の場合と同様に、貢献したPRのレビューはより長く、より困難になるため、これもトレードオフです）。

絶対。 これも私たちが苦労してきたトレードオフです。 自動化されたテストは数千（！）あり、複数のデバイスで実行しています。 問題は、それらが完了するまでに数時間（現在、デバイスごとの実行ごとに約4時間）かかることです。残念ながら、さまざまな理由で少し不安定になることがあります。 たとえば、昨日、正当に失敗したと思ったテストについて寄稿者にpingを送信しましたが、Chromeが新しい利用規約への同意を求めていたため、実際には失敗していることに気付きました。 🤦

これは多くの遅延につながり、PRがテストに合格するためだけに数日かかる場合があることを意味します。 それは私たちにあり、それは私たちが解決する必要のある問題です。

幸い、私たちはこの問題に取り組んでいます。 私たちは、UIを実際に自動化するよりも、単体テストに似たプラットフォームレンダラーをテストする新しい方法を開発しています。これは、はるかに信頼性が高く、高速です。

新しい機能の追加とバグの修正に関しては...

私たちは変更を加える際に常にあなたとあなたの顧客を念頭に置いており、あなたのフィードバックに耳を傾けていることをご承知おきください。