開発者のコ​​ミュニティであるあなたから本当に話を聞く必要があるので、この会話をハミングさせましょう！

まず、

私は私の考えのいくつかを共有し、いくつかの愚かな質問をし、そしていくつかのうまくいけばあまりリードしない質問をするつもりです。 Xamarin.Formsのプログラムマネージャーとして、私には手がかりがないように聞こえるような方法で質問しなければならないことがよくあります（時々私にはありません）が、実際にはあなたからのことを聞く必要がありますあなたの口に言葉を入れます。

この提案には私が気に入っていることがあります。私が多くの人と話している問題のいくつかにどのように対処できるかがわかり、解決に向けて取り組んでいます。

予約もあります。

ここでは、シェルの概念と開発者の経験についての一般的な考え方をいくつか紹介します。

アプリエクスペリエンス

適切に構造化され、適切な要素を使用する完全なアプリエクスペリエンスを実現するために、ほとんど労力をかけずに、デフォルトで優れたものにするための明確な道筋を示します。

このアプローチを使用してアプリケーションをトップレベルで説明すると、次のようになります。

• すべてのプラットフォームで同じように見えることをテーマにしたアプリ
• マテリアルデザイン（この場合）はデフォルトでパターン化されています
• 構成で有効になった最新のナビゲーションパターン
• iOS、Android、UWPで同じように見えるようにエントリやボタンをカスタマイズするのに労力を費やす必要はありませんか？

それは正確ですか？ 私が強調すべき他の利点は？

App代わりにMaterialShellます。 これから利益を得るには、新しいトップレベルのアプリケーションパラダイムを学習/採用する必要がありますか？

アプリに入ると、 ContentPage土地に戻りますよね？ しかし、私のButtonとEntryはすべて、マテリアルファイドできれいです。 それでもOnPlatformなどを別のプラットフォームで異なるように外観（または動作）を分岐させることはできますか？

既存のアプリからこの「シェル」を使用するまでの移行パスはどのようになりますか？ 新しいMaterialShellを紹介し、アプリの構造と外観をどのようにしたいかを説明し、それを実行して新しい良さを確認しますか？

カスタマイズ

Flyoutまたはメニュー項目の外観が気に入ったが、デザイナーのコンプに合わせて調整する必要がある場合、どのようなオプションがありますか？ どの時点で、「うーん、これをすべて自分でロールする必要がありました」と言って、持っているものを標準のXamarin.Formsアプリ構造に移動しますか？

MaterialShellを完全に放棄しなければならない場合、そのスタイリングの良さをすべて失い、iOSとAndroidおよびUWPの間でEntryまったく異なって見える状態で（今日のように）始めたところに戻りますか？ ？ したくないです。

私が期待している転換点があります。 このアプローチを使用してすばやく作業を開始した後、いくつかの制限にぶつかり、オプションを検討する必要があります。 それらは何であり、どの時点でMaterialShellを使用しないほうがよいでしょうか？

問題

この最初のコメントを、読んでいるすべての人へのいくつかの質問で締めくくります。

• この提案が対処しようとする問題は明確に定義されていますか？
• それはあなたが共有する問題ですか？
• この仕様を読んで、以前のプロジェクトで直面したどのような問題が解決すると思いますか？

可能であれば、スクリーンショット/デザイン画像はさらに良くなるでしょう。

これもチェックしてください：

http://www.noesisengine.com/webgl/Samples.Buttons.html

@jassmithアイデア全体が画像として提示されていたら

私の質問は

• タブレットのサポート、さまざまなレイアウトに適応するアプリの応答性については触れられていません。
• 現在のモデルから新しいモデルへの移行は困難ですか？ アプリ開発者の観点とXamarinForms寄稿者の観点から。
• プラットフォームの詳細を尊重せずに、ほとんどのアプリが単一のUIを必要とすることに同意します（同じUIの概念を実現するために、カスタムレンダラーの量を作成する必要があるため）。新しい方向では、Xamarin.Formsを引き続き開発するように、既存の機能がすべて削除されます。プラットフォーム固有のUIを備えたアプリ、または全員が新しい標準に強制されます。
• レンダラーの概念はMaterialShell内に引き続き存在しますか
• iOSでは、これをこのようにレンダリングしたいと実際に言うことができますか？ Flutterには、Androidで動作するCupertino Styles（apple UI）と、iOSで動作するAndroidUIがあります。 Xamarinフォームはどの方向に移動しますか。 開発者は、フラッターが現在提供しているそのような機能を備えていますか？

これには、フローティングラベル/プレースホルダーやエラーメッセージをサポートするためのTextInputLayoutに似たものも含まれますか？ はいの場合、 Bindingを拡張して、wpfと同様の 'ValidateOnDataErrors`を含める必要があると思います。

ここでこれの私の実装を参照してください
https://github.com/XamFormsExtended/Xfx.Controls/blob/develop/src/Xfx.Controls/XfxBinding.cs

また、MaterialShellでShellを拡張して、iOSのルックアンドフィール用のHumanInterfaceShellを作成できるようにする必要があるのではないかと思います。

@ChaseFlorellも私のコメントになりそうだった。 素材は素晴らしいですが、特定のUIのニーズに合わせて独自のシェルを作成したい場合は別のことです。

@ davidortinau 、 @ jassmith 、

この仕様をまとめて、フィードバックを提供していただきありがとうございます。

この提案が対処しようとする問題は明確に定義されていますか？

はい。 ナビゲーションシステムはXamarinFormsで完全に開発されていないため、ナビゲーションシステムを完成させる方法、または完全に回避する方法については、制限のない問題があります。

それはあなたが共有する問題ですか？

はい。

この仕様を読んで、以前のプロジェクトで直面したどのような問題が解決すると思いますか？

私はそれが問題を解決するとは思わないと言ってこの質問に答えるつもりです。 私たちの特定の問題は、現在のナビゲーションシステムが十分に硬くないということではなく、硬すぎるということです。 私たちにとって最も明確な例はTabbedPageです。 TabbedViewビューはないため、アプリにタブが必要な場合は、TabbedPageを使用する必要があります。 したがって、画面全体をTabbedPageで占有する必要があり、独自のボタンや、画面に配置したいその他のコントロールにスペースを使用することはできません。 私の推奨事項は、ページの機能をさらに上位のレイヤーに移動するのではなく、ページの機能をページの外に移動してビューに移動することでした。

FloatingMenuやFlyoutBehaviorのようなものは、ナビゲーションがXamarin.Formsシステムにさらにハードコーディングされ、ソフトウェア開発者からさらなる制御が奪われることを意味するため、私を怖がらせます。 より標準化されたアプローチを持つことにはある程度の価値がありますが、それは間違いなくコストがかかります。

私たちは常に、Silverlight、WPF、UWPなどの他のXAMLベースのテクノロジーに取り組んできました。 これらのテクノロジーでは、ナビゲーションがどのように機能するかをより多く定義できる、はるかにオープンエンドなアプローチがあります。 最近、UI / UXコンサルタントを雇いました。 彼はXFの癖に気づいていなかった。 ソフトウェアの機能に基づいていくつかの画面を作成するように彼に依頼しました。 TabbedViewがないなどの理由で、彼が推奨したものの広い範囲を実装できませんでした。 ナビゲーションを簡単にするのではなく、このフレームワークによって、UX / UIデザイナーから提供されたデザインの実装が実際に難しくなるのではないかと心配しています。

もう1つ言いたいのは、このフレームワークは他のXAMLプラットフォームでは前例のないものに見えるということです。他のプラットフォームと互換性のない新しいフレームワークを提供するのではなく、プラットフォーム全体で標準化を提供することを優先する必要があります。 現在、Silverlight、Xamarin.Forms、およびWPFの3つのプラットフォーム用に構築しています。 必要なのは、これらのプラットフォーム間で標準化して、偏差を増やすのではなく、減らすことです。

@dylanberry 、

特定のUIのニーズに合わせて独自のシェルを作成したい場合は、別のことです。

はい。 これが私の懸念です。 各アプリには独自のユースケースがあり、剛性が高いほど難しくなる可能性があります。これらの実装は簡単ではありません。

この懸念もあります： //github.com/xamarin/Xamarin.Forms/issues/2452#issuecomment -380991817

上記をエコーし​​、ジェスチャとポインタがどのように機能するかを尋ねます。

一般的なコメントとして、システムに追加されるコードの行ごとに、バグのあるコードが追加される可能性が3回以上あります。 Xamarinフォームには、修正が必要なバグがすでにたくさんあります。 コードが増えると、バグが追加される可能性が飛躍的に高まります。 より多くのバグがあります。 XFチームは、コードベースのサイズを増やすのではなく、減らすように取り組むべきだと感じています。 コードベースを減らすことが、バグが発生する可能性を減らす唯一の方法です。

既存のバグを修正するのではなく、なぜ新しいものを再発明し、最初にすべてが堅実であることを確認するのですか？

私にとっては触れられていますが、ナビゲーションはXamarin Formsの最大の障害であり、過去3年間で最も心痛を引き起こしました。

ナビゲーションは3つのプラットフォームすべてで一貫しておらず、MasterDetailパターンにより、ハンバーガーで多くの問題が発生し、ページをモーダルにプッシュする必要があります。その後、追加できないため、カスタムナビゲーションバーを実装する必要がありますが、Androidではアニメーションがひどく見えます（ MDで）。

• 多くの場合、ナビゲーションバーのコンテンツをオプトアウトして独自のContentViewで上書きできることが理想的です。 PlatformSpecificsは元々、ツールバーアイテムの配置を可能にするものとして動員されていましたが（私がブライアンと話していたときはさかのぼります）、限られた用途であることが判明しました。

• ページポップアニメーションなどのフレームワークのものをオーバーライドする機能

提案されているものの多くは非常に便利なようです。特定のページでマテリアルシェルを使用でき、アプリ全体ではない限り、コードは非常に便利です。 これは確かに私たちが使用するものです。現在、私はUX担当者に「XamarinFormsの制限です」と言い続けています（以前の役割で行ったように）。 あえて言うと、以前にフォームアプリのスタイルを設定したことのあるUXの観点からフィードバックを得る必要があります。 XamlCのようにオプトインする必要があります。

名前はわかりませんが、FlexShellの方が理にかなっています...しかし、Flexboxができました（要求したことはありませんが...申し訳ありませんが、David、自分自身を助けることができませんでした😄）

また、これはテーマが一種の死んでいることを意味しますか？ とにかくそれらを使用したことはありません。

@mackayn

これは確かに私たちが使用するものです。現在、私はUX担当者に「XamarinFormsの制限です」と言い続けています（以前の役割で行ったように）。

OKですが、完全に新しい実装を作成するのではなく、現在の実装を修正または改善する方が理にかなっています。これにはバグや制限もあります。 そこには次のように書かれています。

MaterialShellは、ある時点で意見の分かれるAPIです。」

真剣に、Xamarinフォームはいくつの異なる方向に進むことができますか？ XFチームは、少なくともAndroidとiOSの現在のXF実装を修正し続けることがほとんどできませんが、これはどうでしょうか。 バグ修正、XAMLプレビューの修正、パフォーマンスについてはどうですか？

クロスプラットフォームのソリッドブラシとグラデーションブラシのシンプルでありながら非常に便利なサポートを追加するという提案で誰かが開いたチケットがありましたが、 @ jassmithの応答は問題があるというものでした。 しかし今、このチケットは同じことを提案しています....それはもう問題ではないのですか？ 図に行く

@opcodewriter

はい、私は昨年、たとえばPrismチームを阻むナビゲーションの奇妙さがあり、問題を解決することができなかったと言ってきました。

今のところ建設的なフィードバックを提供しようとしていますが、Xamarin Formsはその進化の重要な時期にあります。このAPIは、アプリ全体のアプローチではなく柔軟な方法で実装されている場合、多くの問題点に対処できます。

@jassmithこれは、XFがシェルに対して（ネイティブコントロールの代わりにレンダリングエンジンを使用して）Flutterアプローチを採用することを意味しますか？

皆さん、昨日、ジェイソンと私はこの仕様を改善する方法について話し合いました。私たちは大規模な更新を行う予定です。これをさまざまな問題に分割しています。

上記の感情のいくつかをエコーし​​たいと思います：もちろんあなたが無限のリソースを持っていない限り、私たちが持っているものを改善してみましょう、そしてそれを目指してください😉

ListViewの修正（これがまだ正しく機能しないとは信じがたい）、CheckBox、RadioButtonなどのコントロールの実装、ブラシサポート（SolidColorBrush、GradientBrush）の実装、ページに基づいてポップアップを表示する機能など、まだ取り残されていることがたくさんあります。またはContentView、バグの修正（透過ビューについて報告された最近のバグを参照）、パフォーマンス、ツールなど。

なぜあなたは新しいことを始めたいのですか?????

@TonyHenriqueうん写真は素晴らしいだろう。 残念ながら、私はアーティストではなく、自分の参照用に使用している画像の権利を所有していません。 設計チームのメンバーが、仕様に合った適切な画像を作成するのを手伝ってくれることを願っています。

@muhaym

• タブレットのサポート。 レイアウトがタブレットに適応していることを確認することを目的としています。 もちろん、これはコンテンツページ内のレイアウトのケースをカバーするつもりはありません。それは別の機能です。 主に私は新しいVSMでそれを処理します。
• ほとんどの場合、ContentPagesを適切な場所に配置し、新しいナビゲーションの概念に適応するだけです。 私はそれが常に些細なことになるとは言いませんが、それも衰弱させるべきではありません。
• 絶対に機能を削除することはありません。 実際、私はSpecを更新して、MaterialShellの機能の一部を欠いているが、それ以外はプラットフォーム固有のUIバージョンのShellであるShell基本クラスを含めるように取り組んでいます。
• はい。 図面を追加すると、図面の処理方法がわかっているレンダラーが変更されます。
• はい。 階層の任意のレベルで使用されるレンダラーを交換できます。 レンダラーは、リソースディクショナリの特別なキーで設定されたテンプレートによって変更されるだけです。 これらのテンプレートを好きなように変更したり、nullを設定して無効にしたりできます。

