Xamarin.forms: Uwp Xamarin.Forms.Shell

現時点では、シェルのサポートはAndroidとiOSでのみ提供されています。 将来のUWPサポートの可能性に関するフィードバックを継続的に評価しており、利用可能になり次第、より多くの情報を提供する予定です。

私は通常、電話ユーザーにはiOSとAndroidを使用し、タブレットとデスクトップユーザーにはUWPを使用しています。 したがって、UWPをサポートすることは、Windowsユーザーの関心を維持するために非常に重要です。

何？？ MSは本当に独自のプラットフォームを捨てています。 これは聞いて悲しいです！

UWPサポートがいつ提供されるかについての可視性はありませんか？ それとも、すでに決定が下されていますか？

UWPのシェルサポート-お願いします！

シェルのUWPサポートも見たいです。

私の会社にとって、UWPは非常に重要です。なぜなら、お客様はWindowsタブレットをいくつかのAndroidスマートフォンと組み合わせて使用​​して、作業を完了できるからです。 UWPサポートがない場合、シェルに移行することはできません。

同意しました-UWPとの互換性により、モバイル実装でWindowsタブレット機能を組み込むことができます。 私はそれなしでこれを完全に別々にコーディングしなければならないでしょう。 うん！ UWPの互換性は必須です！

私はまだShellを使っていないので、それが理にかなっているかどうかはわかりません。 ただし、UWPの実装にアプリの他のすべての要素（シェル以外）を使用する方法があるかもしれません。 結局のところ、TabbedPageとMasterDetailPageを使用しても同じことが達成されるようです。

また、シェルでUWPを使用する機能にも投票します。

UWPをお願いします...または少なくとも数年間信頼できるMicrosoftUXAPIの一部です。 「後でサポートするかどうかをお知らせします」というこのアプローチは、単なる意味です。

したがって、はい、UWPまたはそれをサポートするものは何でもありますが、もっと重要なのは、いつかどうかを知るためのコミットメントです。

その確実性なしにシェルに移動することはできません。

UWPだけでなくMacOSもお願いします。

UWPは、開発者によってまだ広く使用されているプラ​​ットフォームであるだけでなく、AndroidおよびiOSベースのXFアプリを起動して実行するための最速の方法でもあることに気付いたかどうかはわかりません。 比較すると、AndroidとMacの両方の世界に提供されているエミュレーターは非常に遅く、問題が発生しやすく、恐ろしい認証の経験や、実際のMacを持ち歩くことを余儀なくされていることについて話さないでください。 したがって、結局のところ、本物での開発に取って代わることはできませんが、UWPアプリは、…物事を…実行するための高速で簡単かつ包括的な方法を提供することにより、開発者の生産性を向上させます。 そして、iOSとAndroidでもアプリを起動して実行するために必要なことを実行します。

では、UWPのシェルサポートを追加していただけませんか？

https://github.com/xamarin/Xamarin.Forms/pull/6015

@Mephisztoeに同意して

Xamarin.Formsをモバイルプラットフォームのみに委任しないでください。 特にUWPだけでなく、WPFとGTK＃も引き続きサポートしてほしいと思います。

したがって、基本的に、Xamarin Formsの3つのプラットフォームすべてにクロスプラットフォームであるアプリを持っている人は、これらの機能を更新して使用することはできません。 Xamarin Forms for UWPの将来の開発が行われない場合は、クロスプラットフォームリストからUWPを削除しないのはなぜですか？

プラットフォームが異なれば、優先順位も常に異なります。 結局のところ、あなたは「7つのプラットフォームすべて」ではなく「3つのプラットフォームすべて」と言ったのです。

@GalaxiaGuyそうです、私が7つのプラットフォームと言ったら、架空のプラットフォームを構成することを考慮して、3つのプラットフォームすべてを言いました。 Xamarin.Formsのドキュメントによると：

Xamarin.Forms
Xamarin.Formsは、.NET開発者向けの完全なクロスプラットフォームUIツールキットを公開しています。 Visual StudioでC＃を使用して、完全にネイティブなAndroid、iOS、およびユニバーサルWindowsプラットフォームアプリを構築します。

そして、readmeには次のように書かれています。

Xamarin.Formsは、iOS、Android、Windows、およびmacOS用のネイティブアプリを完全にC＃ですばやく構築する方法を提供します。

これは、GTK、WPF、Tizenもサポートしていないという意味ではありません。

これらのプラットフォームはおそらくUWPよりも重要ではないことに同意しますが、UWPはiOSやAndroidよりも重要ではないと考える人がたくさんいます。

