Monotouch CodeのMonodroidアプリの再利用

Question

私は現在、最終的にモノドロイドに移植されるMonoTouchアプリケーションを実装しています。アプリケーションは、ODATA Webサービスのクライアントにすぎません。あまりにも派手なものやパフォーマンスが重要ではありません。

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

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

今私の質問：

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

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

ありがとう、

エイドリアン

Answer 1

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

私は後者を言うでしょうが、あなたは間違いなくあなたのビジネスとドメインのオブジェクトの大部分を再利用することができます。同じ単一sqliteがモノドロイドで使用されているため、アプリのデータ永続性部分（それを使用する場合）は再利用可能です。

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

別の例は、listViews（uitableViews）です。それらは完全に異なっています。ご想像のとおり、モノドロイドの実装は、その醜いジャバの姉妹に忠実です。 Androidでは、Appleが強制する間接的な巨大なもつれを使用する必要はありませんが、データソースとしての単純なArrayAdapter - より複雑なレイアウトのためにサブクラス化されます。

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

Androidは、XAMLとWebに似たレイアウトメカニズムを提供します。iPhoneでは、すべてが絶対に位置付けられているため、それほど幸運ではありません（または、それをどのように見るかによって、より幸運です）（常に320x480であるため、これを行うことができます）。

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

データのための個別のレイヤーとコントローラーに固執することで、ほとんどのレイヤーが覆われていると思います。アプリを見ることなく、コントローラーを簡単に再利用できるか（uitableviewsまたはcustom UISを使用するかどうか）言うのは難しいですが、Androidの開発は非常に高速で、簡単なタスクになるはずです。

_{（私はMonodroidプレビューを使用しており、MTアプリも出ています）}

Answer 2

そこにはかなり堅実な概念があるように聞こえます。実際、Monocross（http://code.google.com/p/monocross/）と呼ばれるオープンソースプロジェクトがあります。MVCパターンを使用して同様のことを行います。

ミゲル・デ・イカザは、あなたを助けるかもしれない非常にクールなMVVMプロジェクトのように見えるものを分岐しました。 https://github.com/migueldeicaza/monotouch.mvvm

Answer 3

プレゼンテーションレイヤー、ドメインモデル、サービスレイヤー、リポジトリ、および共通のMVCパターンを正常に実装しました。 NetworkConnectionManager（私の名前）などのプラットフォーム固有のコードが必要な場合（私の名前）#if #endifを使用してオブジェクトをラップするか、ユニットテストを行う必要がある場合、すべてのユニットテストにコンソールアプリを使用します。 Android、iPhone、およびWindows Phoneのプロジェクトとしてプロジェクトを除き、すべてのユーザーインターフェイスプラットフォーム固有のCRUDであるUIレイヤーを除外します。また、コンソールにコンソールの定義でタグを付け、AndroidプロジェクトをAndroid定義でタグ付けして、#if #endifを実行できるように

MVCレイヤー全体をコンソールにユニットテスト下に置いてAndroidの下で動作させることができれば、それがうまくいくと言わざるを得ません。インターフェース。これは、プレゼンテーションレイヤーの一般的性をテストするのに最適な方法です。このアプローチを取り入れているが、私はこのアプリケーションを長時間サポートする予定かもしれません。また、Androidタブレット、iPad、Windows 8フレームワークに移植する予定です。 。

MVPパターンを試みましたが、この状況では機能するほど柔軟ではありませんでした。さまざまなフレームワークも試しましたが、フレームワーク全体をカスタム開発することになり、最も柔軟性が得られます。決して些細なことではありません。抽象化、ジェネリック、オブジェクト指向のデザインをあまり徹底的に把握していない場合、より簡単なアプローチを提案したり、あなたの人生を機能させようとしています。

前述のように、Androidには多くのインとアウトがあります。たとえば、Androidで遭遇した最大の問題は、マルチスレッドまたは非同期操作とアクティビティの回転です。それとともに。私は自分ですべての回転構成を管理するパスを選択しました。つまり、すべての引き分けとアクティビティで使用されるリソースを手動でクリーンアップする必要があります。

Answer 4

私は同様のことをしようとしました - 私の場合、私はできるだけ多くのコードでVSとすべてのWindows開発ツールを使用したいと思っていました。

ただし、モデルレイヤーを「ジェネリック」にするだけで、MACでUIレイヤー（コントローラーとビュー）を実行することに戻りました（モノデベロムのコントローラーとビュー）。関係する努力は、私が取り組んでいた比較的小さなアプリケーションの過剰なことでした - そして、私だけがそれに取り組んでいました。

また、iPhoneやAndroidを初めて使用する場合、比較的洗練されたことをしようとすると、サンプルを見つけることや質問への回答を得ることがより困難になります。私は自分自身のために人生を難しくしていることがわかりました（確かに私のiPhoneの仕事の初期の時代に）。

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

Answer 5

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

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