@ChaseFlorellいいえ。ただし、仕様に修正を加えたい場合は、提案を

@dylanberry基本クラスは、それほど簡単にはなりません。 DrawingTemplatesを変更するほど簡単ではありません。 最適なパフォーマンスを得るために、これのMaterialShellの側面をプラットフォーム固有のコードに実装するつもりです。

@ RichiCoder1ジェスチャがここに表示されますが、要点は、サブリージョンジェスチャを含むビューがCommandableSpan APIの一部として表示され、ジェスチャを含む描画もサポートするように拡張されることです。 ただし、一般的には、ジェスチャーを使用せず、ネイティブバックエンドに入力を処理させることをお勧めします。 これは、現時点ではMaterialShell仕様とは無関係であり、Drawing仕様に属しており、詳細を説明します。 長いものと短いものがDrawingTemplateの理由です。これは、レンダラーがスライダーを構成する方法を知っている複数の図面を持ち、入力処理をネイティブバックエンドで引き続き処理できるようにするSliderDrawingTemplateを含めることができるためです。 これは、これを強制されることを意味するのではなく、レンダラーを可能な限り高速にするためのオプションのことです。

@mackayn Transitions / Segue APIが登場し、まもなくここに到着するはずです。 私はまだ私の最初の提案の命名のいくつかを考えています。 それは確かにフェーズ1にあるページ遷移のみでフェーズに入るものになるでしょう。しかし、それはあなたがフレームワークアニメーションをオーバーライドすることを可能にします。 オプトインについて。 シェルはアプリケーションのルートである必要があり、TemplatedPage以外のものをネストすることはできません。 つまり、内部統制のテーマは100％あなたの統制にあります。 新しいテンプレートをオン/オフする魔法のスイッチにすぎず、同じ方法でそのスイッチを制御できます。 これにより、ページ、レイアウト、さらにはコントロールレベルでテーマをオプトインおよびオプトアウトできます。

@ encrypt0rは正確ではありません。 ハイブリッドと考えてください。 レンダリングは可能ですが、内部では、プラットフォーム固有のすべてのコントロールが描画コードをテーマにしています。 ただし、Skiaには簡単に追加できるエスケープハッチがあります（v1の近くにあるとは思えませんが）。

@opcodewriter ListView2（明らかに実際にはその名前は付けられません）がついに今年のロードマップに登場しました。 なぜ新しいListViewなのですか？ 元のAPIは、ほぼ無制限の数のバグや問題を引き起こしますが、下位互換性を完全に壊さずに実際に効果的に修正することはできません。 Cell / ViewCellやItemsViewのようなものTemplatedItemsListは、1.0で意図されていたものに対してはうまく機能しましたが、APIの最新の使用法に必要なものにはほど遠いものです。

残念ながら、ListViewタイプ自体の中でこれを解決する方法は考えられません。また、残念ながら、コミュニティでも解決できたとは思いません。 現時点での最善のオプションは、ListViewをそのままにして、オーバーヘッドが少なく、簿記が少なく、存在する必要のない奇妙なタイプが少なく、ターゲットフレームワークが最善を尽くすことを信頼して、はるかに洗練されたものを作成することです。

古いリサイクル戦略を削除するだけで、これは私たちが実行できない大きなバックコンパットを破る変更になり、Xamarin.Formsコードベースのかなりの部分が削除されます。 ListView2は、ガードレール（またはCellの場合は、2つの異なる内部プロジェクトの不道徳な合併）を目的としていたこれらのアイテムを削除することで、金属にはるかに近づき、今ではすべての人を傷つけています。

古いキャッシング戦略は、現在存在するすべてのレンダラーに影響を与えます。 すべてのレンダラーが要素の変更をサポートする理由です。 私の最善の見積もりでそれがなくなった場合、プロジェクト内のすべてのコードの約10％がなくなります。 それは本当にプロジェクトの最大の癌です。

@davidortinauあなたのコメントがとても素敵なフォーマットであるという理由だけで、あなたはあなた自身のコメントを受け取ります！

このアプローチを使用してアプリケーションをトップレベルで説明すると、次のようになります。

• すべてのプラットフォームで同じように見えることをテーマにしたアプリ
• マテリアルデザイン（この場合）はデフォルトでパターン化されています
• 構成で有効になった最新のナビゲーションパターン
• iOS、Android、UWPで同じように見えるようにエントリやボタンをカスタマイズするのに労力を費やす必要はありませんか？

それは正確ですか？ 私が強調すべき他の利点は？

はい、その通りです。 あなたが強調することができる他の多くの利点がありますが、あなたがそれをいじり始めるとそれらは明らかになるはずです。 ボトムシートを作成できるように、FABを用意し、URLを使用してナビゲートします（更新はまだ予定されています）など。

アプリの代わりにMaterialShellがあります。 これから利益を得るには、新しいトップレベルのアプリケーションパラダイムを学習/採用する必要がありますか？

間違い。 アプリのMainPageはMaterialShellです。 アプリケーションは引き続きアプリのルートです。

アプリに入ると、ContentPageランドに戻りますよね？ しかし、私のすべてのボタンとエントリは、マテリアルファイドできれいです。

あなたが上で間違っていたところを除いて、はい、これは正しいです。

OnPlatformなどで、外観（または動作）を別のプラットフォームで異なるものに分岐させることはできますか？

はい。

既存のアプリからこの「シェル」を使用するまでの移行パスはどのようになりますか？

Google Playストアの再現ケースを見て、すべてのアプリの現在のページをそこに配置することを想像してください。 これは、Nav / Tab / MDページを直接使用しているアプリ内の領域のみを置き換えます。 ContentPagesには影響しません。

新しいMaterialShellを紹介し、アプリの構造と外観をどのようにしたいかを説明し、それを実行して新しい良さを確認しますか？

ビンゴ

フライアウトやメニューアイテムの外観が気に入ったが、デザイナーのコンプに合わせて調整する必要がある場合、どのようなオプションがありますか？

ヘッダー、ヘッダーの折りたたみ方法と非表示方法を完全に制御します。 フライアウト内の各「セル」（セルにはなりません）のルック/フィールを完全に制御します。 そこにある各グループのヘッダーも完全に制御します。 実際には、すべての「外観」を制御できますが、コンテンツを追加するために、さらにいくつかの場所を追加する必要があります。

どの時点で、「うーん、これをすべて自分でロールする必要がありました」と言って、持っているものを標準のXamarin.Formsアプリ構造に移動しますか？

GooglePlayストアの物理的なレイアウトのフライアウトが希望とは完全に異なって見える場合。 わずかに異なるわけではなく、完全に異なります。

MaterialShellを完全に放棄しなければならない場合、そのスタイリングの良さをすべて失い、iOSとAndroidおよびUWPの間でエントリがまったく異なって見える状態で（今日のように）始めたところに戻りますか？ したくないです。

MaterialShellは、子がそれらを取得できるようにいくつかのデフォルトリソースを設定しているだけではありません。 あなたはそれを自分で行うことができるでしょう。 とにかくそれをしなければならないかもしれません、私たちは実際にMaterialShellにデフォルトでそれをさせることを約束していません。 オプトアウトではなくオプトインにすると、サブツリーに対する単一のAPI呼び出しになります。

私が期待している転換点があります。 このアプローチを使用してすばやく作業を開始した後、いくつかの制限にぶつかり、オプションを検討する必要があります。 それらは何であり、どの時点でMaterialShellを使用しないほうがよいですか？

意図は、あなたがシェル以外に行くことを決して良くしないということです。 Materialは必要ないかもしれませんが、常にShellが必要です（ここでもShell基本クラスが登場します）。 どうして？ シェルのルック/フィールははるかに構成可能になり、ナビゲーションストーリーははるかに統一され、シェルではできない他のページでできることは何もないはずです。

より良いのは、シェルレンダラーが実際に簡単に構成されて正常であることを確認することです。 魔法の隠しクラスはありません。私たちがハードディップするカスタムネイティブビューサブクラスもありません。 可能な限り、レンダラーのすべてのコンポーネントが構成され、交換可能になります。 そうすれば、希望どおりに機能しない場合でも、実際に修正できます...

なぜ最初はそうしなかったのですか？ それは初期の設計目標ではなかったので、私たちはそれと結婚することになりました...これは十分に大きくて新しいので、私たちはその間違いを私たちと一緒に運ぶ必要はありません。

@opcodewriter

真剣に、Xamarinフォームはいくつの異なる方向に進むことができますか？ XFチームは、少なくともAndroidとiOSの現在のXF実装を修正し続けることがほとんどできませんが、これはどうでしょうか。

バグ修正、XAMLプレビューの修正、パフォーマンスについてはどうですか？

^^これ

@migueldeicaza

皆さん、昨日、ジェイソンと私はこの仕様を改善する方法について話し合いました。私たちは大規模な更新を行う予定です。これをさまざまな問題に分割しています。

ミゲル、これは明らかに大きな仕事になるだろう。 すべての開発者を代表して話すことはできませんが、私のチームは安定性、パフォーマンス、柔軟性の3つを望んでいると言えます。 バグを修正したい。 アプリをスムーズに実行し、UI / UXデザイナーが提供するデザインを、振り返って「申し訳ありませんが、プラットフォームでは不可能です」と言わずに実装できるようにしたいと考えています。 この仕様は、その目標に反しているようです。 これには、ジョブでより多くのリソースを投入する必要があります。つまり、リソースは、安定性、パフォーマンス、および柔軟性に取り組むために解放されません。

これは、xamarinフォームで開発するための新しいデフォルトの動作/方法でしょうか？ または、プラットフォーム固有のルックアンドフィールごとにアプリを構築するオプションがまだありますか？

@DanielCauserは、長期的にはこれが「デフォルト」の方法になる可能性があると思いますが、現在の方法に取って代わるものではありません。 これは、より統合された最新の方法であり、デフォルトで現在手作業で構築されているシェルの多くを提供します。 さらに、シェルを単一のコントロールとして提供するため、シェルの描画方法とレイアウト方法について多くの最適化を行うことができます。 シェル専用の3つの描画パスはもうありません。

このアイデアが提案する改善が、基盤となるXamarin Formsコードの改善によって解決されるという条件で、私は慎重にこのアイデアに賛成です。 これによりフォームに加えて複雑さが増す場合、私はそれを使用しません。
私のお金のために、私はフォームを現在よりも柔軟で、速く、そして完成させることに向けられた開発者リソースを持っていることを望んでいます。 それが起こった場合、私はここで提案されたすべての新機能を自分で作ることができます。 この場合のDIYは、Xamarinが提供する一般的なツールキットよりも、私と私のクライアントに適していることはほぼ間違いありません。 いくつかの注目すべき例外を除いて、この提案は私が現在直面している問題を解決しません。

@jassmith

1. 500以上の未解決の問題があります。
2. Xamarin Formsは3年前のものであり、基本的なコントロールと機能にはまだバグがあり、重要な機能はまだ不足しており、パフォーマンスはまだ完全に特定されていません（いくつかの改善が行われたことは知っていますが、Androidでのパフォーマンスは著しく劣っています）。
3. XamarinForms開発チームはまだ小さすぎます。

なぜ今、このまったく新しい機能に取り組み始めたいのですか？ 最初に上記に焦点を当てる方が理にかなっていますか？

ListViewに関連する上記のコメントについて：完全に再設計/置換するなど、あらゆる種類の大胆な取り組みを称賛します。 Xamarin Formsのすべてが非常に優れているわけではありませんが、変更したり変更したりしないでください。

@opcodewriter

1）うんあります。 私はその問題に同意し、私が個人的に推進する優先的な作業項目であり続けます。

2）Androidでのパフォーマンスは、これを推進する理由の一部です。 これにより、フレームワークはページ遷移のヘッドアップ時間を増やすことができるため、JIT時間などを非表示にすることができます。 ページをよりインテリジェントにプロアクティブにロードおよび保持できます。 XFチームが修正できないのは、全体的なJIT時間です。 AOTを有効にしてAndroidでアプリを実行し、その速度がはるかに速い場合、私ができることは何もありません。

3）ここには引数はありません。

なぜ今、このまったく新しい機能に取り組み始めたいのですか？ 最初に上記に焦点を当てる方が理にかなっていますか？

この作業は予定されていません。ここで仕様について説明しているだけです。 私の経営陣は、彼らが私のアドバイスで適切だと感じたときにそれをスケジュールします。

ListViewに関連する上記のコメントについて：完全に再設計/置換するなど、あらゆる種類の大胆な取り組みを称賛します。 Xamarin Formsのすべてが非常に優れているわけではありませんが、変更したり変更したりしないでください。

ListViewは、まさにXamarin.Formsのバグベアです。 これらの500の問題のうち、220がバグとしてマークされており（ハウスキーピングや拡張の問題もたくさんあります）、25％以上はListViewに関係しています。 比較のために、UWPプラットフォーム全体に関係するのとほぼ同じ割合です。 さらに悪いことに、破棄後にレンダラーが使用されると基本的に説明されているAndroidのクラッシャーのかなりの数も、ListViewのバグですが、ListViewは検索クエリのどこにも表示されないため、検索に表示される可能性はほとんどありません。

@jassmith既存の問題を修正する以外に（ListView以外にも、常に正しく機能するとは限らないものがあります）、
-真のポップアップサポート（基本機能と共通機能はまだありません）
-戻るときにページナビゲーションをキャンセルする（長い未解決の問題）
-基本的なコントロールがありません（CheckBox、RadioButtonなどはありません）
-クロスプラットフォームの描画（キャンバスコントロールまたはその他の方法）
-ソリッド\グラデーションブラシ（SolidColorBrush、GradientBrush）のクロスプラットフォーム描画のサポート

フレームワークを本当に豊かにする方向でより多くの作業が行われ、CSSスタイルやFlexbox（独自の問題が発生した）のようなものを追加しないことを望みます。

@opcodewriter

真のポップアップサポート（基本機能と共通機能はまだありません）

公平に、それは現実になるのに十分高く優先されることは決してないようです。 これは実際、ある時点でかなりうまくいきました。

戻るときにページナビゲーションをキャンセルする（長い未解決の問題）

