Xamarin Forms、MVVMCross、およびSkiaSharp：クロスプラットフォームアプリ開発の聖三位一体
公開: 2022-03-11高い期待を設定することについて話します。 聖なる三位一体、それ以下ではありません！
真実は、共有コードがないため、複数のプラットフォームをターゲットにする場合、モバイルアプリの開発にはコストがかかるということです。 AppleではObjective-CまたはSwiftでコーディングする必要があり、AndroidではJavaでコーディングする必要があり、WinPhoneでは.NET（多くの場合C＃）で開発する必要があります。 さらに、各プラットフォームが地図、描画、写真、またはGPSを処理するために提供する多数のライブラリーは、単一のモバイルアプリを構築するために膨大な時間と知識を必要とします。
言うまでもなく、ほとんどの新興企業は費用を3倍にする余裕がなく、確立された企業でさえ、モバイルスペースへの参入価格を正当化するのに苦労する可能性があります。
この記事では、Xamarin FormsをMVVMCrossおよびSkiaSharpと組み合わせることで、親しみやすさ、パフォーマンス、独自性を損なうことなく、クロスプラットフォームのモバイルアプリを構築するための実行可能な方法を学ぶことができます。 この記事では、これら3つのテクノロジーと、複数のモバイルプラットフォームでコードを最大限に再利用できるようにすることで開発コストを削減する方法について説明します。
重要な問題
クロスプラットフォームのモバイルアプリ開発の問題は現実のものであり、そのため、プラットフォーム間でコードを共有することで開発コストを削減するために、長年にわたってさまざまなソリューションが登場してきました。 たとえば、ビデオゲーム業界では、すべての主要なゲームエンジンがクロスプラットフォームソリューションを提供しており、UnrealやUnityでさえ携帯電話やタブレットをターゲットにしています。
アプリの面では、このクロスプラットフォーム市場をリードするための複数の試みが何年にもわたって行われてきました。 多くは不足し、深淵で失われましたが、それらのいくつかは数年後もまだ生き残っています。 これらの中には、3つのモバイルプラットフォームすべてをサポートする唯一の.NETソリューションであるXamarinがあります。
ネイティブであろうとなかろうと、ここに来る
したがって、さまざまな解決策の間に戦争があり、戦争はプロパガンダを意味すると誰が言いますか？
戦争は主にビッグNの前で戦われます：ネイティブであること！ 明確な意味がないので注意が必要です。 これは、今日のモバイル開発の世界で最もよく使われている言葉であり、非常に流行しています。 真実は、それが実際に何を意味するのかについて誰も同意しないということです。
クロスプラットフォームフレームワークを選択する場合、すべての「ネイティブ」オプションが同じではないため、注意してください。リンゴとオレンジを比較している可能性があります。 プログラミング言語に関するものもあれば、ハードウェア機能を使用できることに関するものもあれば、プラットフォームAPI / UIの使用に関するものだと考える人もいれば、Webアプリではないことだけに関するものもあります。
議論のあらゆる側面に議論があり、それは役に立たないので、私はこれ以上深く掘り下げるつもりはありません。 なぜ役に立たないのですか？ さて、飲み込むのが難しい事実をお話ししましょう。エンドユーザーは気にしません！
はい、あなたはその権利を読みます、あなたのプログラマーだけが気にします。 エンドユーザーは、基盤となるテクノロジーのためにアプリを選択することはありません。問題に答え、優れたエクスペリエンスを提供するため、エンドユーザーはアプリを選択します。
したがって、単語の意味をめぐって争うのではなく、Xamarinがユーザーに関心のあるものを提供する効率的な方法をどのように提供するかを見てみましょう。
父、子、そして聖霊
先に進む前に、クロスプラットフォーム開発の問題に対するソリューションを構成する3つの要素を明確にしましょう。
父：Xamarin
前述のように、Xamarinはモバイルおよびデスクトップアプリ開発用の.NETソリューションです。 2016年にMicrosoftによって購入されましたが、Monoプロジェクトで約4年前に日付が付けられました。 現在、Xamarin.iOS、Xamarin.Android、Xamarin.Macの3つのソリューションを備えています。 他のプラットフォームは、Microsoftソリューションであるデフォルトですでに.NETアプリを処理しています。 つまり、Xamarinは.NETのプラットフォームAPIへの直接リンクを提供します。 したがって、.NETアプリのネイティブ機能を使用できます。 UIの抽象化レイヤーを提供するFormsと呼ばれるXamarinの拡張モジュールもあります。
息子：SkiaSharp
SkiaSharpは、GoogleのSkiaベクターグラフィックライブラリの.NETラッパーです。 Skiaは、Android、Chrome、ChromeOS、Firefoxのネイティブレンダリングエンジンです。 SkiaSharpを使用すると、.NETアプリのライブラリを使用してクロスプラットフォームにすることができます。 これは、デザイナーが「アプリをすっごく良くする」と言っているきちんとした影は、ターゲットプラットフォームごとに繰り返すのではなく、一度だけコーディングできることを意味します。 個人的には、その最高の機能は、鮮明でピクセルパーフェクトなレンダリングを維持しながら、さまざまなフォームファクタの重複を防ぐことができる方法でSVGグラフィックスをレンダリングできることだと思います。
聖霊：MVVMCross
すべてを適切に分離し、緩く結合するために、私たちの神聖なソリューションはMVVMCrossに依存します。 このフレームワークは、MVVM（Model-View-ViewModel）インフラストラクチャを実装しているため、すべてを独立させることができます。 技術的になりすぎることなく、アプリは通常3つの部分に分かれています。
- モデル：データのメモリ表現
- ビュー：ユーザーにデータとアクションを提示するUI
- ViewModel：モデルをビューにバインドするレイヤー（またはその逆）
ソフトウェアエンジニアリングでは、視覚的表現を変更した場合でもアプリケーションロジック（ViewModel内）を再利用できるように、常にビューをViewModelから分離するように努めています。 MVVMCrossは、データバインディングを処理し、プラットフォームを抽象化するためのパターンとツールを提供することで、まさにそれを実現するのに役立ちます。
エンドユーザーが気にすること
要約すると、成功したアプリと悪いアプリを区別するさまざまなことがあります。 成功したアプリ：
- 現実の問題を解決します
- 楽しい体験を提供します
ポイント1は、明らかに、選択したフレームワークとは何の関係もありません。 それでは、ポイント番号2に集中しましょう。アプリの楽しみに寄与する3つの主要な側面があります。
- 親しみやすさ
- パフォーマンス
- 独自性
親しみやすさ
親しみやすさは、使いやすさとアプリの使い方をすばやく見つけることに関係しています。
つまり、プラットフォームのさまざまなユーザーインターフェイスパラダイムをシステム全体で一貫した方法で使用することです。 たとえば、ボタンの位置、リストコンテキストのアクション、ナビゲーションなどの単純なものはすべて、アプリの使いやすさに貢献します。
親しみやすさは、Webインターフェースに基づくWebアプリまたはフレームワークの主な弱点です。 一方、Xamarin Formsは、ベンダー提供のUI要素へのクロスプラットフォームマッピングを提供します。
したがって、ユーザーはプラットフォームの一般的なルックアンドフィールに準拠したエクスペリエンスを得ることができるため、ユーザーはアプリで直感的に安心できます。
パフォーマンス
率直に言って、マーケティング宣伝で「ネイティブ」と言っても意味がありません。 「HTTPを介したネイティブ」であるJasonetteを例として取り上げます。 UIはWebサーバーに保存されます…こんにちはラウンドトリップとスローダウンです。したがって、ネイティブが必ずしもパフォーマンスの向上を意味するとは限らないことがわかります。
したがって、その神話が邪魔にならないように、実際のベンチマークを見ると、Xamarinはパフォーマンスに関して最も丸みのあるソリューションとして出てきます。 Xamarin Formsは、かなり多くのコンテキストスイッチを必要とせず、母国語アプリと同等のパフォーマンスを提供します。
私の結論は、実装の選択は、Xamarinと母国語ではなく、アプリの速度を低下させる可能性があるということです。 そこにある他のオプションは、パフォーマンスに関して明らかに不利です。
独自性
デザイナーがユニークな外観のアプリを作成する可能性も、可能な限り最高のユーザーエクスペリエンスを提供し、アプリを差別化するかどうかを検討する上で非常に重要です。
多くの場合、一意性とは、カスタムの外観のコントロール、アニメーション、またはジェスチャを作成することを意味します。 Xamarinですぐに利用できない場合は、SkiaSharp（GoogleのSkiaベクターグラフィックスレンダリングライブラリのラッパー）を使用し、Xamarinフォームのカスタムレンダラーコンセプトを利用して、常に1つのコードでコーディングしながら、必要なだけハードウェアに近づけることができます。言語、他のソリューションでは提供できないもの。
あなたがビジネスとして気にかけていること
この時点で、フレームワークの選択もビジネス上の決定であると考えている可能性があります。 人的資源の可用性など、この記事の範囲外の要因は別として、Xamarinには、特にMVVMCrossと組み合わせると、提供できるものがたくさんあります。 私はあなたがあなたの決定で考慮したいと思うであろう4つの側面について詳しく説明します：
- 価格と開発費
- コードの再利用
- コンポーネントの可用性
- サポートとコミュニティ
価格と開発費
これを邪魔にならないようにしましょう。 今年の初めから、Xamarinはフリーランサーやスタートアップのような中小企業（Visual Studio Community Editionを使用）は無料です。 大規模な組織の場合は、既にお持ちのVisualStudioライセンスが「無料」で付属しています。 Xamarin Forms、MVVMCross、SkiaSharpもすべて無料でオープンソースであり、それを締めくくることができます。
すでに述べたように、Xamarinで.Netルートを使用すると、アプリを最初から最後まで単一の言語で開発できます。 他のほとんどのソリューションでは、プログラマーがさまざまな言語を知っている必要があります。 たとえば、Cordovaの場合、HTML、Javascript、CSSだけでなく、利用可能なプラグインがないベンダーAPIにアクセスする必要がある場合は、Objective-C、Java、C＃にも精通している必要があります。 。
使用される言語の多様性により、より多くのコンテキストスイッチとマスターするツールが増え、効率が低下します。 一方、Xamarinはオールインワンソリューションです。VisualStudioから、すべてのプラットフォームでビルド、デプロイ、デバッグを行います。
Xamarinとは直接関係ありませんが、.Netソリューションを選択することで開発をスピードアップするC＃の多くの機能も利用できます。 つまり、非同期/待機、クロージャ、リフレクションを備えた簡単なマルチスレッドなど、C＃4.5以降の優れた機能の恩恵を受けます。これらはすべて、効率を向上させることが示されています。
コードの再利用
コードの再利用について考えたことがあると思いますが、この点では、すべてのソリューションがある程度同等であると考えている可能性があります。 メイトと言って申し訳ありませんが、あなたは間違っています！
あなたの中のプログラマーは、なぜ私がフォームに組み込まれているMVVMレイヤー上でMVVMCrossの使用を提案するのか疑問に思ったかもしれません。 さて、ここで考慮すべきことがあります：あなたは本当にモバイルアプリを構築しているだけですか？
アプリロジックをMVVMCrossで分離し、それが提供する制御の反転を使用することで、モバイルだけでなくWindowsとMacでも最大量のコードを再利用できます（Xamarin.Macが友だちだからです）。
それはあなたにお金を節約するだけでなく、あなたのコード保守コストを下げる良いエンジニアリング慣行を提案します。
コンポーネントの可用性
たぶんあなたは私のようではありませんが、私は車輪の再発明を嫌います。 したがって、アプリに簡単に統合できる既存のコンポーネントにアクセスできることは、市場投入までの時間を短縮するために不可欠であり、多くの場合、同時にコストを削減します。
XamarinとMVVMCrossを選択すると、既存のコンポーネントを選択するための2つのオプションが提供されます。 まず、フォームの有無にかかわらず、Xamarinで利用できるコンポーネントが増えています。 XamarinにはVisualStudio内に統合されたコンポーネントストアがあり、一般的なアプリの問題に対するさまざまな解決策を見つけることができます。他の企業は直接販売しているため、独自のコンポーネントを作成する前に必ず検索してください（または、コンポーネントが構築されたら販売することを検討してください）。
次に、Nugetパッケージを検索する必要があります。これは、誰かが必要なことを実行するためのコードを既に作成している可能性があるためです。 それらのパッケージの中には、電子メール、GPS、ローカリゼーションなどの一般的な問題を解決するクロスプラットフォームのMVVMCrossプラグインのまともなリストがあります。
すでにC＃の経験がある場合は、好みのコンポーネントを使用している可能性があります。 もちろん、あなたは彼らを手放したくありません、彼らはとても快適に感じます。 安心してください。既存のコンポーネントのC＃バインディングを作成して、カスタムレンダラーの助けを借りてFormsでも、Xamarinにバンドルされているかのように使用できます。
そういえば、独自のリポジトリを作成する前に、XamarinバインディングのGithubリポジトリを確認することをお勧めします。
サポートとコミュニティ
最後に、サポートと例へのアクセスは、フレームワークを選択する上で非常に重要な要素です。 Xamarinはしばらく前から存在しているため、コミュニティは今日かなり良い規模になっています。
Googleで情報を検索すると、通常、かなりの数の回答が見つかります（ヒント：Xamarinの祖先であるmonotouchとmonodroidも検索してみてください）。Xamarinは、Webサイトで多くの例と優れたドキュメントを提供しています。
さらに、Xamarinは実際にはベンダーAPIを拘束するだけなので、AppleとGoogleのドキュメントは常に関連性があり、多くの質問に答えます。 次に、独自のMVVMCrossサービスを作成して、共有コード内のベンダーAPIを抽象化できます。
Xamarinの将来については、昨年3月にMicrosoftが買収したことで、私は、Xamarinが前進する以外のどこにも進まないことを確信しています。 その販売とマッチングがフリーっぽいモデルに移行して以来、コミュニティは成長し、サポートは向上し、製品はおそらくより速いペースでさえも向上し続けています！
Xamarinの将来は明るいように見えます。
戦いの用意をしよう！
私はこの記事でワームの缶を開けているかもしれないという事実を意識しています。 誤解しないでください。検討する価値のある他のオプションがあります。私の懸念はあなたの懸念と同じではない可能性があるため、そうすることをお勧めします。
6週間のタイムラインがあり、4か月経ってもアプリの準備ができていない場合は、勝てないことに注意してください。 それは、社内で誰かを訓練したり、知識のある人を雇ったりするために、2か月半と多額のお金を残すことになります。 その時点で「ネイティブ」アプリの構築を主張することは、プロジェクトの運命にとって非常に有害な場合があります。
Xamarinとこれらのコンパニオンテクノロジーは、ユーザーが気にかけていることと必要なことを正確に提供します。 この記事が、次のモバイルアプリ用に選択する可能性のあるフレームワークについて十分な情報に基づいた決定を下すのに役立つことを願っています。