私は一般的に感情に同意しますが、UWPにないため、新しい機能を自分で無視する必要があります。

参考までに、リリースノートを間違って読んでいない限り、4.1プレビューにはTizenのShellRenderer実装があるようです。 UWPについての言及はありません。

@dotMortenからのプルリクエストがマージされるまでに時間がかかる場合は、誰かがその実装を取得して、公式サポートが得られるまで、コミュニティが管理する別の「プレリリース」NuGetパッケージに移動する可能性があります。 そうすれば、Xamarin.Formsの完全なプレリリースまたはカスタムビルドを使用せずに使用できます。 公式のサポートがない場合は、リポジトリがすでに設定されており、コミュニティが引き継ぐことができます。

申し訳ありませんが、これは速く動きませんでした。 マスターと同期するときにいくつかのリグレッションが発生し、仕事や家族関連のもので完全に圧倒されたので、実際に座ってそれに対処する時間があまりありませんでした。 しかし、私は自分の支店のPRを喜んで受けています。

また、UWPで利用可能になり次第、シェルを使用します。 上記と同じ問題があります。 アンドロイドとウィンドウズの両方を備えたタブレット、電話、ノートブックが混在しています。 また、最適な開発環境はUWPだと思います

この問題は、私がXFをあきらめた主な理由の1つです。 お客様にとって、デスクトップとモバイルは同じ優先順位を持っています。

まだ言われていないことは何と言えますか..

だからそれを手に入れよう！
UWPのサポートはMicrosoftにとってオプションではありません。本当にこれを伝える必要がありますか？

@papiermache行動規範は、このプロジェクトに関するすべてのコミュニケーション、問題、コメントに適用されることに注意してください

また、これを開発者に対するMSXamarinの取り組みのテストとして扱います。 MS側の誰かが体重を量る準備ができていますか？

申し訳ありませんが、さらなる考えを和らげるでしょう…しかし、UWPサポートの欠如を発見したことに私は完全に驚かされました。UWPが最初から含まれているプラ​​ットフォームではないということさえ私には思い浮かびませんでした。 リック。

投稿者：ジェレミー[email protected]
送信日：2019年8月16日14:28
宛先：xamarin / Xamarin.Forms [email protected]
Cc：Rick Piovesan [email protected] ; 言及@ noreply.github.com
件名：Re：[xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell（＃5593）

@papiermache https://github.com/papiermache行動規範は、このプロジェクトに関するすべてのコミュニケーション、問題、コメントに適用されることに注意してください

—
あなたが言及されたので、あなたはこれを受け取っています。
、直接このメールに返信GitHubの上でそれを見るhttps://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 、またはスレッドミュートhttps://github.com/を通知/ unsubscribe-auth / ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A 。

こんにちは@dotMorten 、あなたは何か更新を与えることができますか？ あなたはまだUPW + Shellを動作させることを試みることを計画していますか？ それが親切でコミュニティの行為であることを理解してください:)あなたの努力はShell + UWPを機能させることに最も近いように思われるので、ただ疑問に思っています。 MicrosoftがXamarinでのWindowsサポートから離れてピボットしているように見えることにまだ完全に不思議に思っています。 他のすべての良さに感謝しますが、それでも当惑し、イライラします。

ごめん。 ある種の燃え尽き症候群なので、私はこれを再訪していません。 最新の原因となる多くのリグレッションとマージしたことを覚えていますが、それを元の速度に戻すための時間もエネルギーもありませんでした。 また、変更が必要であり、XFチームからの幅広い賛同が必要であるが、「それを調べてみよう」以外のサポートはあまり得られなかったものをいくつか特定し、その後消滅しました。 一般的に、私がXFチームから得たサポートとフィードバックは、励ましにすぎませんでしたが、フォロースルーが少し不足していました。 私が行った作業についてのフィードバックをまだ待っていますが、現時点ではおそらく時代遅れです。 うまくいけば、私はすぐにそれに戻るための時間とエネルギーを持っているでしょう。

この問題は現在、最もコメントの多いオープンアイテムのトップ10に入っていますが、完了するためのロードマップには含まれていません。

@pauldipietroこれに関する最新情報を入手できますか？ UWPサポートがXFチームの優先事項ではなくなったというシグナルを送信しているように見えます。 それが本当なら、私たちがその周りの計画を立てられるように、私たちに教えてください。

ありがとう