これは実際にはMaterialShellが対処することを目的としたものです。 これをNavigationPageで実行できないのにはかなり確かな理由があります。

基本的なコントロールがありません（CheckBox、RadioButtonなどはありません）

これらのいくつかは、現在進行中のF100イニシアチブの一部です。

クロスプラットフォームの描画（キャンバスコントロールまたはその他の方法）

これは、＃2452で指定されているようにこれの姉妹APIになります

ソリッド\グラデーションブラシ（SolidColorBrush、GradientBrush）のクロスプラットフォーム描画のサポート

上記と同じ答え。

@jassmith

公平に、それは現実になるのに十分高く優先されることは決してないようです。 これは実際、ある時点でかなりうまくいきました。

OK、2018年末までに優先順位を付けるのを楽しみにしています:)

これは実際にはMaterialShellが対処することを目的としたものです。 これをNavigationPageで実行できないのにはかなり確かな理由があります。

現在の実装でこれを実行できない理由を詳しく教えてください。

これらのいくつかは、現在進行中のF100イニシアチブの一部です。

分かりました。 成功を祈っている..

現在の実装でこれを実行できない理由を詳しく教えてください。

軌道から大きく外れているので、ここではこれ以上詳しく説明しませんが、要点は次のとおりです。

• iOSでは、バックスワイプジェスチャをリアクティブにキャンセルすることはできません。 これは、人々がより大きな電話で戻るために使用する主要な方法であるため、これは明白な省略になります。
• iOSでこの動作をオーバーライドすることは技術的には可能ですが、新しいバージョンのiOSがリリースされたときに実際にサポートされるか、機能するかどうかを確認できない方法で、UINavigationControllerの内部をかなり深く理解する必要があります。 要するに、Appleはこれをやっている人々をあまり楽しんでいないようだ。

それがスタイリングにどのように影響するかに関して、そこにもいくつかの他の小さな懸念があります。 しかし、それは長い話です。 それでもこの特定の機能について話し合いたい場合は、新しい問題を開くことをお勧めします:)

@jassmith
gestureRecognizerShouldBeginを処理して、 OnBackButtonPressedようなものを呼び出すだけで十分だと思いました。

全体的に、私は読んでいるものの多くが本当に好きですが、これはコアXamarinFormsのnuget / repoで実行する必要があるもののようには感じません。

これは、Xamarin Formsに組み込まれるのではなく、XamarinFormsの上に構築されるべきであるという意見のあるアプローチです。 これは、開発者が別のアプローチを取ることを可能にする別個のライブラリと見なしています。 公開する必要があるXamarinフォームの必要な部分はである必要があり、これはそれらのビットの上に構築する必要があります。

開発者がXamarinClassic / NativeまたはXamarinFormsを使用することを決定したときと同じように、XamarinFormsまたはXamarinForms withShellを使用することも同様の決定を見ることができます。

Xamarin Formsは、プラットフォームを相互に適合させようとせずに、最高のクロスプラットフォームUIフレームワークの作成に重点を置く必要があります。 今日、Xamarin Formsは、プラットフォームの感触が尊重されていることを確認するという素晴らしい仕事をしています。

ベースシェルがXamarinFormsリポジトリにあり、シェルの処理に関するコードがいくつかあることがわかりましたが、Material Shellは、特定のデザイン言語とナビゲーションパターンに緊密に結合されているため、XamarinFormsリポジトリにあるべきだとは思えません。

@MisterJimson
ご意見ありがとうございます。 パブリックAPIの表面積の正確な配置はまだ決定されていません。 両方のアプローチには長所と短所があります。

仕様は、ShellクラスとMaterialShellクラスの両方を持つように（できれば非常にすぐに）更新されます。 MaterialShellクラスは、コアからの移行を検討する部分です。 シェルはあなたが説明したものでしょう。

シェルブレイクアウトとナビゲーション仕様の更新で更新

既存のXF実装が作成された場合、私は本当にそれを望んでいます...このようなものがBCLの一部としてではなく、アドオンとして存在できるようにするために、より強力でより良いものになります。 したがって、正しく安定した強力な基盤となるプラットフォームを持つことは、既存のアプリやこのような新しいレイヤーにメリットをもたらします。

このことの進化を楽しみにしています。

@jassmith @brianlagunas

ほんの少しの観察。

• BackButtonBehavior、まったく必要ない場合に備えて、可視性プロパティが必要ですか？
• マテリアルシェルナビゲーションスキームはPrismに似ていますが、これらの既存のフレームワークで機能しますか？ （Prism、FreshMVVM、MVVMCross）
• ナビゲーションバーのレイアウトを完全に上書きできますか？ 現状では、Formsはこの点で非常に制限されており、新しいバージョンのFormsがカスタムコードを壊す可能性が高いことを知っているので、不格好なナビゲーションバーがカスタムレンダラールートを強制することになります。
• MasterDetailはあまり触れられていませんが、フライアウトメニューをカスタマイズできますか？
• ハンバーガーをどのように管理しますか？

私は、既存の問題点と制限に対処し、新しい機能を備えた新しいものを確実に解決したいと思っています。

いいね。

私はXFに非常に慣れていませんが、フレームワークはやや壊れやすいという評判が少しありますが、確かにこれはあなたの努力のおかげで急速に改善されています。

だから、それが価値があるものについては、これは私の意見です:-)

Xamarinが現時点で多くの愛を集めていることは@ opcodewriterに同意し

また、これは別のレイヤーである必要があるという@MisterJimsonの考えも気に入っていますが、自分の能力とサポートできるフレームワークの数については正直である必要があります。 私たちは皆、刺激的な新しい光沢のあるものをコーディングし、難しい決定を回避する傾向がありますが、コードの強固な基盤を開発することをあなたに頼っています。

他の誰かのことを心配せずにコードを機能させるのに十分な問題があります:-)

XFは現在良い場所にあり、本当に堅実なツールセットになる可能性があります。

これにあなたのすべてのハードワークをありがとう、それは示しています。

@mackayn

BackButtonBehavior、まったく必要ない場合に備えて、可視性プロパティが必要ですか？

CanExecuteがfalseを返すようにコマンドを設定します。 今のところ、二次的な方法を追加しないことを選択しました。

マテリアルシェルナビゲーションスキームはPrismに似ていますが、これらの既存のフレームワークで機能しますか？ （Prism、FreshMVVM、MVVMCross）

私はそう確信している！ よくわかりませんが、彼らと彼らの悩みを考えていました。 そのため、たとえば、すべてのナビゲーションは1つのイベントで行われます。

ナビゲーションバーのレイアウトを完全に上書きできますか？ 現状では、Formsはこの点で非常に制限されており、新しいバージョンのFormsがカスタムコードを壊す可能性が高いことを知っているので、不格好なナビゲーションバーがカスタムレンダラールートを強制することになります。

この部分は難しいです。 ここでは可能な限り拡張性を認めたいと思いますが、これを正気で合理的な方法で改善する方法についての提案を心から開いています。

MasterDetailはあまり触れられていませんが、フライアウトメニューをカスタマイズできますか？

ヘッダーを任意のビューに設定したり、グループヘッダーとアイテムに使用されるテンプレートを制御したり、メニューアイテムを追加したりできます。 レイアウトのいくつかの側面を制御しますが、100％は制御しません。 繰り返しになりますが、他に何が必要だと思うかについて考えてみるとよいでしょう。 フッター動作プロパティを持つフッターの必要性がはっきりとわかります。

ハンバーガーをどのように管理しますか？

BackButtonBehaviorもハンバーガーをオーバーライドします。 おそらく名前を変更する必要があります。 繰り返しになりますが、ここで提案を受け付けています。 もともと私はそれをLeftBarButtonと呼んでいましたが、RTLの状況では左側にありません...

@stevehurcombeの技術的な見返りは継続的かつ継続的です。 これは、チームのはるかに小さな派遣団によって並行して実行されます。 残念ながら、現実には、この仕様の多くは奇妙な方法での技術的な見返りに関するものです。 Xamarin.Formsは、1.0リリースで巨額のAPI債務を負い、それ以来その債務を抱えています。 XFの特定のものは、APIがそれらを表現する方法のために、正しく動作させるのが非常に難しいか、正しく動作させることが不可能ですらあります。

タブバーとナビゲーションバーの間の緊密な相互作用はそのような領域の1つであり、MDP内のタブまたはアイテム間を移動する際にグリッチが発生しないようにすることも別の領域です。 各要素がアプリのシェルの全体像を把握できないため、問題が発生する可能性のある領域はたくさんあります。

工具に関しては、これに専念する完全に別のチームがあり、彼らは大きな進歩を遂げています。 内部ツールは過去6か月で大幅に改善されており、ぜひお試しください。

@mackayn

マテリアルシェルナビゲーションスキームはPrismに似ていますが、これらの既存のフレームワークで機能しますか？ （Prism、FreshMVVM、MVVMCross）

恐れることはありません。コミュニティが問題がここにあることに気付く前に、 @ jassmithがこれを私の注意を引きました...だから私は自信を持って言うことができます、それは彼が確かに私たちと同じくらい気にかけている問題です。 あなたはそれが私たちがサポートしようとしているものになると確信することができます。 この規模の何かは、それがフォーム開発者全体のニーズを満たし、PrismのようなMVVMフレームワークのニーズを満たすことを保証するために、確かに多くのチーム間の対話を必要とします。

@dansiegel

両方のチームが対話していることを知っておくとよいでしょう、それは私が知る必要があるすべてです👍

@jassmith今では、いくつかのものが実行されている方法やXFでアーキテクチャ化された方法が最善ではないことは明らかです。 したがって、豚に口紅を塗る代わりに（ここで失礼になりたくない）、新しいフレームワークを最初から再作成するか、既存のフレームワークを大幅にリファクタリングしてみませんか。 非常に怖いように聞こえますが、Xamarin Forms開発者の大多数は気にしないと確信しています。私たち全員が、アプリなどをリファクタリングすることに興奮しているので、はるかに優れたアプリを手に入れることができます。
「この種の変更は望まない」という理由で、PRが適切なリファクタリングで拒否されるのを見てきました。 誰がそのルールを作ったのかはわかりませんが、彼は深呼吸してリラックスし、おそらく「ルール」を再考する必要があります。
最高のものは何ですか：それを維持できないフレームワークを使用してイライラした開発者を抱え続けたり、リファクタリング作業を行う必要があるイライラした開発者を抱え続けたりしますか？ ちょうど私の2セント...

@opcodewriterあなたと私は同意しますが、これはこの仕様ではトピックから外れています。

ナビゲーションに関する新しい資料を読むだけで、とても気に入っています。 ナビゲーションコマンドをバインドするためのソートハンドを持っているのが大好きで、URLの周りにナビゲーションを向けるのは賢いです（Prismの影響を受けていると思います）。

皮肉なことに、URIナビゲーションスキームは、私たちが昔からやりたかったことであり、フレームワークに合理的に組み込むことができなかったため、Prismを実装するようにプッシュし始めました。 彼らの信用をとらないために、彼らはその100％に値する:)

速記の正確なセマンティクスはまだ手に入れられています。

私はそれがおそらくもっと次のようになると思います：

<Button Command="{segue:Uri}" CommandParameter="app://Foo/Bar/Baz" />

また

<Button Command="{segue:Push}" CommandParameter="{DataTemplate local:MyPage}" />

したがって、拡張機能は、どのパラメーターを使用するかについてより正確にすることができます。 名前空間は主に、インテリセンスで物事を簡単に見つけられるようにするために使用されます。

@jassmith私はこのセグエのものが本当に好きです。 プッシュモーダルをどのようにサポートするつもりですか？

私はすべての詳細を持っていませんが、マークアップ拡張機能に包まれたプリズムのようにURLナビゲーションを想像することができます。

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="path/to/page" />

<!-- push modal -->
<Button Command="{segue:Uri Modal='true'}" CommandParameter="path/to/page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://root/path/to/page" />

最初に注意することは、URIナビゲーションはシェルでのみ機能するということです。 これは、奇妙なエッジケースがなくてもスタックを一貫して理解できる唯一の場所であり、コンセプトをサポートするようにナビゲーションインタラクションを設計できます。

現在のところ、完全なURIのみをサポートしています。 パーシャルはコンテキストに応じて処理されるため、処理が非常に困難です。

現在の場所がapp：// Shell / Apps / Games / Detailsであると仮定すると、3つの例は次のようになります。

特に、これは、現在のShellItemにAppsルートがあり、現在のShellTabItemにGamesルートがあり、ContentPageがルートの詳細を持つスタックにプッシュされているシェルにいることを意味します。

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games/Details/page" />

<!-- push modal -->
<Button Command="{segue:Uri}" CommandParameter="app://page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games" />

シェルURIでは、最初の場所は常にシェルです。 そうでない場合は、モーダルプッシュであると見なされます。 次はShellTab、次にShellTabItemです。 その後、ShellTabItemのナビゲーションスタックが続きます。 現時点では、URIナビゲーションをすべての可能なページコントロールにバックポートするつもりはありません。 これは、MasterDetailPageを使用する人々にとっては本当に厄介です...

ルート登録とルートプロパティを使用すると、タイプベースのルーティングは必要ありません。 スペックから削除します。

@jassmithがこのナビゲーションについてもっと考えています。いくつか質問があります。

1. CanExecuteどのように処理できますか
2. 複数のタップをユーザーが制御（読み取り防止）できるようにするにはどうすればよいですか？
3. 相対ナビゲーションをどのように処理しますか？ IEあなたは3ページの深さで、4番目に進む必要がありますが、スタックは完全に動的ですか？
4. プリズムにはこの素晴らしいNavigationParameters概念があり、クエリ文字列/Navigation/MyPage/MyPageDetails?id=33を介して基本的な値だけでなく、複雑なオブジェクトnew NavigationParameters {{nameof(MyObject), MyObject}}も渡すことができます。 同様のことをサポートする予定はありますか？

@ChaseFlorell

1）セグエとは？ 現在はできません。 間違いなくもっと考える必要があります。 セグエコマンドを作成する方法はありますが、それは...最悪です。 それはあなたがそれを扱うことを可能にするでしょう、しかしその時点でそれは本当にそれの価値がありません。

