XamarinおよびXamarin.Formsを使用する場合
私はキャプテンになりたくありません。一部の証拠は繰り返しますが、すでにHabréやさまざまなフォーラムで何度も議論されていることを繰り返します。「通常の」モバイルアプリケーションでXamarinを使用しても意味がありません。 「通常の」モバイルアプリケーションとは、次の特性を持つアプリケーションを意味します。
- いくつかのビジネスロジックが含まれています。
- すべてのビジネスロジックはサーバーに実装されます。
- アプリケーションの主なものは、便利なユーザーインターフェイスです。
ここでは、ゲームの巨大なレイヤーには触れません。これは私の世界です。
Xamarinを使用する主な動機は、さまざまなプラットフォームで動作し、クロスプラットフォームフレームワークを使用して1つの言語で記述すると簡単になる大量のコードが存在することです。 WindowsおよびiOS用の小売アプリケーションを作成しました。 このプロジェクトでは、商品の価格の計算に数千行のコードしかかかりませんでした。
Xamarin.FormsはXamarinの一部であり、XAMLを使用してクロスプラットフォームでユーザーインターフェイスを作成できます。 Xamarin.FormsなしでXamarinを使用して、ネイティブクラスのラッパークラスを使用してインターフェイスを作成できます。 Formsを使用しないXamarinは、クロスプラットフォームユーザーインターフェイスの作成には使用できません。
ドキュメント内のXamarinとXamarin.Formsの選択は、次のスキームに従って行うことを提案します。
選択するプロジェクトの種類
Xamarinには、ソリューションでプロジェクトを作成する2つの方法があります。
- 共有プロジェクト
- PCLライブラリ 。
1つ目は、プロジェクトが別のアセンブリにコンパイルされず、アプリケーションが起動されるメインプロジェクトに埋め込まれているかのように、Windowsストアアプリケーションの共有プロジェクトに類似したXamarinの実装です。
主な教訓は、共有プロジェクト（.shproj）Zamarinタイプのプロジェクトを使用する理由はないが、.NET PCL（Portable Class Library）を使用する必要があるということでした。 共有プロジェクトの主な欠点は、他のプラットフォームでは機能しないコードを記述でき、コンパイルされることです。別のプラットフォーム用に開発を開始すると、このプラットフォームの多くのコードがサポートされていないことに驚くでしょう。 PCLにはそのような欠点はありません。 このタイプのプロジェクトを作成する場合、サポートするプラットフォームを指定する必要があります。 たとえば、Androidの何かを使用する場合、コンパイルされず、サポートされていない参照をプロジェクトに追加できません。 ボーナスとして、チーム内の誰もが一般プロジェクトですばやく、しかしネイティブよりも正確に何かを書きたいとは思わないという追加の自信を得ることができますが、たとえば、ネイティブコードをネイティブプロジェクトに取り込み、それをPCLに接続する依存性注入を通じて。
メモリリークの準備をする
不快ですが、決して予想外のことではありませんでしたが、iOSのメモリリークです。 iOSの世界とXamarinの世界は異なる世界です。 1つは、自動参照カウントによってメモリがクリアされ、もう1つは、ガベージコレクターによってメモリがクリアされます。 したがって、iOSの世界と接続しているXamarinの世界で何かを呼び出すと、これはほぼすべてのネイティブコントロールで動作します。このリンクかどうか。 これは非常にい方法で対処する必要があります。 ページを閉じるとき、すべての外部オブジェクトにnullを割り当て、イベントハンドラーからサブスクライブを解除する必要があります。 占領はかなり退屈です。
iOSでは、Apple Instrumentsを使用してメモリのプロファイルを作成できます。 Androidにはこのような可能性はありません。標準ユーティリティはネイティブアプリケーションでのみ機能します。 Xamarinは、Xamarin Profilerツールのベータ版もリリースしました。 今後数週間のうちにAndroidで使用する予定です。
Androidではすべてがはるかに優れていますが、2つのガベージコレクターが同時に動作することを覚えておく必要があります。 1つはAndroidランタイム（Dalvik Runtimeのバージョン5.0まで）の世界、もう1つはMonoランタイムの世界です。 どちらも使用されていないリソースを削除できない場合にも、同様の状況が発生する可能性があります。 それでも、最新の更新プログラムをインストールした後、ユーザーインターフェイス、コントロールを操作するとき、重大なリークに気付きませんでした。 ささいなことで、次の更新がすべてを変更できるような条件下で、根本的な原因を見つけようとすることは常に起こりますが、それは合理的ではありません。 したがって、すべてのページで、次のページに移動すると、このようないコードが呼び出されます。
this.Content = null;
新しいページに移動するとき、再びインスタンス化します。 この方法を使用すると、デバッグが困難なメモリリーク、突然の原因のないクラッシュなどに対処できます。 誰かがこの方法にショックを受けるかもしれませんが、メモリの問題に特化したフォーラムやブログを見ると、これはXamarinの世界では普通のことであることがわかります。 同時に、パフォーマンスは低下しますが、ページを開いたときに目に見える大きな遅延はありません。
フォームなしでMVVMを体験
WindowsストアとiOSのプロジェクトには共通のロジックがありますが、ユーザーインターフェイスはネイティブに記述されています。 なぜなら XAMLで記述したWindowsの場合、MVVMを使用し、iOSは既存のビューモデルを呼び出すことにしました。 アイデアがそれ自体を正当化しないことを認めなければなりません。 iOSとWindowsでユーザーインターフェイスを整理する方法は非常に異なっていることが判明したため、WindowsとiOSで別々のビューモデルを作成する必要がありました。 どういうわけかそれらの間でコードをいじくり回すために、私はCommandパターンを非常に広く使わなければなりませんでした。 検証、サービスコール、ビジネスロジックコール、パラメーターの準備、結果の処理などのコード-ICommand実装クラスに移動し、異なるViewModelで再利用されました。 後者は、コマンドセットを使用してコントロールをバインドするための、モデルとビューの間の薄いレイヤーでした。
具体的な例：ユーザーがリストから製品を選択し、割引を割り当てました。 Windowsでは、UXガイドラインに従って、割引の選択と適用は別のページで行われました。 iOSでは、同じページにポップアップが表示されました。 製品に割引を適用することは、ApplyDiscountCommandクラスにありました。 ViewModel for Windowsは、このコマンドが呼び出された新しいページを開きました。 iOS用ViewModelは、ユーザーが割引を選択し、同じViewModelでApplyDiscountCommandが呼び出されたポップアップウィンドウを開きました。
iOSでMVVMを使用することは、このプラットフォームにとって不便で自然ではないことが判明しました。 特に、コード内のすべてのバインディングを手動で登録し、Execute（）を使用してコード内のコマンドも呼び出す必要がありました。 コンバーターの使用も不便でした。
また、iOSでSystem.Xml.Linqを完全にサポートしていないことも不快でした。 System.Xml名前空間の廃止されたクラスXmlDocument、XmlElement、XmlAttributeに限定する必要がありました。
MvvmCrossフレームワークと組み合わせてXamarinを使用しました。 一般的に、私はそれが好きだった。 Mvvmの論理的で理解可能なサポート、IoC、Messenger、クロスプラットフォームプラグインのような軽量な実装、たとえばHttpでの作業。 唯一の誤解は、別のページに移動する際のパラメーターの受け渡しの実装です。 これには、パラメータークラスが単純型（int、bool、string）のプロパティで構成されている必要があります。 次に、URLにシリアル化されます。 単一のプロセスとスレッドの一部として渡される何かをシリアル化するという驚くべき決定です！ このライブラリをクロスプラットフォームMVVMフレームワークとして安全に推奨できます。
Xamarinフォームの落とし穴
現在、Xamarin.Formsを使用して別のプロジェクトに取り組んでいます。 Xamarin.Formsを使用するという決定は、クロスプラットフォームを実現したい顧客アーキテクトによって行われ、キャンセルすることは不可能でした。 おそらく、Xamarin Formsを使用する決定には、多くの画面フォームと、異なるプラットフォームの3つのバージョンをサポートしたくないという動機が必要です。
Xamarin Formsを使用すれば、ネイティブ開発を遅かれ早かれ習得する必要がないというのは、これがマーケティングの神話だと言われています。 この例は、これは神話ではなく、ネイティブインターフェイスの作成方法に精通していない開発者でさえ、タスクにうまく対処できることを示しています。
Xamarin.Formsを初めて使用し始めたとき、少数のコントロールは大きな失望になりました。 Xamarin.Formsでは、次のコントロールがデフォルトではないことを知ってショックを受けました。
- ラジオボタン
- チェックボックス
- ハイパーリンク
それらの不在は、iOSにはそのようなコントロールがなく、他の視覚要素が同様のタスクに使用されるという事実によって説明されます。
もちろん、これらのコントロールのカスタムレンダラーを使用することもできますが、基本的に異なるプラットフォーム用のコードを書くことを望まないため、これらのコントロールのバージョンを完全にクロスプラットフォームで記述しました！ BoxViewやLineなどのプリミティブなXFコントロールを使用して、必要なものを組み立てました。 Androidでは、これらのコントロールは、特に一般的な文体の文脈では、見た目が異質ではありません。
別のショック：テキストフィールド（エントリ）のMaxLengthプロパティの欠如。 Behaviorsメカニズムを使用するか、単にOnTextChangedの余分な部分をカットすることで、テキストの最大長を設定することをお勧めします。 XFがそのような基本的なプロパティを追加できず、独自のコントロールを作成するように強制できないのはなぜですか？ 質問は修辞的です。
また、すべてのコントロールに、DatePickerやTimePickerなどのバインド可能なプロパティがあるわけではありません。
たとえば、小さなポップアップkosyachkiを提供します。たとえば、複数のコントロールが1つのプロパティにバインドされると、アプリケーションが定期的にクラッシュします。 再現が難しいこのバグの原因を特定するのに、開発者の1人が1日半かかりました。 コピープロパティを作成して別のプロパティにバインドする必要があり、クラッシュが停止しました。
ジェスチャと複雑なインターフェイスのサポートはかなり後方です。 標準のTimePickerよりも速い時間を選択できるページがあります。 これは、ユーザーが矢印をさまざまな方向に動かして時間と分を選択できるアナログ時計の形で作られています。 残念ながら、Xamarin Formsには実装できませんでした。これは、アプリケーションでネイティブに記述された唯一のページです。 実際、Xamarin Formsで利用できるジェスチャーは、タップとダブルタップの2つだけです。 長押し、左/右へのスワイプなどのジェスチャーはサポートされていません。
インターフェイスのパフォーマンス、特にリスト表示のパフォーマンスが低い。 スクロールすると、リストアイテムにさまざまなサイズと色のテキストが含まれるリストの速度が低下します。 アニメーションが無効になっているにも関わらず、ページは少し遅れて開きます。 生産性のために何かを単純化し、デザイナーが描いた画面をやり直さなければなりません。 これを行うことができない場合は、今後のリリースでXamarinがパフォーマンスを向上させることを期待するだけです。
それでも、Formsがスタイルとテンプレートを完全にサポートしていることは本当に気に入っています。 これはXAMLの非常に強力なポイントであり、Xamarinに存在するのは良いことです。 また、楽しい瞬間の1つは強力なXAML機能です。もちろん、これはWPFに後れを取っていますが、WindowsストアアプリケーションのXAMLとほぼ同じです。 XAMLでの作業に慣れている開発者は、Xamarin Formsで十分に快適になります。 バインディング、チーム、コンバーター-これらはすべてサポートされており、MVVMを完全に使用できます。 もちろん、上記の例のように、悲惨なコントロールとさまざまなグリッチを考慮に入れていますが、これらは徐々に修正されています。
Xamarinは開発中であり、頻繁に更新されます。 たとえば、バグがありました。リストを繰り返しクリックすると、アプリケーションがクラッシュしました。 すぐに、これはXamarinのバグであり、修正に時間を浪費しないと判断しましたが、Xamarinが修正するかもしれません。 そして実際、次の更新で2〜3か月後、バグはなくなりました。
開発環境とは
Xamarinは、使いやすさと信頼性で有名なこの一般的に優れた開発環境であるVisual Studioを台無しにしました。 いいえ、いいえ、マイクロソフトは「視覚的な」広告に対して私に支払いをしませんでした、それは格言のようなケースに過ぎません。 以下に、主にツールキットで発生した主な問題をリストします。
Xamarinプラグインを使用したVisual Studioは、多くの場合予想どおりにハングします。 たとえば、XAMLの編集中に定期的にハングします。 Runetで見つかった回避策は、suoファイル（プロジェクトのユーザー設定）を削除することです。その後、しばらくマークアップを編集できます。 しかし、翌日には再びフリーズします。 1日3回までフリーズすることもあれば、1日中「信頼性」に満足することもあります。
また、理由もなく、プロジェクトは電話への展開を停止する場合があります。 数秒前に開始しましたが、すべて正常でしたが、パッケージの展開に失敗しました。 Xamarin Studioを開き、そこで起動し、静かに展開された後、VSに戻って作業を続けます。 ときどき、あなたが無私無欲に何かをプログラムすることがあります-そしてそれはハングします。 VSの場合と同じエディターのカラースキームを設定できるため、目をつぶることなく思考の飛行を中断しないように、XSに切り替えてそこで続行します。 XSは一般に信頼性が高いですが、そこで作業することは常に不可能です。 TFSサポートなし。 遅かれ早かれ、VSに戻る必要があります。
もう1つの不快な瞬間は、Ghost DocがXamarinプロジェクトで動作しなくなったことです（shprojプロジェクトはサポートしていません）。 しかし、XSでは彼は入れません。 まあ、少なくともStyleCop for XSは利用可能です。
最大の欠点は、VSが未処理の例外を適切に表示する機能を失ったという事実です。 現在、例外とその発生場所に関する情報を含む標準ウィンドウは表示されません。 スクリーンショットのようにウィンドウが表示され、スタックトレースとそれが落ちた場所では、出力ウィンドウを見る必要があり、不便です。 XSでは、すべてが少し改善されていますが、不便でもあります。
また、VSでは、XAMLファイルを開くときに、デザイナーは常に画面の床にロードしようとします。 彼は理論的にもこれを行うことができず、閉じなければなりません。 再び不必要なマウス操作です。 残念ながら、最後に使用したタイプの編集を覚えていません。 デザイナーのダウンロードを無効にする方法 XSでは、これに問題はなく、コードがすぐに開きます。
VSのIntelliSenseは独自の生活を送っています。IntelliSenseは、独自の未知のルールに従って機能し、オフになります。VSの再起動は常に役立つとは限りません。 さらに、追加されたクラスは表示されません。 新しいクラスを追加すると、IntelliSenseが破損することがよくあります。 XSでは、私の意見では、IntelliSenseの実装はより悪いですが、安定して動作します。
これらの欠点はすべて生産性を低下させ、XSがより安定しているという事実にもかかわらず、次のinりの爆発で、彼らは世界的な陰謀についての妄想的な考えを思い付きます：このようにXamarinはXSを支持してVSを放棄するように強制します。
Xamarinのサポートは既に組み込まれているため、夏の間、VS 2015がいつリリースされるかについての質問でGoogleを苦しめました。 最後に、公式リリースを待って、私はむしろその中でプロジェクトを立ち上げました。 Microsoftは、いつものように、それ自体に忠実であり、新しい機能を試すには、最新のOSをインストールする必要があります。 VS 2015は7つで動作しますが、共有プロジェクトをビルドするには、Xamarinには少なくともWidows 8.1が必要です。
したがって、Xamarinでプロジェクトを開始する場合は、Windows 8.1 + VS2015で作業することをお勧めします。 まだ7人で座っていて、8.1に切り替えられない場合は、TFSではなく、gitまたはSVNを使用してXamarin Studioのみで作業することを検討してください。
Xamarinは、インターネット上に十分なドキュメントや記事がなく、stackoverflowに関する質問がほとんどないことでしばしば非難されました。 おそらく今ではすべてがより良くなり、stackoverflowとXamarinフォーラムの両方ですでにかなり多くの質問があります。
おわりに
結論として、この資料からいくつかの主要な結論を示します。
- XamarinとXamarin.Formsは、異なるプラットフォームで同じコードを使用する必要がある大規模プロジェクトで使用できます。 1年前の記事に答えて 、「 Xamarin.Formsは戦闘条件に対応できていませんか？」 「準備はできていると自信を持って答えることができますが、仕上げが必要です。
- 特にiOS用に開発している場合は、メモリリークに対処する準備をしてください。
- 主なヒントの1つ：一般的なコードには常にPCLプロジェクトタイプを使用するようにしてください。
- Xamarin.Formsを使用しない場合、MVVMパターンを使用するのはほとんど意味がありません。XAML専用です。 Xamarin.Formsについては、MVVMCrossフレームワークをお勧めします。MVVMCrossフレームワークは、その責任を十分に果たし、常に改善されています。
- Visual Studio 2013と2015のどちらかを選択できる場合は、もちろんOSがWindows 8.1以降でない限り、2015を選択してください。 まだ7つで作業している場合は、Xamarin Studioを使用できますが、Visual Studioにバインドしないように、TFSを使用しない方が良いでしょう。
著者artur_g