以前からのアドバイスは今でも正しいです。
これは、Android、WP7、および iOS に非常に簡単に組み込むことができるようです。
私が間違っているか、何かが欠けている可能性がありますが、過去にこれを構築しようとしたとき、単純さがすぐに複雑になったようです:(
1 つの特定のケースでは単純に見えるかもしれませんが、一般的なフレームワークでは、ピボット、タブ、ポップアップ、モーダル、分割ビューなどを使用する場合など、考慮すべき他の多くのケースがあり、これらの複数のケースでは、標準的なアプローチは適切ではない可能性があります。完全にユニバーサル。
特に iOS では、この種の検出が非常に困難になることがあります (特に、UIViewController が NavigationController 内にある場合とない場合がある一般的なケースでは)。
もっと簡単にできるのは、ビューが表示されているかどうかのイベントを検出して通知することです - しかし、それでも完全に単純ではないようです - iOS では ViewDidDisappear が呼び出されない場合があります - さらに、これらのイベントは単にアプリが応答する必要があるものではありません...
必要なのはホイールだけのように感じるかもしれませんが、明らかな事実として、普遍的なホイールは 1 つではありません。ホイールにはさまざまなスタイルやサイズがあります。私は今、非常に多くの MvvmCross アプリを見てきましたが、標準的なアプリがどのようなものかはまだわかっていません。あるアプリで「明らかに」適切な設計とアーキテクチャであるものは、他のアプリで採用されているアプローチとはまったく異なって見える場合があります。
一般に、個々のアプリがこの種の機能を必要とする場合、これは非常に明確に定義されたシナリオ (たとえば、既知のプレゼンテーション フレームワーク内の既知のビュー タイプ) であると思います。そのような場合、そのアプリ シナリオのためだけに何かを実装することは、当時のアプリ開発者にとって非常に簡単なことだと思います。また、これらのシナリオのいくつかは、いくつかのアプリ間で共有できるのではないかと考えていますが、1 つのコード パターンがすべてに、または多くのアプリに適合するかどうかはわかりません。
ユーザーがブログを書いたり、github-post、またはフォーラムでこの分野での経験について書いているのを見て、私はとてもとても嬉しく思います。http://www.gregshackles.com/2012/11/returning-results-from-view-models-in-mvvmcross/などのブログ投稿では、Mvvm にパターンを適用して再利用する方法を示しています。
そのようなブログ投稿から、コア mvvmcross (およびその他の) ライブラリ内でより多くの機能を取得する方法を見つけることさえあるかもしれませんが、コア ライブラリを可能な限り軽く、柔軟で、拡張可能に保つことも重要です。
あなたのような人々がクロスプラットフォームの mvvm 体験について話しているので、私はリンク ページを最新の状態に保つために最善を尽くしています - http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html - 願わくば人々がアイデア、コンセプト、コードを共有するのに役立ちます。