2）プッシュが完了するまで、セグエは自分自身を無効にします。 前のナビゲーションタスクが完了するまで、コマンドno-opをさらにアクティブにしようとします。

3）セグエ付きのプッシュ/ポップなどの従来のナビゲーションを使用できます。 これらは相対的なアクションです。

4）[QueryParameterAttribute]はすでに存在する場合と存在しない場合があり、確認も拒否もできません。 ;）

複雑なオブジェクトのサポートを追加する可能性はほとんどありません。 アイデアは、コンバーターを使用して単純な値を取得し、それらを複雑なオブジェクトに変換することです。

URIベースのアプリナビゲーションを構築した過去の経験から（CAB-p＆pの複合UIアプリケーションブロックに戻る）、 System.Uriタイプを使用せず、代わりにすべてをURIのように見せることを強くお勧めします。ただし、URI実装自体は使用しないでください。 @pprovostは、仕事が彼に残したに違いない生涯の傷跡を証言することができます。 インターネットURIの制限やエラー（つまり、ホスト名）に直面したときに、アプリ内のものをあまり気にすることができなかったため、数え切れないほどの問題にぶつかったことを覚えています。

すでに受けた被害の一部だと思います。

実際、URIベースのナビゲーションスキームをサポートする場合は、System.Uriが最適です。 CABはURIナビゲーションを使用していましたが、あなたが言うように、System.Uriオブジェクトの代わりに文字列を使用できるようにすることで、URIの「ように見える」ようにしました。 ホスト名は必要ありませんでした。

あなたが求めているのは、入力した文字列構文を受け入れることができる非常に緩い文字列ベースのAPIです。これは、予測可能な結果を​​生成するものではありません。 URI /文字列ベースのナビゲーションスキームが機能するには、ルールが設定されている必要があります。

XFでも任意のURIは機能しません。 URLに含まれているが、ファイルシステムでは有効な無効な文字のリストは、正確には小さくありません。 これらはすべて文字列が機能する場合であり、URIはエスケープしないか、ユーザーに機能しない（または失敗する）理由を理解させ、名前を「URIセーフ」に変更する必要があります。

より制限的な（またはより良いセマンティクス/解析/検証？）必要がある場合は、独自の抽象化を作成できますが、私見では、 System.Uriは無料ではない多くのインターネット手荷物をもたらします。 これは、Mono / MonoDevelopがパスを表す独自のFilePathを作成した方法と似ています。パスは通常、単なる文字列です。

少なくとも、すべてのURIは相対的であると見なされているようです。これにより、作業が簡素化されます。 CABでは、スキームとホスト名の部分でも絶対URIを使用しましたが、これには問題がありました。

たとえば、 UriよりもResoucePathようなものの方がずっと好きです。 しかし、ゲームの後半では、とにかく取引が完了したと確信しています。

ファイルシステムパスが何かと何の関係があると思うかわかりません...

システムを混乱させるためにURIをどのように使用しますか？ スキームとホスト名を無視し、ルートの検索を開始します（[az]のみに制限されています）。 あなたが入れた奇妙なキャラクターが見つからない場合、それはただ止まります。 また、入力するクエリ文字列は有効なC＃識別子である必要があります。そうでない場合、一致しません。 クエリ文字列データ内のエスケープされたデータはエスケープ解除されます。

@kzu URIはXFで問題なく機能し、ファイルシステムスキーマよりもXFに適しています。 実際、ウェブサイトからアプリを起動するときはURIが必要です。 Prismの実装を見て、URIベースのナビゲーションがいかに強力であるかを確認する必要があります。 URIベースのナビゲーションスキームを使用してPrismで構築されたすべてのアプリの中で、無効な文字に関連する問題が送信されることはありません。 XFプラットフォームのURIベースのスキーマに関する懸念は問題にならないことを確信しています。

理にかなっています。 Prism @brianlagunasの背景情報をありがとう！ 今、私は仕様を注意深く読み、実際に役立つフィードバックを提供する必要があります;）

非常に優れたイニシアチブですが、お客様のために「特別な」ことを行うための適切な仮想メソッドまたはその他の方法を作成することにより、拡張性とカスタマイズが考慮されることを願っています。

たとえば、次のことが可能になりますか/方法：

1. たとえば、アイコン付きのバッジを表示するタブの拡張性。 または、「詳細」ボタンや「 * 」ボタンなどのポップアップドロワーを上に表示します。
2. カスタムスナックバー（たとえば、カスタムの背景/前景色で行ったアクションの[元に戻す]ボタン付き）
3. 可能な限り最速のナビゲーションを提供するアニメーションがないなど、シェルでプログラムされたデフォルトとは異なるアニメーションを使用してAndroidにフラグメントをプッシュします。

テクニカルノート：シェルはページをリサイクルして、ページに2回移動すると、ネイティブ要素がその下の別のVMで再利用されるようにしますか？

こんにちは@rogihee

実装に関するフィードバックをお待ちしております。 https://github.com/xamarin/Xamarin.Forms/blob/9558f2837280e02b41848d3a3c3213d49a664751/Xamarin.Forms.Platform.iOS/Renderers/ShellRenderer.cs

Androidは現在、まだ開発が進んでいますが、同じアプローチを使用しています。

@rogiheeページのリサイクルに関しては、私はそれを実行可能にするための

これらの「作成*」オプションは良さそうです。 これの迅速な進歩を見るのは良いことです！

要素を再利用することでパフォーマンスに影響があるのではないかと思います。 個人的には、Mem / CPUの使用率が高いよりも、アプリの速度と「流動的な」感触を優先します（ただし、もちろん最後のどこかに相関関係があります）。 そして、iOS / Androidを他のものよりも優先します:-)。

シェルは流動性の知覚に非常に焦点を合わせています。 まだどこにでもあるわけではありませんが、一緒になっています。

シェルが設計された負荷を確実に処理できるようにするために、シェルを使ってクレイジーなことをしようとする初期のユーザーを配置する必要があります。

@jassmith migは、ビルドで3分間シェルについて言及しました。

私は彼のパパではありません

+1

現在の世界の状態に一致するようにAPIを更新しましたが、サンプルを更新する必要があります。

いくつかの更新されたサンプルを追加しましたが、他のサンプルを修正し、短縮構文を使用するときにルートの説明を更新するために多くの作業を行う必要があります（短縮ルートを取得するためです！）

おやおや、私はパーティーにとても遅れていると感じています。 素晴らしい記事と議論。 私はそれをすべてざっと目を通し（空港で申し訳ありません）、私自身の提案があります。 これがどこかで言及された場合は申し訳ありません。

@jassmith @migueldeicazaナビゲーションバーに動作を追加して、ListViewがスクロールしているときにスクロールオフし、反対方向にスクロールしたときに表示できるようにしてください。 そこにあるほとんどすべてのプロのアプリは、より多くの不動産を表示するためにこれを行います。 これは、小さなデバイスで特に役立ちます。

もう1つは、XAMLタグの名前を変更して、把握しやすくしてみませんか？ たぶんShellSectionの代わりにTabを使用しますか？ 現在、ShellXタグがたくさんあります。

iOSの場合、ナビゲーションバーのスクロールモードを有効にするためにオン/オフを切り替えるプロパティがあると思います。 Androidの場合、新しいレイアウト（CoordinatorLayout、AppBarLayoutなど）の使用を開始する必要があります。 XFのAndroid実装は、まだメインコンテナとしてRelativeLayoutを使用しているため、この点でかなり時代遅れです。 この特定の問題については、どこかに拡張チケットがあると思います。 Shellがさまざまなスクロールモードをサポートすることを望んでいます。

また、ページにエラーやその他の種類のポップアップを表示するには、カスタム動作を実装する必要があることがよくあります。 シェルはこの機能をすぐにサポートする必要があるため、サードパーティのプラグインに頼ったり、複雑なUI階層を作成したりする必要はありません。

@ adrianknight89

ナビゲーションバーに動作を追加して、ListViewがスクロールしているときにスクロールオフし、反対方向にスクロールしたときに表示できるようにしてください。 そこにあるほとんどすべてのプロのアプリは、より多くの不動産を表示するためにこれを行います。 これは、小さなデバイスで特に役立ちます。

それは私が本当に正しいやり方を見つけようとしていることです。 残念ながら、すべてのプラットフォームがこの機能をサポートしているわけではないため、プラットフォーム固有の取引になる可能性があります。 少なくともAndroidはこれをサポートするためにゼロから構築されました。私は時々それをオンにして、それがまだ機能することを確認します。

もう1つは、XAMLタグの名前を変更して、把握しやすくしてみませんか？ たぶんShellSectionの代わりにTabを使用しますか？ 現在、ShellXタグがたくさんあります。

ここでの命名は本当に難しいです。 ShellTabは、上と下で少し混乱します。 代わりに、より一般的な階層名を選択しましたが、名前付けに満足していないことを認めなければなりません。 提案は100％歓迎されています...名前をもう一度リファクタリングすることを完全に楽しみにしているわけではありませんが、何ができるのでしょうか...

iOSの場合、ナビゲーションバーのスクロールモードを有効にするためにオン/オフを切り替えるプロパティがあると思います。 Androidの場合、新しいレイアウト（CoordinatorLayout、AppBarLayoutなど）の使用を開始する必要があります。 XFのAndroid実装は、まだメインコンテナとしてRelativeLayoutを使用しているため、この点でかなり時代遅れです。 この特定の問題については、どこかに拡張チケットがあると思います。 Shellがさまざまなスクロールモードをサポートすることを望んでいます。

ShellはCoordinatorLayout + AppBarLayoutを使用し、基本的に今のところスクロールアウェイサポートを「無効」にしますが、機能します。 iOSのスクロールオフも簡単に実装できます。 残念ながら、UWPのNavigationViewはこの機能をサポートしていません。

また、ページにエラーやその他の種類のポップアップを表示するには、カスタム動作を実装する必要があることがよくあります。 シェルはこの機能をすぐにサポートする必要があるため、サードパーティのプラグインに頼ったり、複雑なUI階層を作成したりする必要はありません。

例、例が必要です:)

@jassmith

James Montemagnoの接続プラグインを使用して、データ接続状態の変化をリッスンしています。 インターネット接続が切断された場合、インターネットがオンラインに戻るまで、スライド/フェードインおよびフェードアウトするか、静止したままであるという通知を表示することをお勧めします。

Instagramでは、この通知はナビゲーションバーのすぐ下に配置されます。 Tumblrでは、下部のナビゲーションバーの真上にあります。 YouTubeでは、奇妙なことに、下部のナビゲーションバーの下にあります。 たぶん、このようなものはシェルの一部になることができますか？

提案されたポップアップコントロールは、私が知る限り、既存のウィンドウをオーバーレイするものですが、簡単に消すことができます。 今述べた通知と、場合によっては他のタイプの通知は、親ウィンドウをオーバーレイする必要がないため（つまり、親のビジュアルツリーはジェスチャーに応答します）、ポップアップが適切かどうかはわかりません。

シェルには、このビュー（Notification [View]と呼びます）の外観、配置、および開始/終了アニメーションの動作を定義するためのプロパティを含めることができます。 つまり、基本的には、Shell、INavigation、またはその他に組み込まれているクロスプラットフォームのトースト/スナックバーの実装です。 これは、プラットフォームごとにネイティブに見えるように強制されることはありませんが、すべてにわたって同じです。

安定性や柔軟性などについての議論については、1.0からの古いアーキテクチャを排除せずに、それらを達成することは現実的ではないと思います。 私はListView2に非常に賛成です。

@jassmith

• 新しいListViewの拡張チケットはもうありますか？
• v1.0はいつ発売されると思いますか？ EOYで見ることができるチャンスはありますか？

また、チームの規模が小さすぎることについても同じ懸念があります。 実際、私は過去にこれを取り上げました。 将来、チームがもっと大きくなることを願っています。 🙏@ davidortinau @migueldeicaza

@jassmithしばらくの間、Appクラスのレンダラーがあれば、現在サードパーティのハッカーが必要な多くのことを実行できると信じていました。 たとえば、RgPopupsプラグインはアプリのメインビューを取得し、レンダリングされたビューをアプリに挿入して、画面全体のポップアップの外観を提供します。 これは現在、「純粋な」Xamarinフォームでは実現できません。 ただし、アプリにレンダラーがある場合は、自分でこれを行うことができます。

私はすべて、これらの種類のトースト通知をShellに追加し、それがどのように行われるべきかを理解しようとしています。

アプリケーション内の好きな場所にページを任意に配置できるように作成していただけますか？ これは、タブレット/デスクトップ/ラップトップ（大画面デバイス）で特に重要です。タブレット/デスクトップ/ラップトップでは、同時に複数のページを画面に表示する必要があり、分割ビュー（マスター詳細ページ）を使用して整理する必要はありません。 例、Googleマップを参照してください。

コンテンツがマップ上でどのように「フローティング」しているかに注目してください（分割ビューなし）。 タブやフローティング領域内のナビゲーションなどを使用する場合は、ページの階層が非常に限られているため（ページをネストできないため）、Xamarinフォームを使用してこの種のことをすぐに実行することはできません。ビュー内）。 私たちは実際に、NavigationPageと同様の機能を提供する独自のカスタムビューを開発しましたが、これはビューであるため、この種のレイアウトを実現できましたが、多くの作業/困難を伴いました。

アプリケーション内の好きな場所にコンテンツ（ページを含む）を配置できる必要があります。

アプリケーション内の好きな場所にページを任意に配置できるように作成していただけますか？

このビューは電話では正しく表示されない可能性が高いので、 @ jsiemensには少し興味がありますが、デスクトップとタブレットでは見栄えがします。 それがどのように機能すると期待できるかについて詳しく説明していただけますか。 最終的には、Regionの概念をWpfからFormsに取り入れていると言いたくなるでしょう。 私のひざまずく反応は、私はこの概念を気に入っていますが、すでに複雑なナビゲーションAPIに博士号または少なくとも天才レベルのIQが必要になるリスクがあり、ユーザーの採用には最適ではないということです。