同意しました。XFにWindowsサポートが含まれないかどうかを知りたいだけです。 そうでなければ、私もなぜそうしないのか知りたいですか？ 彼らは、「次の」Windows UXスタックがUWP以外になり、サイクルを無駄にしたくないことを知っていますか？ 次の作品はBlazor / HTMLのものになるのでしょうか？ もしそうなら、私が移行できるように私に知らせてください...多分unoプラットフォームに？

投稿者：スコットKuhl [email protected]
送信日：2019年8月22日木曜日午後1時21分22秒
宛先：xamarin / Xamarin.Forms [email protected]
Cc：David Gerding [email protected] ; コメント[email protected]
件名：Re：[xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell（＃5593）

この問題は現在、最もコメントの多いオープンアイテムのトップ10に入っていますが、完了するためのロードマップには含まれていません。

@pauldipietro https://github.com/pauldipietroこれに関する最新情報を入手できますか？ UWPサポートがXFチームの優先事項ではなくなったというシグナルを送信しているように見えます。 それが本当なら、私たちがその周りの計画を立てられるように、私たちに教えてください。

ありがとう

—
コメントしたのでこれを受け取っています。
、直接このメールに返信GitHubの上でそれを見るhttps://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 、またはスレッドミュートhttps://github.com/を通知/ unsubscribe-auth / AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A 。

率直に言って、最善の策は実際にはXFをUnoプラットフォームに置き換えることだと思います...

Xamarinは、ターゲットが主にモバイルデバイス（電話、タブレット、時計）であり、デスクトップやラップトップではないことを明らかにしました。

彼らはUWP自体をサポートおよび維持することに関心がないので、それは私が顧客に勧めるのは良くありません。

自分の必要性を明確にしたいと思います。Xamarinフォームには_UWP_は必要ありません。 Xamarinフォームには_いくつかのWindowsターゲット_が必要です。 UWPは最も実行可能な候補のようです。 私が推測しなければならなかった場合、Microsoftは最終的にデスクトップ用のHTMLおよびBlazorクライアントにパントして行きます。これは、Windows後の世界で最も広いUXリーチを提供する可能性があるためです。 これは、コンポーザブルシェル（xfシェルではない）パスにも適している可能性があります。 UXのWindows側の一貫したロードマップがない場合、他に何を計画しているのか想像できません。

しかし、明確にするために、「ウィンドウを実行しないでください」という大きな太字でアナウンスせずにXamarinのWindowsサポートを削除することは、最低限、本当に、本当に不親切です。 「古いマイクロソフト」の鳴り響き。

@davidortinau et al：現在事実上死んでいる（ @dotMortenの最新の投稿を参照）「XFシェル+ Windowsのコミュニティサポート」を指摘する以上のことをしてください。

Xamarinのすべての新しくてクールなものにとても感謝しています。 しかし、Xamarinを使用するWindowsターゲットの将来の実行可能性について、より正直な回答が必要です。

変更する必要があり、XFチームからの幅広い賛同が必要ないくつかのこと

これらの1つがWinUIに関係していることを私は知っています。これは、このPRの依存関係として取り込むことを望んでいます。
https://github.com/xamarin/Xamarin.Forms/pull/7214

そのPRは16299の互換性を維持しており、私のテストでは、それがnugetに含まれていて、ユーザーがWinUIをインストールする必要がない場合にうまく機能します。 確認するために、VMで16299をスピンアップする必要がありますが、楽観的です。 @dotMortenが

これがそのナゲットです。

Xamarin.Forms.4.3.0.1853.zip

他の誰かが私たちのためにそれをテストして、本当に役立つ問題があるかどうか私たちに知らせたい場合。 基本的なUWPテンプレートを使用してテストしましたが、クラッシュすることなく正常に動作します。

これについて私が現在見ている道は

• WinUIの依存関係を処理するために、＃7214をマージします
• UWPシェルPRをリベースします（これは将来のスプリントで予定されているので、その時点で実行するか、他の誰かが私たちを打ち負かした場合に実行します）
• モーテンはすでに腹足類で動作しているので、さらにいくつかのサンプル（主にXaminals）でテストしたいのですが、動作し、必要なコードクリーンアップの変更を加えたら、マージします

そのパスで何かが足りない場合はお知らせください。対処しようとします。そのため、必要なのはリベースとXaminalsに対する検証だけです。

@PureWeen 、
提供されたXamarinNugetを使用してApp132.zipを実行できます。 アプリは正常に動作しているようです...タイムスタンプ付きの要素をリストコントロールに追加することになっていると仮定します。 上部のボタンとPulltoRefresh動作の両方で要素が追加されます。

私が何を探しているのかわかりませんが、私はあなたの努力に感謝し、私ができる限り助けようとします。

デイブG

@PureWeenあなたがWinUIで前進しているのを見るのは素晴らしいことです。 WinUIが推移的に追加されなかった依存関係を追加していたため、WinUIへの依存関係は私にとって破壊的な動作を生み出していました。 これはVS2019を使用している場合は修正可能ですが、WinUIがその機能をまだ利用しているかどうかはわかりません（VS2017ユーザーには引き続き影響しますが、少なくとも回避策があります）。
さらに、WinUIには多くの頭痛の種となるバグがありましたが、最近、ログに記録したもののいくつかが修正されていることに気づきました。それはすべて励みになります。 7214が入ったら、私にpingを送信してください。この取り組みを開始します。
また、リベースのサポートが大好きです。 前回それをしたとき、私はこのPRを完全に台無しにしました:-)

