10

私は現在、最終的に Monodroid に移植される Monotouch アプリケーションを実装しています。アプリケーションは、OData Web サービスに対する単なるクライアントです。派手すぎたり、パフォーマンスが重要だったりすることはありません。

課題は、できるだけ多くのコードを再利用することです。Monotouch と Monodroid の UI API がかなり異なることは承知していますが、データ データの抽象化とビジネス レイヤーを再利用したいと考えています。

私の UI レイヤーは MVP パターンに従っているので、各ビューの抽象表現をコーディングして UI コントローラーを再利用したいと考えています。ただし、Monodroid ベータ版はまだ許可されていないため、これが機能するかどうかは推測できます。

今私の質問：

  • このアプローチについてどう思いますか？これは良い考えですか、それとも iPhone と Android の UI コンセプトの違いにより、平凡なアプリケーションになるだけでしょうか?

  • コードの再利用を最大化するためにアプリケーションを構築する方法に関するヒントを提供できますか?

ありがとう、

エイドリアン

4

5 に答える 5

15

このアプローチについてどう思いますか？これは良い考えですか、それとも iPhone と Android の UI コンセプトの違いにより、平凡なアプリケーションになるだけでしょうか?

私は後者だと思いますが、ビジネス オブジェクトとドメイン オブジェクトの大部分を間違いなく再利用できます。同じ Mono Sqlite が Monodroid で使用されるため、アプリのデータ永続化部分 (それを使用する場合) は再利用可能です。

中間層の UI をわざわざ作成するつもりはありません。この 2 つは完全に異なります。たとえば、Android アプリでは、画面に 6 つのボタンを含めることができる下部メニューがあります。iPhone では、タブ バーまたはツールバーに 6 つのボタンがない可能性が高くなります。そのための共通パターンを作成しても、あまり役に立ちません。

もう 1 つの例は、ListViews (UITableViews) です。それらは完全に異なります。ご想像のとおり、Monodroid の実装は、醜い Java 姉妹に忠実です。Android では、Apple が強要した複雑な間接処理を使用する必要はありませんが、単純な ArrayAdapter をデータ ソースとして使用するだけで、より複雑なレイアウト用にサブクラス化できます。

注意すべきもう 1 つの重要な点は、Android には 1 つの画面サイズがないことです。3 つの異なる画面密度の画像を作成します。フォント サイズは絶対的なものではありません。

Android は、XAML や Web と同様のレイアウト メカニズムを提供します。iPhone では、一般的にすべてが完全に配置されている (常に 320x480 であるため、これを行うことができる) ため、それほど幸運ではありません (見方によっては、より幸運です)。

コードの再利用を最大化するためにアプリケーションを構築する方法に関するヒントを提供できますか?

データ用の別々のレイヤーでほとんどをカバーし、コントローラーに固執していると思います。アプリを見なければ、コントローラーの再利用がどれほど簡単かを言うのは難しいです (UITableViews を使用するか、カスタム uis を使用するかに関係なく)。

(私は Monodroid のプレビューを行っており、MT アプリも公開しています)

于 2010-09-21T10:36:06.760 に答える
7

そこにはかなりしっかりとしたコンセプトがあるようですね。実際、MonoCross (http://code.google.com/p/monocross/) と呼ばれるオープン ソース プロジェクトがあり、MVC パターンを使用して同様のことを行っています。

Miguel de Icaza は、非常にクールな MVVM プロジェクトのように見えるものをフォークしました。https://github.com/migueldeicaza/MonoTouch.MVVM

于 2011-09-01T03:14:44.367 に答える
3

プレゼンテーション レイヤーの MVC パターンの実装に成功しました。ドメイン モデル、サービス レイヤー、リポジトリ、およびコモンはすべてプラットフォームに依存しません。NetworkConnectionManager (私の名前) などのプラットフォーム固有のコードが必要な場合は #if #endif を使用してオブジェクトをラップするか、ユニット テストを行う必要がある場合は、すべてのユニット テストにコンソール アプリを使用しますが、まったく同じです。 Android、iPhone、および Windows Phone プロジェクトと同じようにプロジェクトを作成する必要がありますが、ユーザー インターフェイス プラットフォーム固有のすべての要素である UI レイヤーは省略しています。また、コンソールに CONSOLE define をタグ付けし、Android プロジェクトに ANDROID define をタグ付けして、#if #endif を実行できるようにします。

MVCレイヤー全体をコンソールで単体テストにかけ、Androidで動作させることができれば、iPhoneとWindows Phoneで動作することが保証されているよりも、うまく機能すると言わざるを得ません。インターフェース。これは、プレゼンテーション レイヤーの汎用性をテストするのに最適な方法です。私が取っているこのアプローチはやり過ぎかもしれませんが、私はこのアプリケーションを長期間サポートする予定であり、Android タブレット、iPad、および Windows 8 フレームワークにも移植する予定であるため、IMO はこれを正しく行うために余分な時間を費やす必要があります.

私は MVP パターンを試みましたが、この状況では機能するほど柔軟ではありませんでした。私もさまざまなフレームワークを試しましたが、フレームワーク全体をカスタム開発することになりました。これが最も柔軟性が高いからです。決して些細なことではありません。抽象化、ジェネリック、およびオブジェクト指向設計を完全に把握していない場合は、より単純なアプローチをお勧めします。

前述のように、Android には多くの裏表があります。たとえば、私が Android で遭遇した最大の問題は、マルチスレッドまたは非同期操作とアクティビティのローテーションです。これにより、アクティビティが完全に破壊されて再作成され、ビューが消去されます。それと一緒に。すべてのローテーション構成を自分で管理する方法を選択しました。つまり、アクティビティで使用されるすべてのドローアブルとリソースを手動でクリーンアップする必要があります。

于 2011-08-31T17:57:51.707 に答える
2

私の場合は、できるだけ多くのコードに VS とすべての Windows 開発ツールを使用したかったためです。

しかし、私は単にモデル レイヤーを「ジェネリック」にし、UI レイヤー (コントローラーとビュー) を Mac (つまり MonoDevelop) で実行することに戻しました。私が取り組んでいた比較的小規模なアプリケーションにとって、これに伴う労力はやり過ぎでした。

また、iPhone や Android を初めて使用する場合は、比較的高度なことをしようとすると、サンプルを見つけたり、質問への回答を得たりするのが難しくなります。私は自分自身の生活をより困難にしていることがわかりました (確かに、iPhone の仕事を始めたばかりの頃はそうでした)。

もちろん、あなたのプロジェクトやビジネスモデルの内外を知らずに、具体的なアドバイスをすることは困難ですが、それらは私の経験であり、価値があるものです.

于 2010-09-09T10:02:59.280 に答える
0

少し遅れているかもしれませんが、このクロスプラットフォーム モバイル開発ビデオは非常に役に立ちます。また、Android と WP に移植される MT アプリも作成しています。データストレージについては、データモデルを完全に再利用可能にすることになっているVici CoolStorageを真剣に検討しています。さらに、プラットフォームに依存しないコードを、ソリューション内のユーティリティ プロジェクトと共通プロジェクトに移動しています。また、MD と WP で Web サービス通信コードを再利用できるようにしたいと考えています。残りは現時点では iOS 固有です。

あなたのプロジェクトがどのように進んでいるかを知ることは非常に興味深いでしょう。コードの再利用性は本当に効果があるのでしょうか?

于 2012-10-24T10:16:33.830 に答える