@dansiegel少なくとも個人的には、特定のビューポートのしきい値を下回ったときに、下部のスクロールビューを移動して圧縮するために、おそらくVSMまたは同等のものを使用します（GMapsが現在行っているように）。 ただし、ナビゲーションと状態管理がそのためにどのように機能するかを確認するのは好奇心が強いでしょう。

ナビゲーション：ユーザージャーニーの観点から始めて、ユーザーがそれがどのように機能することを期待するかを見れば、それは克服できない問題ではないと確信しています。 ナビゲーションは、電話の全画面の性質と、たとえば大画面の小さなビューに対応する必要があります。

ユーザーは、タブレットと小さなビューを単一のナビゲーションマイルストーンとして「見る」でしょう。 小さな画面では、2つのマイルストーンが存在する可能性があります。 ナビゲーションは、どういうわけか、応答性がなければなりません。

開発者として、私たちは確かにその応答性を処理する必要があります。それは状況に応じたものだからです。 それを処理するためにフレームワークに依存することはできませんが、フレームワークはそれをサポートする必要があります。

@jsiemens @dansiegel現在私がこれを処理する方法は、 ControlTemplateを使用しています。 「ページ」タイプのコンテンツをContentViewとして作成し、プラットフォームに適したContentPage （ NavigationPage ）でホストします。 ControlTemplatesすると、 ControlTemplateバインド可能なプロパティに基づいてオン/オフを切り替える複数のバインドされたContentViews （通常はGridのでオーバーレイできます）を持つことができますControlTemplate自体（ DynamicResourceも使用できます）。 最終結果は、すべてのコンテンツがページにあるが、すべてが常に表示されるわけではないWebサイトのCSSパネルのように少し機能します。 ControlTemplateはこれにとって魔法のようなものであり、シェルでそれらの機能を保持したいと思います。

@dansiegelアプリが電話で実行されているか、タブレット/ラップトップ/デスクトップで実行されているかに応じて、異なるシェルをロードするようにコーディングするだけです。

@jsiemensは問題ありません。私のコメントは、あなたのアイデアをさらに洗練するために、さらなる会話と批判的思考を促進することだけを目的としています。 いくつかの点で、ここでのあなたの概念を考えると、すべてのページは本質的にマルチページであり、ページを特定のコントロールに添付して、通常のナビゲーションではなく単なる別のビューとして扱うことができます。

@dansiegelええ、私が求めているのは、アプリケーション内のどこにでもページを追加できるようにすることだと思います。 基盤となるプラットフォームが適用しない場合にXamarinFormsがこの制限を課すのは奇妙です（たとえば、iOSはビューの単なるツリー階層です-NavigationControllerのビューをアプリケーション内の文字通りどこにでも追加できます）。 また、私のコメントは、シェル仕様でこれをカバーする必要がないことを示すことを目的としていました。「レスポンシブ」レイアウトを気にする必要はないと思います。 レイアウトを構築できる限り、フォームファクターに応じて条件付きでシェルをロードすることができると思います。それで十分です。

この仕様では完全に話題になっているわけではないと思いますが、複雑なレイアウトを構築する方法（ @MelbourneDeveloperの3番目の優先順位-柔軟性など）について話しているので、ここで言及しました。これは確かに最上位のレイアウトです。私と私のチームの心に留めておいてください（ナビゲーションページやタブなどの「ページのみ」のコンテンツを含む可能性のあるコンテンツパネルをマップの上にフロートできるようにするマッピングアプリを構築しています）。

シェルを使用してこれをどのように解決するかはわかりませんが、シェルに対する私の最初の反応は、まだできないことは何もしていないようだということです。 Xamarin Formsチームは、私がすでに実行できることを実行できる機能を構築し続けているように感じますが、方法は異なります（CSS、Visual State Manager、現在は描画とシェルの仕様など）。 だから、それは私にあまり価値をもたらさない。 以前はできなかったこと（カスタムコントロールやレンダラー以外）を実行できる新しい機能が必要です。 構文がよりエレガントであるためにシェルがそれを達成するための答えである場合、私はそれですべてですが、最終的には、現在のページ/ビュー階層よりも強力で表現力があり、本当に価値があります。

レイアウト内のすべてのサブビューをネイティブウィジェットを使用せずにレンダリングできる場合、xamarinビューごとにネイティブビューを作成することから切り離すことができますか？ XFビューのグループが単一のサーフェスにレンダリングされ、1つのネイティブビューに分割される、一種の自動ハイブリッドフラッター/ xamarinアプローチ。 Androidビューの作成/レイアウトc＃-> java相互運用コストを回避すると便利です。

進行中！！

シェルが終了した後の@jassmith 、描画は一緒に有効になりますか？

シェルはmacosとwpfをサポートしますか？

@juepiezhongren最初のターゲットはiOSとAndroidです。 その後、他のプラットフォームが優先されます。

図面は現在開発されていません。 現在の仕様では、シェルで有効です。 今日と同じように、Xamarin.Forms内でSkiaSharpおよびSkiaベースのコントロールを使用できます。

私たちは、素材や他のデザインスタイルの一貫したデザインをサポートするために、他のネイティブ戦略に取り組んでいます。

@davidortinauシェルはRTLサポートを改善しますか？

どのように良いですか？ 今日のRTLサポートには何が欠けていますか？ 私たちはどこでもそれに対処する必要があります。

正直なところ、私はしばらくXF開発を行っていませんが、ほとんどの制限はわかっています。＃1222と＃2448を見てください。

たぶん、シェルはこれらの一般的な制限を助けることができます：

• NavigationPageボタンの場所、ツールバーアイテムの場所、および遷移アニメーションは、現在、FlowDirection設定ではなく、デバイスのロケールによって制御されています。
• FlowDirectionのグローバルアプリ設定

そして、他のいくつかのプラットフォーム固有の制限

Xamarin.Formsの最も重要な機能。 そもそもこのように作られているはずです。

描画せずに、xfはまだかなり不足しています

@juepiezhongren

Skiasharpを使用するだけです

@mackayn私はそれをたくさん使いました
https://github.com/xamarin/Xamarin.Forms/issues/1789
普遍的な見た目は必須です

アダムはひらひらしました、それはxfにとって本当に悲しい兆候です、そこでxamarinはもともとはるかに良い評判をかなり簡単に達成することができました

xamarin.nativeは、ネイティブまたはフラッターに反応するものが何であれ、他のクロスプラットフォームソリューションよりもxfに対してはるかに堅固です。 dotnet愛好家として、xfの現在の状況は常に私にとって少しがっかりしています。

@juepiezhongren

この議論は無意味です。Flutterを使用するニーズが満たされない場合は、複数のプラットフォーム（iOSおよびAndroidのみFlutterなど）にアプリを配信できます。これらの変更により、一貫したルックアンドフィールがより実現可能になります。

単純な小さな不満、そんなに。 まだシェルのためにやった！

私は、SkiaをForms apiにもっと焼き付けたほうがいいと思います（Telerikが行ったように）。 私は同意しますよ。

しかし、彼らがShell＆CollectionViewに努力を注いでくれてうれしいです。

こんにちは、みんなに言ってください、右から左の言語のために、どのように私は右にレイアウトを使用することができますか？

やあ、

私はそのアイデアが大好きですが、いくつかの小さな入力があります。
少し遅れていると思いますが、名前が少しわかりにくいと思います。

1. アイテム、セクション、コンテンツはすべて、実際には一般的な名前です。 それらがどのような関係にあるのかはすぐにはわかりません。 コンテンツ=>セクション=>アイテムまたはセクション=>コンテンツ=>アイテム、またはアイテム=>セクション=>コンテンツですか。
   したがって、より具体的な名前を見つけることで、さまざまな「もの」が何であるかをもう少し指定できる可能性があります。

2. それは私を次の入力に導きます。 すべての内部アイテムのコンテナとしてシェルがあります。 したがって、内部で「ShellItem」の代わりに「Item」のような単純な名前を使用することはできません。 すべての「もの」をShelltem、ShellSectionなどと呼ぶ必要はありませんが、大丈夫です。 それは議論の余地があります。

痛い

2018年もリリースされますか？

プレビューリリースが利用可能になりました！ いくつかの優れたサンプルについては、 https：//blog.xamarin.com/connect-2018-xamarin-announcements/を

本当にAndroid9が必要ですか？ それは少し制限のように思われるでしょう。

それはすべてかなり良いように聞こえますが、純粋にUIの相互作用に基づいているように見えます。
試してみるとわかると思いますが、最初の懸念は、関心の分離を適切に維持しながら、Bluetooth接続デバイスから受信したメッセージングなどのビジネスロジックまたはコードからナビゲーションをどのように駆動するかです。

@hassanrahimi

こんにちは、みんなに言ってください、右から左の言語のために、どのように私は右にレイアウトを使用することができますか？

RTLはサポートされていますが、フライアウトメニューは左側に表示されます。 これは現在の制限です。

下部のタブバーUIをカスタマイズすることは可能ですか？

シェル内をナビゲートするときにリロードされないコントロールをシェルに追加することは可能ですか？ たとえば、FAB。

@stfnilssonの下部のタブバーUIは、スタイル、次にカスタムレンダラーを介してカスタマイズできます。 将来的に例を提供する予定です。

あなたがFABのように説明するようにグローバルなコントロールを追加することはMaterialShellのために計画されています。 FABに加えて、これから恩恵を受ける追加のシナリオを提供できますか？

最初に：私は以前に自分のシェルを使用していましたが、今では自分のシェルを自分のシェルに置き換えるだけでかなり簡単にでき、はるかに優れています。 私は本当にそれが好き。

おそらく私の場合はカスタムへの道であり、シェルとは関係ありませんが：

ケース1：
非常にカスタムなメニューを使用してアプリを作成する場合、アプリの各隅に1つのメニューボタンがあります。ボタンをシェルの一部（オーバーレイやビルボードなど）に追加するにはどうすればよいですか。 ナビゲートするたびに再レンダリングされたくない。

ケース2：
シェルを使用したいのですが、中央のボタンが重くなるように下部のタブバーをカスタマイズしたいと思います（中央の隆起したボタンと呼ばれます）。 レンダラーを使用して、下部ナビゲーションビューをカスタマイズする必要がありますか？

このような特別な場合にはシェルを使うべきだと思いますか？

もちろん、各プラットフォームでそれを行うことを検討していますが、メニューはすべてのプラットフォームで同じように見えるはずなので、コードを共有したいと思います。

これが私のフィードバックです。 私はこのテストを行います（ Xamarin.Forms 4.0.0.8055-pre1 ）：

   <Shell.FlyoutHeader>
        <local:FlyoutHeader />
    </Shell.FlyoutHeader>

    <ShellItem Title="Home" Icon="home.png">
        <ShellSection>
            <ShellContent>
                <local:MainPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

    <ShellItem Title="Notifications" Icon="notification.png">
        <ShellSection>
            <ShellContent Title="Recent">
                <local:NotificationPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

    <ShellItem Title="Test" Icon="icon.png">
        <ShellSection Title="Home" Icon="home.png">
            <ShellContent>
                <local:MainPage />
            </ShellContent>
        </ShellSection>

        <ShellSection Title="Notifications" Icon="notification.png">
            <ShellContent Title="Recent">
                <local:NotificationPage />
            </ShellContent>

            <ShellContent Title="Settings">
                <local:SettingsPage />
            </ShellContent>
        </ShellSection>
    </ShellItem>

ハンバーガーメニューをタップするとすべて動作します。 ただし、 Testメニューに移動し、 HomeとNotificationsを前後にタップして、 RecentまたはSettingsいずれかを選択すると、ページが表示されます。それぞれ開きます。 しかし、ハンバーガーメニューをもう一度タップすると、アプリがクラッシュします。

GroupHeaderTemplateを使用して、ShellItem内のShellContentのグループのタイトルを表示するにはどうすればよいですか？

Xamarin Formsが現在のサイズと複雑さで維持できないことは多くのユーザーにとって明らかです。したがって、新しいものは複雑さを増すのではなく減らす必要があります。

@jassmith意図は、シェル以外に行くことは決して良いことではないということです。 ...目的は、シェルレンダラーが実際に簡単に構成されて正常であることを確認することです。

シェルが完成した場合、将来的に何が減価償却される可能性がありますか？それが完了すると、Xamarinフォームの全体的な複雑さが軽減されますか？ ContentPageを除く他のすべてのページは減価償却されますか？

戦略は、リポジトリからできるだけ多くを引き出すことです。 コアリポジトリの安定性と保守性が最も重要です。

また、ShellがShellPageと呼ばれない理由がある場合はどうなりますか？ 他のページクラスの名前は「ページ」で終わります。

Shellの現在の広告（https://blog.xamarin.com/xamarin-forms-4-0-preview/）は有望ではありません。

1. アプリケーションアーキテクチャの高レベルを表現するための簡略化された方法

これにより、Xamarinは本来の目的を超えてしまいます。 Xamarinはアプリケーションアーキテクチャには必要ありません。 これはレイアウトのみに関するものでなければなりません。

1. ターゲットのモバイルプラットフォームに適した一般的なUIナビゲーションパターンの階層

Xamarin.Formsはデスクトップもカバーしているので、ここで「モバイル」が誤植であることを願っています。

1. 堅牢なナビゲーションサービス

Xamarin.Formsはナビゲーションを必要としません。 現在のナビゲーションが機能していない場合は、何も組み込む必要のないナビゲーションへの優れたアプローチが多数あるため、減価償却することができます。

こんにちは@charlesroddie 、フィードバックをありがとう。

現時点ではシェルが適切ではないようですが、問題ありません。 アプリに価値がない場合は、シェルを使用する必要はありません。 とは言うものの、シェルの仕様は開発者のフィードバックから多くの情報を得ており、開発者コミュニティにサービスを提供することが私たちの目的の中核です。

今日のXamarin.Formsでは、TabbedPage、MasterDetailPage、タブとメニュー項目、およびさまざまな組み合わせを使用して、アプリケーションアーキテクチャ、コンテンツの階層について既に説明しています。 これが私がここで「建築」と言っていることです。 Shellは、これらのパターンを単純化して置き換えます（Shellを使用することを選択した場合）。