@dotMortenいいですね！

私はVS2017で上記に含めたアプリをテストしましたが、それは私のために機能したので、私たちはその面で大丈夫だと思います

私が何を探しているのかわかりませんが、私はあなたの努力に感謝し、私ができる限り助けようとします。

主なことは、メインのUWPプロジェクトにナゲットを追加し、それらがすべて正常にコンパイルおよび実行されているように見えることを確認することです。

WINUIの依存関係を追加しても、頭痛の種にはならないことを確認しようとするだけです:-)

上記のアプリをVS2017でテストしました

WinUIをプロジェクトヘッドに追加せずに？ それが私が見つけた問題です。WinUIに依存するバージョンのXFにアップグレードする場合、WinUIに依存関係を手動で追加しないと機能しません。 私見それは画期的な変化です。 WinUIはパッケージを変更して暗黙的に機能するようにすることができますが、NuGet 5.0機能に依存しているためVS2019が必要になります（そして、この変更を行っていないため、現時点ではどちらでも機能しません）。

WinUIにログインした問題は次のとおりです： https ：

VS2019ユーザーが手動で追加の依存関係を追加する必要がないように、少なくともそれに対処するための簡単なPRを作成するだけかもしれません。

私がapp123をテストしたとき、それはVS2019であったことを追加するだけです。

WinUIをプロジェクトヘッドに追加せずに？

上でリンクしたプロジェクトはVS2017内で開くことができ、コンパイルして正常に実行されます。 WinUI nugetをUWPヘッドに追加していません。これは、nuspec内の依存関係としてのみ示されています。

私はそれがどのように機能するのか本当にわかりません。 追加する必要のあるスタイルと、パッケージと一緒にインストールする必要のある追加のappxフレームワークパッケージがあり、それはすべて.targetsによって実行されます。 フレームワークパッケージはすでにマシンにインストールされていますか？

Visual Studio Magazineは、特にこの問題を取り上げました。 マイクロソフト、正式な回答の時間です。

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

@dotMorten私は数日間外出していますが、戻ってきたらそれを調べます。 WinUIチームにも確認を依頼しました

VS 2017でテストした場合、このターゲットは推移的に正常に実行されます
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

これは、ローカルフォームプロジェクトの設定を上書きできる更新されたNugetです。
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

フォームプロジェクトでは、これを強制的に実行して、人々を驚かせないようにしました。

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff -5e6292d5925c776aa9aa6d6f8c63ddf6R19

@PureWeenこれは、これらの行を明示的に追加しなくても機能するはずのビットです（すべてのユーザーがプロジェクトヘッドも更新する必要があるため）。

あなたはそれがうまくいくと言っていると思いますが、私たちが同じページにいることを確認してください。

これは許容できる重大な変更だと思われるかもしれませんが、アップグレードパスは新しいXFバージョンを選択するほどクリーンではないため、これは最近別の依存関係で発生し、多くの人を失望させたのを思い出します。

Re：Xamarinフォームのデスクトップ/ラップトップ/タブレットターゲットの必要性

企業環境でモバイルアプリを構築している私たちにとって、Android / iOSベースと同じ基本コードベースから「仕事に似た」デスクトップ/ラップトップ実行可能ファイルを作成する機能は不可欠です。 Windowsのみである必要はありません（HTML / JSなどのブラウザベースのターゲットでも同様に優れています）が、ユーザーの大多数はWindowsデスクトップ/ラップトップ+ iPhone / Android電話を使用しているため、Windows実行可能ファイルはほとんどの場合は問題ありません。

