これは何ですか
Xamarinは、C＃言語を使用したモバイルアプリケーション（iOS、Android、Windows Phone）のクロスプラットフォーム開発のためのフレームワークです。 アイデアはとてもシンプルです。 LINQ、ラムダ式、ジェネリック、非同期などの通常の言語機能をすべて使用して、お気に入りの言語でコードを記述します。 同時に、SDKプラットフォームのすべての機能とUIを作成するためのネイティブメカニズムへのフルアクセスがあり、厳密に言えばネイティブのものと変わらず、（少なくとも保証によって）パフォーマンスが劣らないアプリケーションを取得します。
フレームワークは、いくつかの主要部分で構成されています。
- Xamarin.IOS-開発者にiOS SDKへのアクセスを提供するC＃のクラスライブラリ。
- Xamarin.Android-開発者にAndroid SDKへのアクセスを提供するC＃のクラスライブラリ。
- iOSおよびAndroid用のコンパイラ。
- IDE Xamarin Studio;
- Visual Studioのプラグイン。
詳細
しばらく前、JavaScriptを使用してHTML5でクロスプラットフォームモバイルアプリケーションの開発を提供する多くのフレームワーク（ PhoneGapなど ）が広く知られていました。 アプリケーションは、適切なjsライブラリ（Jquery Mobileなど）を使用して、モバイルデバイス用の通常のWebサイトとして開発されるという考え方です。 次に、これらはすべて、ユーザーにとってネイティブアプリケーションのように見えるコンテナにパッケージ化されます。 これらのフレームワークの欠点は明らかです。まず、UIのネイティブ要素にアクセスできません。 つまり、iPhoneの標準の「戻る」ボタンを使用する場合でも、描画して構成する必要があります。 次に、プラットフォームを操作するための一般化された切り捨てられたAPIを取得します。 したがって、特定のプラットフォームに固有の特定の機能は使用できません。 さて、3番目で最も重要なのは、そのようなアプリケーションが電話のブラウザー内（より正確には、WebViewコントロール内）で物理的に起動されることです。 これが何を意味するのかを長い間書く必要はありません：パフォーマンスの低下（WebViewは古いバージョンのAndroidでは特に「良い」）と大きな表示の問題（まあ、紳士、これはブラウザーです）。 もちろん、場合によっては、これらのフレームワークは非常に適切かもしれません。
Xamarinは何か他のものです。 なぜなら
アプリケーションの実行に関して、iOSとAndroidには1つの重要な違いがあります-プリコンパイルされた方法です。 ご存知のように、Androidでアプリケーションを実行するには、Dalvik仮想Javaマシンが使用されます。 Javaで記述されたネイティブアプリケーションは、中間バイトコードにコンパイルされ、プログラムの実行時にDalvikによってプロセッサ命令に解釈されます（つまり、.NETでのCLRの動作と同様）。 これは、いわゆるJust-in-timeコンパイル（オンザフライのコンパイル）です。 IOSは異なるコンパイルモデル-Ahead-of-Time （実行前のコンパイル）を使用します。 Xamarinは、これらのプラットフォームごとに別々のコンパイラーを提供することにより、この違いを考慮します。これにより、ブラウザーコンテキスト外で実行され、プラットフォームのすべてのハードウェアおよびソフトウェアリソースを使用できる実際のネイティブアプリケーションを取得できます。
iOSの場合、状況は単純です。仮想マシンはなく、プログラムコードは事前にマシンコードにコンパイルする必要があります。 この目的のために、AOTコンパイラーMonoが使用されます。
Androidの場合はさらに興味深い。 アプリケーションをコンパイルすると、C＃コードはMono仮想マシンが理解できる中間バイトコードに変換され、この仮想マシン自体もパッケージ化されたアプリケーションに追加されます。 MonoとDalvikは両方ともCで記述され、Linuxカーネル上で実行されます（AndroidはLinuxベースであることを覚えています）。 あなたはすでに何が起こっているかを理解しています。 Androidでアプリケーションを起動すると、両方の仮想マシンが並んで動作を開始し、特別なラッパーメカニズムを介してデータを交換します。
それはすべて良いことですが、開発に近づきましょう。
Xamarin.iOS（Monotouch）の例を使用して、ライブラリ自体について詳しく説明します。 Xamarin.Androidを使用するよりもはるかに多くの経験があります（ただし、すべてが同じです）。
Monotouch.dllクラスライブラリは、iOS SDKのすべての機能へのアクセスを提供します。 開発者にとっては、優れた注釈を付けたC＃クラスのコレクションにすぎません。 内部的に、これらのクラスはネイティブクラスおよびメソッドのバインディングメカニズムを開発したXamarinエンジニアを使用します。 同じメカニズムを使用して、objective-cで記述されたライブラリをバインドできることが重要です。 ほとんどのクラスとメソッドは、元のiOS SDKと同じように呼び出されますが、例外があります（この場合、バインディング属性に表示されるため、元の名前についてはXamarinドキュメントの検索を使用する必要があります）。 クラスでは、C＃イベントのメカニズムが積極的に使用されており、ラムダ式を使用してハンドラー用の美しくコンパクトなコードを作成できます。
button.TouchUpInside += (s, o) => { message.Text = "Hello!"; };
そして一般的に、C＃で記述されたコードは、はるかに読みやすく快適です。 属性を持つ文字列を作成するコードを使用して違いを確認してください。
非同期開発の場合、XamarinはSystem.Threading.ThreadおよびSystem.Threading.ThreadPool名前空間の両方のクラス、およびTask Parallel Libraryが提供するすべての機能を使用する機能を提供します。 ただし、後者を使用することをお勧めします。 さらに、執筆時点で、次の安定バージョンがリリースされました。このバージョンでは、特に.NET 4.5のサポートが登場し、特にasync / awaitキーワードを使用できるようになりました。 この機能は以前に利用可能でしたが、これにはベータ更新チャネルを使用する必要がありました。
制限は何ですか？
Xamarin.iOSの制限は、主に、上記のようにiOSには.NETやMonoとは異なり、仮想マシンがないという事実に関連しています。 したがって、Genericをサポートすることは困難です。 理由は明らかです。コンパイラのタスクは、コードを分析し、特定のクラスとメソッドで考えられるすべての具象化を決定することです。 したがって、次の制限が発生します。
- コンパイラーは全能ではなく、考えられるすべてのユースケースを考慮しない可能性があるため、Virtual Genericメソッドの使用は推奨されません。
- Objective-C階層のベースであるNSObjectクラスからGeneric子孫を作成することはできません。 細くて美しい建築物を何らかの形で台無しにする深刻な制限。
他の制限、たとえば、動的コード生成のサポートの欠如は、私の意見ではあまり重要ではありません。 これらの詳細については、iOSの場合とAndroidの場合をご覧ください 。
UI開発
Xamarinは、プラットフォームごとに、ネイティブUI開発ツールとネイティブユーザーインターフェイス要素を使用する機能を提供します。 Androidの場合、UIの作成はコード内で直接実行するか、XMLのインターフェイス記述を使用して宣言型アプローチを使用できます。 iOSの場合、コードまたはネイティブインターフェイスデザインツールの使用のいずれかです-個別のxibファイルまたは1つの大きなストーリーボード。 これらのファイルの編集は、iOS開発者にとって使い慣れたXcode環境で行われます。 そして、それはあなたがMacを必要とすることを意味します。 はい。iOSアプリケーションを開発するには、とにかく2つの理由でMacが必要です。
まず、私が言ったように、Xcode環境でUIを編集します。 第二に、アプリケーションのデバッグには、iPhone / iPadシミュレーターが必要です。これは、Macでのみ利用可能です。
コードの移植性
開発者によると、Xamarinはクロスプラットフォーム開発ツールです。 一度書かれたアプリケーションは、さまざまなモバイルプラットフォームで実行できることが期待されています。 しかし、この場合、前の段落と矛盾があります。 どうして？
実際、状況は次のとおりです。 プラットフォームごとに、独自のUIレイヤーを実装する必要があります。 つまり、アプリケーションの外観を担当するコードは、プラットフォームごとに個別に記述する必要があります。 これは、UIを操作するためにネイティブメカニズムを使用する機能の価格です。 アプリケーションをレイヤーに分割すると、次のスキームが得られます。
- データ層（DL）-SqlLiteベースまたはxmlファイルなどのデータストレージ。
- データアクセスレイヤー（DAL）-CRUD操作のリポジトリをラップします。
- ビジネス層（BL）-アプリケーションのビジネスロジックを含む層。
- サービスアクセスレイヤー（SAL）-リモートサービス（Rest、Json、WCF）との対話を担当するレイヤー。
- アプリケーション層（AL）-プラットフォーム固有のコードを含む層。言い換えると、monotouch.dllまたはmonodroid.dllライブラリに依存するコードです。
- ユーザーインターフェイスレイヤー（UI）-ユーザーインターフェイスレイヤー。
クロスプラットフォームは、すべてアプリケーション層の上にある層です。 移植可能なコードの割合は、アプリケーション自体に大きく依存しますが、私の意見では、50〜60％を超えることはほとんどありません。 Xamarinのエンジニアはこれを理解しているため、このシェアを増やすことを目指しています。 この問題を解決する成果として、Xamarin.Mobileライブラリを検討できます。 カメラ、連絡先、ジオロケーションを操作するためのさまざまなプラットフォームに単一のAPIを提供します。 ただし、このライブラリを使用しても、たとえばデリゲートメカニズムを使用するなど、プラットフォーム固有のAPIを使用することは制限されません。
サードパーティのコンポーネント
Xamarinには、独自のサードパーティコンポーネントストアであるXamarin Componentsがあり、IDEと統合して、Xamarinエンジニアとサードパーティ開発者の両方が作成したさまざまなコンポーネントを数回クリックするだけでプロジェクトに接続できます。 ところで、コンポーネントの数は飛躍的に増加しています。 有料版と無料版の両方があります（現時点ではほとんどがあります）。 すべてのコンポーネントは2つの部分に分けることができます。 追加のユーザーインターフェイス要素を提供するものと、クラスライブラリを提供するものがあります。 たとえば、Jsonと連携するための有名なライブラリのMonoオプションはJson.NETであり 、Restサービスとやり取りするためのライブラリはRestSharpです。 すべてのコンポーネントがクロスプラットフォームであるとは限りません;多くは特定のプラットフォームでのみ利用可能です。 上で述べたように、Xamarinはバインディングメカニズムを使用してネイティブクラスライブラリとリンクします。これにより、ネイティブクラスライブラリをC＃に移植できます。 さらに、たとえばXamarin.iOSには、このようなバインダーを自動的に生成できる特別なユーティリティがあります。 実際、これによりXamarinのエンジニアはiOSのすべての革新に遅れずについていくことができます。 そのため、特にXamarin.iOSでは、リリースのほぼ直後に、Dropbox APIとiOS 7の新しい機能を使用できるようになりました。
ドキュメントとコミュニティ
Xamarinには、詳細なガイド、スニペット、印象的な例のベースを含む優れたドキュメントがあります。 すべてのMonotouchおよびMonodroidライブラリクラスのドキュメントは、 Monoの一般的なドキュメントの一部です。 しかし、残念ながら、これは開発プロセス中に発生する可能性のある問題の層全体をカバーするにはまだ十分ではありません。 Xamarinには、 公式フォーラムとStackOverlowに焦点を当てた開発者のコミュニティがあります。 コミュニティの人々の活動とイニシアチブを自慢することはできません。 公式フォーラムで尋ねられた5つの質問のうち、私は1つの回答しか受け取りませんでした。 たぶん私は尋ねなかった この点で、民間技術は非常に貴重な支援を提供しました。 ビジネスライセンスで利用可能なエンジニアとのメールサポート。 原則として、彼らは数時間以内に非標準の「オフとオンを切り替えてください」と回答しますが、彼らは本当に問題を理解し、解決に役立ちます。 ネイティブ開発のために蓄積された質問と回答のベースはXamarinの場合よりもはるかに広いことを理解する必要があります。そのため、コード例を理解するためには、特定の構文Objective-C（Javaに問題はないはずです）を理解する必要があります同じstackoverflowで。 さらに、これにより、プラットフォームの公式ドキュメントを読んで理解することができます。これは、特定の段階で非常に重要になる可能性があります。 一方、これには良い点があります。そのような根拠を受け取ったので、必要に応じてネイティブ開発に切り替える方が簡単です。
開発環境
開発環境としてのXamarin開発者は、独自のIDE（Xamarin Studio）またはVisual Studio（ビジネスライセンスで、詳細は以下）のいずれかを使用することを提案しています。
Xamarin Studio
Xamarin Studioは、Mac OS XとWindowsの両方で実行されるクロスプラットフォームIDEです。 外見は非常にシンプルでフレンドリーに見えますが、外部のシンプルなものの背後には、Visual StudioとResharperでよく知られている多くの機能を含むかなり強力なツールがあります。
- 素敵な構文強調表示;
- コード補完（ネームスペースを同時にインポートする機能を含む）;
- ファイル名、タイプ、クラスメンバーなどによる便利なユニバーサル検索
- 開発されたプロジェクトナビゲーション機能：クラスの説明への迅速な移行、基本クラスへの移行、クラスを使用する場所のリストなど。
- さまざまなリファクタリングメカニズムとクイックヘルプ（alt + Resharperで入力など）;
- 追跡、ホバー時の変数の現在値の表示、フローの視覚化、VSのイミディエイトウィンドウの類似を含む、十分に開発されたデバッグメカニズム。
- バージョン管理システムとの統合統合：SVN、Git、およびTFS（ただし、TFSの場合、サードパーティのユーティリティが必要です）。
苦い真実の時！ 使用の過程で、他の興味深い機能が発見されました。 MacでXamarin Studioを使用したため、以下はすべてMac OS Xに特に適用されます。
- ホットキー（コピーアンドペーストを含む）は、英語のレイアウトでのみ機能します。 開発者はこの問題を認識しています。 バグトラッカーのバグが巻き上げられます。
- 定期的に、ブレークポイントを設定しようとすると、スタジオがフリーズします。 自動保存メカニズムがありますが、これは少しイライラします。
- SVNとの統合された統合を使用する場合、プロジェクトへの新しいファイルの追加は自動的に追跡されません。 つまり .csprojファイルの変更はチェックインされますが、ファイル自体はチェックインされません。 ファイルごとに、右クリックしてリポジトリに追加する必要があります。 技術サポートは、彼らがこのバグについて知っていて、次のアップデートの1つでそれを修正すると報告しました。
- プロジェクトのコンパイルが停止する場合があります。 スタジオを再起動することで処理されます。
ビジュアルスタジオ
Xamarinは、特別なプラグインをインストールした後、Visual Studioで開発する機会を提供します。これはビジネスライセンスで利用できます（記事の公開時-999ドル）が、1か月の試用版があります。 利点は明らかです。場所を変更せずにモバイルアプリケーション開発者になり、Resharperや他のお気に入りのプラグインに代表される重火器をすべて使用できます。 Visual Studioのプラグインをインストールした後、プロジェクトの開始時に使用されるMacとの接続を構成する必要があります。 つまり 起動後、アプリケーションは自動的にMacに送信され、そこでコンパイルされてシミュレーターまたはデバイスにダウンロードされますが、プロセス自体はデバッグプロセス、ブレークポイントの設定などです。 Visual Studioで発生します。
Visual Studioで作業するためのオプションがいくつかあります。 または、WindowsとVisual Studioを配置するMac（Parallelsなど）内で仮想マシンを使用しています。 または、2台の異なる物理マシンを使用しますが、複数のPC開発者に1台のMacを使用することは困難です。 デバッグにはシミュレーターの操作が必要です。 最後のオプションは、Mac OS Xで仮想マシンを使用することです（いわゆるhackintosh）。 いくつかの制限がありますが、これは実行可能なオプションです。 たとえば、Xcodeでは、次のようにスクロールバーを使用してストーリーボードをナビゲートするだけで済みます。 Windowsマウスは、実際のMacマウスにあまり似ていませんが、すべての結果があります。
苦い真実の時。 Visual Studioには、定期的なデバッグの問題がありました。 最も顕著なのは、アプリケーションがリモートで構築されている場合、タイムアウトによってデバッグプロセスが落ちる可能性があることです。 繰り返しになりますが、開発者に感謝する必要があります-彼らはエラーをかなり集中的に修正し、すでにこの記事を書いている時点で、デバッグプロセスは安定しています。 現在のところ、Visual Studioを使用する場合、アプリケーションを起動してからシミュレーター画面に表示されるまでの時間は、MacでXamarin Studioを使用する場合よりもわずかに長くなります。
ライセンス
執筆時点で、Xamarinには次のライセンスタイプがあります。
- スターター-無料。 知り合いの可能性が高いのは、 アプリケーションのサイズ（一部のサンプルプロジェクトでもコンパイルされていないため、非常に小さいと感じられます）およびサードパーティコンポーネントの使用に制限があります。
- インディーズ-ジョブあたり299ドル。 アプリケーションのサイズ制限が削除されました。 開発はXamarin Studioでのみ可能です。
- ビジネス-ジョブあたり999ドル。 Visual Studioおよびプライベートテクノロジーでの開発の可能性があります。 Xamarinエンジニアからのサポート。
- エンタープライズ-1899 $ジョブあたり。 このライセンスは、ホットフィックスを受け取る機会を提供します（とにかく更新が頻繁に出されるため、あまり意味がありません）。また、ソースコードを含むプロジェクトをエンジニアに送信し、「セル幅を変更できないもの」テーブル、助けて！」。 さらに、私の意見では、あまり有用ではない多くのオプションがあります。
各プラットフォーム（iOS、Android）には個別のライセンスが必要であることに注意してください。 現在、ビジネスライセンスには「開発者ごと」と書かれていますが、各ライセンスは4番目のワークステーションでアクティブにでき、これらのワークステーションを変更できます。 つまり 仮に、それぞれがVisual Studioの開発に使用されるという事実にもかかわらず、2人の開発者が1つのライセンスを使用できます。
おわりに
現在、Xamarinテクノロジーは、モバイルアプリケーション開発の分野で複雑なタスクを解決するための深刻なツールです。 それにもかかわらず、開発チームは止まらず、積極的な開発と改善を続けています。 過去2か月間、製品の全体的な安定性が大幅に改善されました。 私の意見では、この技術には素晴らしい未来があり、毎日主要な開発フレームワークとしてそれを使用する開発者の数は着実に増えていきます。 ただし、ライセンスの比較的高いコストは、インディー開発者への途中で使用する際の障害になる可能性があります。 一般に、私はこのフレームワークでの私の経験を前向きであると考えており、これを引き続き使用します。
このフレームワークは、公式Webサイトwww.xamarin.comからダウンロードできます。 優れたスタートガイド： iOS 、 Android 。
最後まで読み通す力を見つけたみんなに感謝します:)