「モバイル」は誤植ではなく、非常に慎重に使用されています。 シェルはiOSとAndroidを対象としています。 デスクトップをターゲットにしている場合は、シェルを使用しません。 デスクトップバックエンドにシェルサポートを追加することについて寄稿者から関心を聞いたことがあり、それらのPRは好評です。 Shellは、アプリをあらゆるプラットフォームに持ち込むのに非常に適した位置にあり、根本的なUIパターンの変更（将来のインターフェイスがどのように採用されるかを知っている）にも適応できる柔軟性（回復力）があると思います。 今日の試験場はiOSとAndroidです。

シェルについて開発者と話をしたとき、シェルのナビゲーションが彼らが評価した機能のリストの一番上にあることを知って驚いた。 ルーティング、ディープリンク、ナビゲーションを中断する機能、バックスタックの即時記述、データの受け渡し、ページの遅延読み込みは、今日発生する問題を解決する開発者にとって非常に魅力的な属性です。

デスクトップをターゲットにしている場合は、シェルを使用しません...シェルはアプリを任意のプラットフォームに移動するのに非常に適していると思います

Xamarinが自重で崩壊することを望んでいません。 Shellがすべてのプラットフォームに到達するまでは、メンテナンスの問題が発生します。これは、他のページの代わりではなく、追加であるためです。 また、多くの人が明らかにクロスプラットフォームフレームワークの採用を検討しているときに、デスクトップ開発者にとってメッセージングの問題があります。

Xamarinは、cssなどの多くのフィーチャークリープを示しています。 これはプロジェクト全体を脅かす可能性があり、組織内の一部の意思決定者がこれを理解することを願っています。

Xamarinが自重で崩壊することを望んでいません。 Shellがすべてのプラットフォームに到達するまでは、メンテナンスの問題が発生します。これは、他のページの代わりではなく、追加であるためです。 また、多くの人が明らかにクロスプラットフォームフレームワークの採用を検討しているときに、デスクトップ開発者にとってメッセージングの問題があります。

Xamarinは、cssなどの多くのフィーチャークリープを示しています。 これはプロジェクト全体を脅かす可能性があり、組織内の一部の意思決定者がこれを理解することを願っています。

同意します。 機能がデスクトップ（UWP）でサポートされていない場合、それは役に立ちません。 また、CSSについても同意します。複雑さが増し、以前はできなかったことができない機能のメンテナンスのオーバーヘッドが増えるようです。 何よりもはるかに必要なのは、すべてのプラットフォームに対してより多くのコントロールを使用し、既存のコントロールに対してより多くの機能を提供することです。 Shellには、Pageインフラストラクチャと同じ制限があり、完全に採用する必要があるか、まったく使用できず、アプリケーションのルートレベルでしか使用できません。 それだけでなく、今では同じことを行う2つの方法があり、それは複雑で混乱を招きます。 ですから、シェルを使わずにフライアウトメニューだけを作りたいのなら、それはできません。 また、シェルアイテムがマップされるコントロールの数は非常に限られています。タブ、ナビゲーションページ、フライアウトだけでは不十分です。 Xamarin Formsが、UWPのようなフレームワークが持つ幅広いコントロールを提供し、UWPの場合と同様に、無駄な肥大化（cssなど）を発生させずに、コントロールのセットとして公開できれば幸いです。

皆さんはいくつかの有効なポイントを上げていると思いますが、UWP / iOS / Androidアプリを管理していて、シェルがUWPをサポートしていないことを知ったときに少しがっかりした人として、将来的には「たぶん」しかありません。 それから私はシェルの要点を見逃していることに気づきました。 これは、誰かが2つの主要なモバイルプラットフォーム用のアプリを作成するための非常に簡単な方法です。 エンタープライズ開発者として... UWPが必要です。XFを検討するためにUWPサポートが提供されるまで待ちました...しかし、多くの開発者はそれを必要としないと思います...さらに複雑なナビゲーションなども必要です。シェルが提供します。

しかし、ナビゲーションとページの使用を開始するために多くの時間を費やしたことも覚えています...理解するのに時間がかかる場合があります。 しかし、私は非常に複雑な基幹業務アプリも作成しています。そのレベルの複雑さを必要としない単純なアプリがたくさんあります。 XFは、Flutterなどに対抗するために進化する必要があります。また、新しい開発者にXFを採用してもらう必要もあります。 そして、プラットフォームの使用は、プラットフォームを維持するために必要なリソースを保護するのに役立つように思われます。

また、UWPを必要としない将来のプロジェクトがいくつかあり、それらでShellを使用することを楽しみにしています。これにより、プロジェクトの作成がはるかに高速になると思います。

私は2.3リリースの頃からXFを使用しているだけで、やるべきことは確かにもっとありますが...現在のプラットフォームは大幅に安定しています...少なくとも私にとっては...だから私は心配していません追加のメンテナンスと歴史的に、XFチームはメンテナンスの負担を非常に意識しているようです...だから彼らはそれを管理していると信じています。

プラットフォームへの素晴らしい追加に感謝します！

物事を行うための新しい方法を追加すると、古い方法が減価償却されて古いドキュメントが削除されるまで、新しい開発者は混乱します。

Flutterははるかに簡単です。 マークアップ言語はなく、すべてがコード内にあります。 Xamarinは、より複雑でバグが多いことで競争することはありません。 同じ焦点で、Flutter（より多くのプラットフォーム）以上のことを行うことで競争します。

このコアのパフォーマンスと安定性に重点を置いて、XAMLやCSSを含まない、基本クラス以外のページやシェルを含まないプロパティバインディングを含まないXamarin.Coreが必要になるところまで来ています。 一部の開発者が現在のバグ率を受け入れることを犠牲にしてこれらの機能を必要とする場合は、Xamarin.Extensionsを使用してそれらすべてが存在するようにすることができます。

物事を行うための新しい方法を追加すると、古い方法が減価償却されて古いドキュメントが削除されるまで、新しい開発者は混乱します。

Flutterははるかに簡単です。 マークアップ言語はなく、すべてがコード内にあります。 Xamarinは、より複雑でバグが多いことで競争することはありません。 同じ焦点で、Flutter（より多くのプラットフォーム）以上のことを行うことで競争します。

このコアのパフォーマンスと安定性に重点を置いて、XAMLやCSSを含まない、基本クラス以外のページやシェルを含まないプロパティバインディングを含まないXamarin.Coreが必要になるところまで来ています。 一部の開発者が現在のバグ率を受け入れることを犠牲にしてこれらの機能を必要とする場合は、Xamarin.Extensionsを使用してそれらすべてが存在するようにすることができます。

@charlesroddie上記で行ったことは、XAMLの使用を強制されるものではありません。 Xamarin.FormsのXAMLはオプションです-常にそうでした。 私は常にXamarin.FormsアプリのUIをコードのみを使用して実行します。上記のすべての「タグ」は、関連する親に指定して追加できるクラスです。
Xamarin.Formsでコード化されたUIが不可能な場合、私はそれを使用しません-終止符！

Re Flutterは一般的に-とてもいいですが、問題はiOSとAndroidだけです-macOS、Windows 7 / 8.1、Linuxをターゲットにする必要があるので私にとっても機能しません。 Xamarin.Formsに勝るものはありません！

カスタムビューをマスターページとして設定できますか。含めることが非常に重要です。MenuItemやページだけを優先するわけではありません。

Xamarin Macとuwpのサポート？

ナビゲーションプロセスにどのように接続しますか？ ご存知だと思いますが、Prismを例にとると、ビューモデルはDIコンテナによって作成され、要求されたページのBindingContextとして自動的に設定されます。

ビューモデルにINavigatedAwareを実装し、データの読み込み、サービスの有効化/無効化などの特定のユースケースを処理することもできます。

同様のものを追加したかったので、最初の推測はOnNavigatingとOnNavigated Shellイベントでしたが、 CurrentとTargetはShellItemを公開しないため、不可能です。慣例によりBindingContextを設定するか、ビューモデルイベントをトリガーしますか？

これについて何か提案はありますか？

編集：＃5166によって追跡されます。

このシェルのアイコンについて、画像の代わりに「アイコンフォント」を使用することは可能ですか？ 画像の実行時に色を変更することは困難であり、さまざまなプラットフォームでさまざまな解像度に合わせて色を管理することも困難です。 SkiaSharpライブラリでレンダリングされたマテリアルデザインフォントを使用してアイコンクラスを作成することを提案できますか？ このクラスは比較的簡単で、シェルですぐに使用できるアイコンがたくさん作成されます。

@vincentwx同意します。 アイコンフォントは非常に使いやすく、使い慣れています。

@ vincentwx @ stevehurcombe絶対に。 私は今アプリでこれをやっています：

<ShellItem>
    <ShellContent Title="Upcoming" 
                      ContentTemplate="{DataTemplate pages:UpcomingPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Rocket}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>

        <ShellContent Title="Latest" 
                      ContentTemplate="{DataTemplate pages:LatestPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Book}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>

        <ShellContent Title="Company" 
                      ContentTemplate="{DataTemplate pages:CompanyPage}">
            <ShellContent.Icon>
                <FontImageSource Glyph="{x:Static local:IconFont.Building}" 
                                 FontFamily='{OnPlatform iOS="Font Awesome 5 Free", Android="fa-solid-900.ttf#Font Awesome 5 Free"}'
                                 Size="18"/>
            </ShellContent.Icon>
        </ShellContent>
    </ShellItem>

これを使用して、すべてのグリフの静的クラスを作成しました： https ：

iOSの色に修正が必要なバグがあります。 ＃5071

Xamarin Macとuwpのサポート？

現時点では@mdonogmaではありません。 追加のプラットフォームをサポートすることへの関心/需要を集めていますが、現時点ではロードマップに含まれていません。

@davidortinauコードとリンクをありがとう。

Android 8.0では、シェルコンテンツでホストされているWebView要素でウェブページをスクロールできません。 ただし、XamarinShellがなくても問題なく動作します。

Xamarinフォーム4.0.0.135214-pre4

下部のタブとタイトルビューのFontFamilyを変更する簡単な方法はありますか？

@varyamereon私は昨日
拡張したシェルをGitHubで間もなく公開しますが、次のようになります。

カスタムシェルを作成します。

<Shell
    x:Class="X.Mobile.App.Features.AppShell.AppShell"

次に、シェルカスタムレンダラーを作成します。

[assembly: ExportRenderer(typeof(AppShell), typeof(AppShellRenderer))]

namespace X.Mobile.App.iOS.Renderers
{
    [Preserve(AllMembers = true)]
    public class AppShellRenderer : ShellRenderer
    {
        protected override IShellItemRenderer CreateShellItemRenderer(ShellItem item)
        {
            return new CustomMenuRenderer(this)
            {
                ShellItem = item
            };
        }

それで：