組織内でモバイルアプリを利用できるようにする場合、ユーザーの大多数は最初にラップトップ/デスクトップで試してみたいと考えています。そして、それが有用であるか、ニーズに適切に適合していると判断した場合にのみ、彼らの電話でそれ。 また、特定の瞬間にどこで作業しているかに応じて、デスクトップまたはデバイスのいずれかからデータを入力したり結果をクエリしたりできる場合、ユーザーの賛同（およびフィードバック）を得るのは非常に効果的です。

Xamarin Formsはこれらのシナリオでうまく機能し、ShellとCollectionViewを使用したいのですが、デスクトップ/ラップトップを同様に作成するために使用できるようになるまで、これらはシェルフウェアです...

@dotMortenなので、例外が表示されない理由は、WinUIがnugetに依存しているためです。したがって、XFをUWPヘッドにインストールすると、WinUIがそれに乗って、そのターゲットを適用します。

これにより、XFパッケージ自体をUWPヘッドプロジェクトにインストールして機能させる必要があります。 XFをnetstandardプロジェクトにのみインストールして上記の例をテストし、例外を再現することができました。

これについては、この号で少し話しました。
https://github.com/xamarin/Xamarin.Forms/issues/4126

共有ライブラリにXFのみがインストールされていて、UWPヘッドプロジェクトがインストールされていない場合、これは問題になります。 したがって、これについて少し話し合って、これについて何をしたいのかを確認する必要があります。

@pureweenわかりました。 その時も同じことが起こってうれしいです。 ディスカッションで考慮すべきいくつかのこと：

• WinUIのPRがマージされると、VS2017ユーザーにのみ影響します（ただし、チームが両方を使用し、一部のユーザーにのみ影響する場合は、奇妙になる可能性があります）。
• Init（）中にこれを検出し、ユーザーに何をすべきかを正確に伝えるエラーをスローして、痛みがそれほどひどくないようにすることができます。
• XFには、参照プロジェクトに依存関係を追加するターゲットファイルがまだ存在しない場合はそれを追加するという考えをいじっていましたが、
  奇妙な開発体験を作成します。
• WinUIがプラットフォームから分離されると、すべてのUWPプロジェクトは常にこの依存関係を使用します（ただし、それまでにVS2017はおそらくサポートされなくなります）。
  
  
  
  • この変更により、Win10の下位バージョンをサポートできるようになり、それを正当化できる付加価値が作成されます。
  
  
  • あなたのチームによると、とにかく誰も実際にUWPを使用していないので、誰も気付かないでしょう😜j/ k
  
  

もう1つの可能なアプローチ：Init中にWinUIが参照されているかどうかを検出しますが、アプリは実行します。 WinUIに依存するレンダラーは代わりにスローするため、これらの新機能のユーザーにのみ影響します。 したがって、ストーリーは「ShellまたはPullToRefreshを使用する場合は、WinUIへの参照も追加する必要があります（VS2017を使用している場合）」になります。

@dotMortenシェルをUWPに導入するためのすべての努力に感謝します！ これは非常に必要であり、コアXamarinチームが対処する必要があります。

これが、CVとシェルを備えたUWPで実行されているXaminalsのテイストです!!!

すごい仕事！

素晴らしい仕事。 エンタープライズレベルのアプリケーションを構築するためのフレームワークに、リリースされ次第含めます。

素晴らしい仕事です。

はい、Xamarinでした！ ある男が宇野に引っ越すと言っているのを読んだ。 番号！！！！ Xamarinは私たちにとって素晴らしいものであり、swift + javaを習得するために多くの時間を節約できました。 チームに忍耐強く、彼らをサポートしましょう

＃6015で閉鎖

素晴らしい仕事、3未満のすべてのチームに感謝します、私はそれを回します💃

素晴らしい仕事、どうもありがとう！

OK、何か奇妙なことが起こっています。4.3.0.947036を使用するようにプロジェクトをアップグレードしましたが、forms.initを呼び出したときにプロジェクトが失敗します。
'Windowsランタイムタイプが見つかりませんでした' Microsoft.UI.Xaml.Controls.XamlControlsResources

非常に奇妙なのは、XamlTypeInfo.g.csで見つかったコードの量です。以前のバージョンのXamarinでは13エントリしかありませんでしたが、現在は43を超えています。プロジェクトにWin.UI Nugetをインストールしましたが、これでも実行できます。助けません。 何か案は

@ abrantie1z- （トピックから外れていますが、言及したいと思います）UnoフォームとXamarinフォームは相互に排他的な選択である必要はありませんhttps：/を参照してください/visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx警告：私はUnoを使用したことがないので、このサポートがどれほど堅牢であるかわかりません。 しかし、ブラウザのXFにもっと多くの人が興味を持つようになるものは何でも良いことです。