 namespace X.Mobile.App.iOS.Renderers
 {
     [Preserve(AllMembers = true)]
     public class CustomMenuRenderer : ShellItemRenderer
     {
         private SKCanvasView _skiaSharpPaintView;
         public CustomMenuRenderer(IShellContext context) : base(context)
         {
         }

public override void ViewDidLoad()
{
}           
public override void ViewWillLayoutSubviews()
{
{

次に、フォントファミリを設定するには：_（頻繁に行わないでください）_

var txtAttributes = new UITextAttributes
            {
                Font = UIFont.FromName("MyriadPro-Semibold", 12.0F)
            };
            foreach (var uiTabBarItem in TabBar.Items)
            {
                uiTabBarItem.SetTitleTextAttributes(txtAttributes, UIControlState.Normal);
            }

下からのポップアップをサポートしてシェルを拡張した人はいますか（下のシート）？

私は自分の古いシェルから新しいシェルに多くのコードを移動しました（もちろん構成）、私はそれが本当に好きです。 5月に製品化するためにリリースされるアプリにも使用しています：-）（Xamarinコードもデバッグします）

リストをShell.MenuItemsにバインドするためのサポートはありますか？ または、BindableLayoutを使用する必要がありますか？ データベースからリストをロードして、これらをメニューとして使用する必要がある場合があります。 それらは同じビューを持っていますが、選択されたメニューに応じて異なるデータをロードします。

シェルを使用するときにAndroidでOffscreenPageLimitを変更する方法はありますか？ これは私のアプリにとって残念なことに非常に重要であり、Shellを進めるのを妨げています。

ありがとう！

いくつかの機能リクエスト：

1. シェルレベルで、すべてのページタイトルにFontFamilyを設定します。
   例えば

2. シェルレベルで、すべてのページタイトル/ナビゲーションバーなどのタイトル/ナビゲーション背景画像を設定します。
   例えば

GroupBehaviorは、pre4では機能しません。

<ShellItem GroupBehavior="ShowTabs" FlyoutIcon="stuff.png" Title="Discussion">...
結果：

xxx / Shell / Shell.xaml（14,14）：エラー：位置108：14。 'GroupBehavior'のプロパティ、バインド可能なプロパティ、イベントが見つからないか、値とプロパティのタイプが一致していません。

GroupHeaderTemplateは何もしないようですが、どのように使用されているか、または有効になっているかはわかりません。

MenuItems.Add（item）を介してアイテムを正常に追加するMenuItemsを追加/削除しようとしていますが、フライアウトが再度表示されても結果が表示されません。 これはこれを行うための正しいアプローチですか？

MenuItemの操作についての言及はありませんが、これらのアイテムをビジネスロジックに基づいて動的に維持できない限り、シェルは私にはほとんど役に立ちません（そして、上記の

プログラムでcsファイルのシェルを変更できることが非常に重要であるというdbwelchに同意します。 メニュー項目だけでなく、ShellItems＆ShellSectionsにも使用できます。

Flyoutをオンにしてメニュー項目を追加すると、Androidではハンバーガーメニューが表示されます。iOSでは、その場所をクリックすると機能しますが、アイコンが表示されません。 何か案は？

@KyleTraynorどこかに未解決の問題があります。 3bar.pngおよび[email protected]画像をiOSリソースフォルダーに手動でコピーし、それらがバンドルアイテムとしてプロジェクトに含まれていることを確認する必要があります。

ソースで見つけた画像は添付されています：

@melucas助けてくれてありがとう！ 私はそれを直そうとして気が狂いそうだった。 よく働く。

Shellを使用するときにAndroidのOffscreenPageLimitを設定する方法を知っていますか？

1つのShellSection内に4つのShellContentsを入れて作成したトップタブページがあり、iOSではうまく機能しますが、Androidでは、不要なページを入れ替えるとページが再読み込みされます。 通常、自分のタブ付きページでは、この問題を修正するためにOffscreenPageLimitを設定できますが、Shellでそれを行う方法を見つけることができません。

@davidortinauページのタイトル、下部と上部のタブにフォントファミリを設定するオプションがありますか？ すべてのプロジェクトで、フォントを変更するためにiosとandroidのカスタムレンダラーを作成する必要があります。

それで、フライアウトシェルのアイテムを実際に変更する機能を持っているという私の投稿への応答がなかったので、おそらくこの機能は範囲外であるか、あるいはおそらくバグと見なされているのでしょうか？

本格的なアプリがこの機能なしでこのシェルをどのように使用できるかわからない。 非常に単純なアプリのみが、a）ユーザーのコンテキスト（つまり、認証済み/非認証済み）、またはb）アプリケーションのさまざまな状態に基づいて、メニューの項目を追加/変更/削除/無効化する機能を必要としません。それが必要です。

好奇心旺盛な@jassmith 、仕様を作成した人々はこのフォーラムにキー入力されていますか、それとも開発者のフィードバックのためだけですか？

ところで、この1つの主要な項目以外に、1つのアプリのコードにシェルを実装しました。これは非常にうまく機能しています。ありがとうございます。 しかし、残念ながら、シェルでこの機能が機能/実装されていない場合は、それを引き出して独自のフライアウトを実装する必要があります。

@dbwelch 、いくつかのこと。
仕様に投稿しているので、新しい号を開いて書いたような応答はおそらく得られません。 また、ジェイソンはもはやフォームに取り組んでいないので、彼を呼び出すことはちょっと無意味です。

結論として、問題を提出してください

@dbwelch @ChaseFlorellここで問題を開きました： https ：

@davidortinauページのタイトル、下部と上部のタブにフォントファミリを設定するオプションがありますか？ すべてのプロジェクトで、フォントを変更するためにiosとandroidのカスタムレンダラーを作成する必要があります。

@jamiewest機能リクエストを送信してください！ ありがとう！ https://github.com/xamarin/Xamarin.Forms/issues/new?assignees=&labels=t%2Fenhancement+%E2%9E%95&template=feature_request.md&title=%5BEnhancement%5D+YOUR+IDEA%21

UseSwipeGesture機能を実装できますか？
現在、ShellItemクラスにはOperaのShellAppearanceプロパティがないようです。
しかし、Androidでは、シェルのタブはTabPageとは異なります（TabPageはデフォルトでスワイプできます）。

    <ShellItem.ShellAppearance>
      <MaterialShellAppearance NavBarCollapseStyle="Full" TabBarCollapseStyle="Full" UseSwipeGesture="false">
    </ShellItem.ShellAppearance>

@ jingliancui 、Brother Cui、qqまたはWeChatはありますか？

@juepiezhongrenこんにちは、あなたは私とチャットするためにこのq​​qグループに参加することができます313308215

RTMでUWPのシェルとビジュアルサポートが提供される予定はありますか？

私はこのアイデアを歓迎します-ナビゲーションページ、マスター/詳細ページなどでの作業は複雑になるので、どんなに難しくても。 おそらくこれは、私がWebのバックグラウンドを持っているためです（ネイティブAPIをあまり使用していません）。 ここでは、ナビゲーションバー、ページタイトル、戻るボタン、ツールバーアイテム、ヘッダーとフッター（ListView）などのカスタマイズが思い浮かびます。

私が要求しているのは、* Shellなどの新機能が、カスタマイズと拡張性を念頭に置いて出荷されていることだと思います。 一見単純なことを実行するために一連のレンダラー、ビヘイビアー、トリガーなどを作成する必要がなかった状況はほとんどありません。

皆さんが思いついたものが何であれ、Xamarin.Formsアプリを他のネイティブアプリと同じように見栄えよくするために、できる限りのことをしてください。 この機能により、モダンな外観のXFormsアプリの起動パッドが改善されるようです。

仕様を推測する代わりに、このシェルがどのように機能するかを確認するために利用できるソースコードはありますか？ たとえば、ハンバーガーアイコンが利用可能な場合、その色付けにどのスタイルが使用されているかなどです。 申し訳ありませんが、C＃/ Xamarinの新機能ですが、コードがどこかで表示可能であれば、非常に役立ちます。

@dbwelchここGitHubでソースコードを閲覧できます。 「T」を押してシェルに入力すると、関連するクラスが表示されます。 ただし、C＃/ Xamarinを初めて使用する場合は、これが最適な開始点ではない可能性があります。 より多くのドキュメントが得られるまで、サンプルのいくつかをチェックすることをお勧めします。

https://github.com/davidortinau/Gastropods
https://github.com/davidortinau/ShellGallery
https://github.com/davidortinau/TheLittleThingsPlayground

ドキュメント： https ：
MSDNの記事： https ：
ブログ： https ：

@davidortinauありがとうございますが、リリースされたばかりのコードが利用可能だと思いました。シェルコードはどこにありますか？ 4.0、Shell、その他のブランチの下を調べましたが、それは私から隠れています！ ありがとう！

@dbwelch https://github.com/xamarin/Xamarin.Forms/search?q=shell&unscoped_q=shell

たとえばShell.csはここにあり

@pauldipietroありがとう、今それを見てください。 @davidortinau私は実際にすべてのリンク（ダウンロードしたばかりのLittleThingsを除く）にかなりの時間を費やしましたが、ハンバーガーアイコンの色などの単純なものを変更する方法がわかりません。 私のアプリでは紫色で表示されていますが、紫色はどこにも定義されていません（私が見ることができます）。 少しイライラする;-)。

更新：私はちょうど問題を見つけました、そしてもちろん、それはTintColorを追加するためにFinishedLaunchingに存在するいくつかの厄介なコードです。 DOH！

紳士に感謝します、援助に感謝します！

フライアウトパネルにいくつかのアイテムが表示されていますが、問題ありません。 ただし、現在、シェルアイテム（アイテムのコンテンツではない）を非表示/非表示にする方法がすでにあります。 たとえば、ContentPageがあり、シェル内にナビゲーションを配置したいだけです。

<local:DetailPage />

常にフライアウトパネル/リストにアイテムを追加しているようです。 また、タイトルがない場合は、アイテムのスタック/プレースホルダーが空になります。 私はアイテムを隠すために多くの方法を試しましたが、それでも運がありません。 おそらく誰かが助けてくれるか、機能がまだ利用できません。

序文：私は初心者のATMです。 ならないようにしています。

@davidortinauそれで、私はこのシェル機能を学習して、ナビゲーションなどを当社の最初のXamarin.Formsプロジェクトに追加しようとしていました（うわー！）。新しいルーティング機能を介して、ShellItemからアプリケーションの他の部分への複数のパラメーター。 これはまったくのことですか？ または、代わりにMenuItemコレクション内のMenuItemsを使用したコマンドに固執する必要がありますか？ MenuItemを使用してFlyoutレベルから1つ以上の値を渡す必要がある場合、代わりにMenuItemsを使用しているため、シェル階層でアプリを構造化できなくなったように見えますか？ コマンドパラメータでMenuItemsを使用すると、それが失われませんか？

これにチャイムできる人はいますか？ もしそうなら、私はそれを大いに感謝します。 基本的にはShellを使用したいと考えていますが、多くのShellItemが同様の中間ページに移動してOrderTypeを作成するため、ユーザーが1つをクリックして選択したShellItemにタグを付けてContentTemplateページまたは適切なものに渡すことができます。正しいタイプと部門の適切なデータが表示されたメインの注文画面に移動する前に、まずOrderDepartmentドロップダウンを選択します。

また、これが間違った場所である場合はお詫び申し上げます。 もしそうなら、私を正しい場所に向けてください。 ありがとう！

アップデート：
たぶん、今はMenuItemsを使用し、コマンドparamをShellViewModelに渡して、ターゲットページに適切な値でナビゲートします。 考えてみると、ContentTemplateページにプッシュするMenuItemsからタブ付き構造に移動する必要はありません。

また、ShellItemがすべて一番上に表示されないように、Flyout内のMenuItemの場所を定義できるかどうか疑問に思いました。 ある日、MenuItemをコレクションの一部として定義する必要がない場合は、次のようにShellItemと混在させることができます。
MenuItem
ShellItem
ShellItem
MenuItem
ShellItem
MenuItem
...
または、ShellItemsがパラメータを渡すことができない場合は、ある時点で渡すことができるようにします。

私は@anthcoolと一緒にいて、これは非常に重要な機能だと

@anthcoolは、私が現時点で行ったことと同じように、ここでいくつかの提案を提供しようとしています。 スタックリストとしてreadonly Stack<NavigationParameter>を持つナビゲーションパラメータクラスを作成します。

public class Navigation
{
    readonly Stack<NavigationParameter> _stack = new Stack<NavigationParameter>();
...
    public Stack<NavigationParameter> Parameters => _stack;
}

NavigationParameterは次のとおりです。

public class NavigationParameter : NameValueCollection { }

ナビゲートするときにプッシュの前にパラメータを追加できます。例：

    var p = new NavigationParameter { { nameof(SomePage), SomeObject } };
    Navigation.Parameters.Push(p);

他のページに移動したら、値をピークまたはポップしてキーを確認するだけです。
上記のようなもの。 お役に立てば幸いです。

@anthcoolは、私が現時点で行ったことと同じように、ここでいくつかの提案を提供しようとしています。 スタックリストとしてreadonly Stack<NavigationParameter>を持つナビゲーションパラメータクラスを作成します。

public class Navigation
{
    readonly Stack<NavigationParameter> _stack = new Stack<NavigationParameter>();
...
    public Stack<NavigationParameter> Parameters => _stack;
}

NavigationParameterは次のとおりです。

public class NavigationParameter : NameValueCollection { }

ナビゲートするときにプッシュの前にパラメータを追加できます。例：

    var p = new NavigationParameter { { nameof(SomePage), SomeObject } };
    Navigation.Parameters.Push(p);

他のページに移動したら、値をピークまたはポップしてキーを確認するだけです。
上記のようなもの。 お役に立てば幸いです。

@rizamarhabanのアイデアをありがとう！ 本当にありがとうございます。 ありがとうございました！ これはすぐにここでチェックします。 もう一度、感謝します！

ShellとVisualがUWPをサポートしていないことを学ぶことに非常に失望しています。

この仕様は本当に行われていますか？
Tizenの実装があるという理由だけで、なぜこれを閉じるのですか？
ナビゲーション機能はまだ検討中だという印象を受けました。

まだUWPはサポートされていません。 Xamarinについてこれまでに経験した最大の失望。

@weitzhandlerポールにメールしてください。 これとUWP全般について説明したい場合は、 dipietro @ microsoft.com 。 プラットフォームを積極的に無視しているわけではありませんが、AndroidとiOSは初期実装を受けており、UWPのシェルサポートの調査が積極的に進行中です。

@mrlaceyいや、それはどこにも終わっていない！ 関連する問題によって閉鎖され続けています。 😄

UWPのサポートを求めているすべての人のために、私はそれを突き刺しました： https ：

コンテンツページにナビゲーションバーテンプレートを実装する方法はありますか？
NavigationPage.TitleViewの指定は、以前のようには適用されません。
参考のためのレポ：
https://github.com/InquisitorJax/Xamarin-Forms-Shell

編集：
マーフィーが再び攻撃します-NavigationPage.TitleViewの代わりにShell.TitleViewを使用してください:)

こんにちは、
私の新しいプロジェクトでは、ShellとCollectionViewを使用していますが、それは素晴らしいことです。
シェルについての1つの質問

• 修正された一番下のアイテムを追加する方法があります（foxの例ではユーザーログアウト用のボタン）

固定ヘッダー（FlyoutHeaderおよびFlyoutHeaderBehavior）を追加することは可能ですが、下部フッターに関する情報が見つかりません。
ありがとう！

こんにちは、
RegisterRouteについて別の質問があります。
私のアプリはかなり大きく、かなりのページ数、約30 ...
それらのそれぞれにRegisterRouteを追加する本当に正しい方法ですか？
Routing.RegisterRoute("blabla", typeof(BlaBlaPage)); ... ...
または、古い方法を使用する方が良いですか？
var blaPage = new BlaBlaPage (); await Navigation.PushAsync (blaPage);

@matteopiccioni私はこのようにすることをお勧めします

Routing.RegisterRoute("blabla", typeof(BlaBlaPage));

と使用
gotoasync("blabla")

今は同じように感じますが、機能が大きくなるにつれて、シェルシステムを介してこれらすべてを動作させることがより適切になるでしょう。

それらのそれぞれにRegisterRouteを追加する本当に正しい方法ですか？

これが問題になる場合は、ページのアセンブリスキャンを行う機能や、それらのルートを生成するコンパイル時の機能を追加することを検討しています。

ここでの主な問題は、どのような種類のリフレクションでもアプリの速度が低下するため、起動時にコストがかかることです。

@PureWeen回答ありがとう
起動時間が遅いことは、xf（Androidの場合）で最も厄介な問題の1つです。
起動時に、最初のレベルのページ（shellitemsページ）のみをルーティングに追加し、アプリの起動後にのみ他のレベルを追加できますか（RegisterRouteの遅延読み込みのようなもの）？

@matteopiccioni

だからあなたが一度にこのようにそれをするなら

Routing.RegisterRoute("blabla", typeof(BlaBlaPage));

大丈夫だよ。 私が話していたのは、ユーザーがそれを行う必要がないようにする何かを構築することになった場合、それをパフォーマンスと比較検討する必要があるということだけです。 現在、 Routing.RegisterRoute("blabla", typeof(BlaBlaPage));はリフレクションを行わないため、一度にすべてを行うことは問題ありません。

文字列とタイプを辞書に追加するだけです

@jassmith @ jamesmontemagno @ piercebogganすごいですね。 GooglePixelでPieSDKを使用するGoogleコンタクトアプリケーションを見たことがありますか？ タイトルバーがなく、アプリの上部にハンバーガーが統合されているUI / UXが大好きです。

この提案は、Googleが使用しているパターンであり、連絡先やマップ、およびおそらく他のシェルであるため、シェルで検討できますか？

あなたの時間と配慮していただきありがとうございます、

カール

以下のすべてのサンプルは、仕様の他の場所で説明されているテンプレート化されたShellContentを使用していないことに注意してください。 ContentTemplateでShellContentsを適切に使用しないと、起動時にすべてのページが読み込まれ、起動パフォーマンスに悪影響を及ぼします。 これらのサンプルは学習のみを目的としています。
幸い、ContentTemplatesでShellContentsを使用する方が、通常、使用しないよりも簡潔です。
[...]
シェルの使用に関する主な問題は、ユーザーがアプリケーションの実行開始時にすべてのページを簡単にロードできることです。 この大きなフロントロード割り当ては、多数のコンテンツページが必要な場合、起動パフォーマンスを大幅に低下させる可能性があります。 このテンプレートを修正するには、可能な場合は採用する必要があります。

私には、これはコンテンツを直接使用するのではなく、テンプレートを使用する必要があるように思えます。 これは私には理にかなっていますが、なぜダイレクトコンテンツアプローチをサポートするのですか？ （単純さは別として、それは人々が自分自身を足で撃つことを可能にします）。 直接コンテンツを使用できることは、「デモを行うときに優れている-そうでなければ恐ろしい」機能であるように感じます。

やあ、
私はここでは新人です。 これが質問をするのに適切な場所であるかどうかはわかりません。そうでない場合は、質問する場所を教えてください。
上記のサンプルと同様のことを試みました。

  <ShellItem Title="My music" ItemsSource="{x:Bind MyMusicModels}" TabLocation="Bottom">
    <ShellItem.ItemTemplate>
      <local:MyMusicItemTemplateSelection />
    </ShellItem.ItemTemplate>
  </ShellItem>

しかし、次のエラーが発生しました。

エラーXLS0413プロパティ 'ItemsSource'がタイプ 'ShellItem'に見つかりませんでした。
エラーXLS0415アタッチ可能なプロパティ「ItemTemplate」がタイプ「ShellItem」に見つかりませんでした。

@Elashiだから、ここでこのアイデアを実行したいと思っていますか
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/layouts/bindable-layouts

ShellItemで？

@PureWeen私はこのアイデアを使用したいと思っていました:)。
このアイデアはまだ実装されていないことを示唆していますか？
まだ実装されていない場合は、作業に興味があるかもしれません。

実装されていません。実装されていればよかったのですが。

私のiPhoneから送信された

2019年5月5日には、11：59 AMで、Elashi < [email protected] [email protected] >書きました：

@PureWeen https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPureWeen&data=02%7C01%7C%7C5a4c31a04c6541d6080608d6d172b36a%7C84df9e7fe9f640afb435aaa ％2BGt13FFjR5BCwdMg0UouarnTxI0％2FawrXtVEURM％3D＆reserved = 0私はこのアイデアを使用したいと思っていました:)。
このアイデアはまだ実装されていないことを示唆していますか？
まだ実装されていない場合は、作業に興味があるかもしれません。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してくださいhttps://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fxamarin%2FXamarin.Forms%2Fissues%2F2415%23issuecomment-489439176&data = 0.02％7C01％7C％7C5a4c31a04c6541d6080608d6d172b36a％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C636926687892536099＆SDATA = RdPBMt9fPqsPC1x0FlJ1MQzn8BK6m9lfg7nsT09YIN8％3D＆0 =予約済み、またはスレッドをミュートhttps://nam05.safelinks.protection.outlook.com/?url=https%3A%2F% 2Fgithub.com％2Fnotifications％2Funsubscribe-AUTH％の2FAABUHE2I4F33TX2SZJE2RVDPT377JANCNFSM4EZ4GB5Q＆データ= 0.02％7C01％7C％7C5a4c31a04c6541d6080608d6d172b36a％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C636926687892546103＆SDATA = UXiXgRiTo4pAjJVraUqmJmYZibiWMdh9htX2SeFG4JM％3D＆予約= 0 。

@Elashiそうではありませんが、MVVMシナリオにとって非常に強力な機能であることがわかりました

あなたがそれに取り組みたいのなら、あなたはあなたが考えていることの基本で問題を作ることができますか？

試行錯誤から...シェル3.2とTheLittlePlaygroundのジェスチャーについてコメントがありますが、ビジュアルパッケージを使用してジェスチャーをANDROIDで動作させることはできません。

シェル+ジェスチャーはiPhoneでのみ機能するというメモに何かが欠けていますか？

@davidortinauこれはほんの一部の仕様であり、しばらくの間閉鎖されていることはわかっていますが、仕様では以下のタスクが完了しているか、発達：

• ShellContentのalaGPSの「サブメニュー」アイテムのAPIを追加->音楽->音楽アプリを開く

現在、GroupHeadersを機能させることができないため、FlyoutMenuを作り直して6つのメイングループに分類し、FlyoutItemでいっぱいのサブメニューを表示して、事前に定義したルーティングに移動したいと考えています。

私のユースケースでは、表示するオプションが50以上あり、それをスクロール状態にするのはUIに適していませんが、表示する各オプションは、ユーザーが無限にスクロールしなくても効率的にアクセスできるようにするために必要なものです。 各オプションの包括的なテーマに基づいてグループに分類することは、UI / UXの観点から最も理にかなっています。

開発/生産の観点から、それがどこにあるのかを明らかにできますか？ -または、それを実装するコードベースの方向に私を向けて、学習できるようにしますか？ （私はXamarinを1か月しか使用していないので、利用可能なリソースのいくつかにまだ慣れていません）。

@TheBaileyBrew

私はこのリポジトリを、あなたのシナリオで最も可能性の高いもので機能する可能性のあるものでグーグルで検索しました。 シェルではありませんが、おそらくMasterDetailPageのセットアップで使用できます。

https://github.com/ishrakland/ListViewWithSubListView/

また、彼らはコース資料の多くをMSFT Learnに移動して更新しました（私はギャップを埋めるために自分自身を実行しています）。 これはここにあります： https ：

私は上記を試してみます。 幸運を祈ります。

こんにちはみんな私はギャラリーや外部ストレージからファイルや写真を選びたいです
xamarinは、誰がファイルを選択するかを形成しますか？ ファイルは.PDF拡張子のみです。 に
両方のファイルを選択してください私は1つのボタンを使用しているので、助けてください!!!

木、2019年5月23日には、午前19時41アンソニークールの[email protected]は書きました：

@TheBaileyBrew https://github.com/TheBaileyBrew

私はあなたのシナリオに役立つ可能性のあるものでこのリポジトリをグーグルで検索しました
最も可能性が高い。 シェルにはなりませんが、MasterDetailPageで使用できます
おそらくセットアップ。

https://github.com/ishrakland/ListViewWithSubListView/

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/xamarin/Xamarin.Forms/issues/2415?email_source=notifications&email_token=AK7KSYK4N3XIVP3IHOBE2P3PW3CKJA5CNFSM4EZ4GB52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AK7KSYI5XKMXD7FC7HZH45LPW3CKJANCNFSM4EZ4GB5Q
。

やあみんな、条件に基づいてタブを追加したいので、XamlではなくC＃を使用してシェルにタブを追加する方法とメニューitmsを追加する方法を教えてください。

@TheBaileyBrew

これはあなたが探しているものですか？
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/shell/flyout#flyout -display-options

@BeleShewあなたの質問は、おそらく、forums.xamarin.comでのstackoverflowまたはoverに適しています。

@PWaliaDevは、シェルの一部であるさまざまなItemsコレクションを介してそれを行います

Shell.Items.Add（new ShellItem（））
new ShellItem（）。Items.add（new ShellSection（））
new ShellSection（）。Items.Add（new ShellContent（））

この問題を修正したかどうかを推測していますが
https://github.com/xamarin/Xamarin.Forms/issues/5428

それはあなたのシナリオに合うでしょうか？

@ PureWeen-リンクごとに表示オプションを設定しましたが、私が苦労しているのは@BeleShewが扱っているものに近いです（ユーザーごとにフライアウトアイテムを作成/削除します）

＃5428を修正すると、私が達成しようとしていることに適合します。

私のアプリには多数の役割/アクセス権を持つユーザーがいて、プログラムでメニューオプションを許可されているユーザーにのみ表示する必要があります（ユーザーに_できないこと_を見せたくないので、できることだけを表示します。

私はこれで遊んでいますが、メニューオプションを調べて、このコードのように非表示にするのではなく追加することが可能かどうかを判断しようとしています（ただし、すべての可能なルートとメニューオプションを繰り返し処理する必要があります。ロード時間：

foreach (var item in this.Items)
        {
            if (item is FlyoutItem)
            {
                var removeSections = new List<ShellSection>();
                var fi = item as FlyoutItem;
                foreach (var child in fi.Items)
                {
                    if (child.Route == "NOT_AUTHORIZED_KEY")
                        removeSections.Add(child);
                }
                foreach (var s in removeSections)
                    fi.Items.Remove(s);
            }
        }

シェルは理論的には優れていますが、これらがなければ実用的には機能が必要です。

1. ユーザーの役割に基づいてシェルアイテムを動的に追加/削除します
2. ログイン/ログアウトシナリオまたは条件に基づく2つの別々のナビゲーションルート。
3. オプションで、Prismなどの他のMVVMフレームワークのサポート

機能1と2が提供されるまで、ビジネス指向のアプリでシェルを使用することはできません。

@ Im-PJなぜ1と2が不可能だと思いますか？ （確かにそうです）

3は進行中であり、ここで追跡され

アプリシェルタブからタップイベントを取得できるかどうか誰かが知っていますか？
関連するフォーラムの質問： https ：

@ Im-PJに完全に同意し、これらの機能が具体的にどのように提供されていないかを理解していません。 これがShellのようなツールの主な理由です。 誰でもスライドアウトメニューを作成できます！

@dotMortenは、広範なC＃とハッキングを介して1または2を実行できる可能性がありますが、実行時にシェルアイテムをバインド/無効化/非表示/追加する例や言及はありません。 動的機能がこのツールの主要な目標だったようです。 XML表現をいくつかのパス機能とともに作成することは、マーケティング担当者に提供するには最小限ですが、実際のフル機能のモバイルアプリで実際に使用するには十分ではありません。

@ Im-PJ

これらの違いについて少し詳しく説明していただけますか？

ユーザーの役割に基づいてシェルアイテムを動的に追加/削除します
ログイン/ログアウトシナリオ

現在、ログインページを表示している場合は、TabBarを使用するか、フライアウトナビゲーションを非表示にすることで、ログイン/ログアウトシナリオを実行できます。

<TabBar Route="LoggedOut">
<LoginPage>
</TabBar>

<FlyoutItem Route="LoggedIn"></FlyoutItem>
<FlyoutItem></FlyoutItem>
<FlyoutItem></FlyoutItem>
<FlyoutItem></FlyoutItem>

ログインページを表示している場合、移動する唯一の方法はコードを使用することです。

IsVisibleバインド可能プロパティを公開するための作業がここで行われています
https://github.com/xamarin/Xamarin.Forms/tree/shell_isvisible

PRを作成する前に少し調整する必要があります

条件に基づいた2つの別々のナビゲーションルート。

あなたがやろうとしていることと現在できないことの例を教えてください。

Xamarin.Formシェルを使用しています

リンクサンプル： https ：

私を助けてください。 [概要]ページにタブバーを表示するにはどうすればよいですか？

同時に2つのシェルページが必要です。
ホーム、設定、ログアウトなどのページを含むレイアウトメニュー用の1つ
自宅からプッシュする必要があるタブ付きページ用の1つ
今のところ、私は「古い方法」を使用する必要があります

同時に2つのシェルページが必要です。
ホーム、設定、ログアウトなどのページを含むレイアウトメニュー用の1つ
自宅からプッシュする必要があるタブ付きページ用の1つ
今のところ、私は「古い方法」を使用する必要があります

Tabbedpageを使用している場合、Flyoutを表示できません。 今回はフライアウトとタブバーを見せたいです。

私はすべてのページをページにタブバーが表示されるようにしますが、タブバーに4つの要素のみを表示したい（[その他のタブ]を表示したくない）。 どうすればいいですか？

<shell>
<flyoutitem route="animals" flyoutdisplayoptions="AsMultipleItems">
<shellcontent route="cats"/>
<shellcontent route="dogs"/>
<shellcontent route="monkeys"/>
<shellcontent route="elephants"/>
<shellcontent route="bears"/>
<shellcontent route="about"/>
</flyoutitem>
</shell>

同時に2つのシェルページが必要です。
ホーム、設定、ログアウトなどのページを含むレイアウトメニュー用の1つ
自宅からプッシュする必要があるタブ付きページ用の1つ
今のところ、私は「古い方法」を使用する必要があります

Tabbedpageを使用している場合、Flyoutを表示できません。 今回はフライアウトとタブバーを見せたいです。

ページにタブバーが表示されるようにすべてのページを配置しましたが、タブバーに4つの要素のみを表示したい（[その他のタブ]を表示したくない）。 どうすればいいですか？

<shell>
<flyoutitem route="animals" flyoutdisplayoptions="AsMultipleItems">
<shellcontent route="cats"/>
<shellcontent route="dogs"/>
<shellcontent route="monkeys"/>
<shellcontent route="elephants"/>
<shellcontent route="bears"/>
<shellcontent route="about"/>
</flyoutitem>
</shell>

残念ながらシェルは使えません
同じアプリにMasterDetailPageとTabbedPageがまだあります（iOSでは、Naxam.TopTabbedPage.Formsプラグインを使用してトップタブページがあります）
これは私の古いチケットでした