まず、両方のアプローチの長所と短所は、状況によってまったく異なる効果があります。 これは、この問題が特定の条件に関連して、真空で考慮されるべきではないことを意味します。 次に、ニュアンスも時間とともに変化します。たとえば、最近ではXamarinを購入したMicrosoftがこの製品を無料にしました。 これは、通常の長所と短所を再検討する時が来たということですか?

カスタムモバイル開発に従事し、同じXamarinに精通している3人のスペシャリストにいくつか質問をしました。さまざまな規模や性質のプロジェクトに関与している可能性のある状況を、他に誰が評価しますか? 対話者は次のとおりです。
- ミハイル・サマリン (フューチュリス、ビジネスディレクター)
- デニス・クレトフ (Notissimus、テクニカルディレクター)
- Maxim Pocheshire Evtuh (Notissimus、開発者)
クロスプラットフォーム開発へのアプローチはあなたの会社で使用されており、どのような理由で選択されましたか?

デニス・クレトフ
当社は3年以上モバイル開発に携わっており、別の業界ソリューションであるオンラインストア向けモバイルアプリケーションのために作成されました。 各オンラインストアにはエンティティの共通リストがあるため、最初にXamarinを使用することに決め、一般的なロジックの70%を別のライブラリに転送することができました。 これにより、オンラインストアの標準ソリューションを短時間で作成できました。

マキシム・エヴトゥフ
長い間、私たちはそのアーキテクチャと、現在会社で使用されている開発原則に取り組みました。 その結果、各プロジェクトは次のもので構成されます。
* API
*コア
* UI
API-サーバーとの相互作用、CORE-ビジネスロジック、UI-付随するUIの瞬間(アニメーション、トランジションなど)をカバーする直接の面付けとコード。 さらに、APIとCOREはプラットフォームの変更とは無関係です(つまり、AndroidとiOSの両方で使用されます)。これにより、開発速度が明確に向上し、最も重要なこととして、将来のプロジェクトサポートが簡素化されます。
Xamarinを使用してこれを達成することができ、MvvmCrossを使用してポータブルコードの数を増やすことができました。

Futuriceの存在の最初の日、つまり16年間、ほぼすべての既存のモバイルプラットフォームで開発を行ってきたため、各ケースで最適なソリューションを見つけようと試みてきました。 現在、すべてのオプションを使用しています:ネイティブソリューション、Cordova、React Native、Xamarin Native、およびXamarin Forms。 特定の場合にどれが特定の顧客の目標とプロジェクトの機能に依存します。
クロスプラットフォームツールを使用する場合と回避する場合、他の人に何をアドバイスできますか?
マキシム・エヴトゥフ
次の2つの場合にクロスプラットフォーム開発を使用するのは意味がないと思います。
- プロジェクトは元々1つのプラットフォーム用に考案されたものであり、他のプラットフォームへの拡張は計画されていません。
- このプロジェクトでは、各プラットフォームでの実装に根本的な違いがあり、プラットフォームコードの数が増加します。
現在の慣行に基づいて、最初のケースはより可能性が高いです ほとんどのアプリケーションは、各プラットフォームの機能(iOSの場合は「フラット」デザイン、Androidの場合は素材)を保持したまま、特別に類似(アーキテクチャ)であると考えられています。
デニス・クレトフ
マキシムについては、モバイル開発の各タスクを分析して、コードの再現性、設計の一意性、および電話のハードウェア機能の使用を分析する必要があることも追加できます。 これらの要素を組み合わせることで、クロスプラットフォームソリューションをいつ使用できるか、およびネイティブがより優れている場合の全体像を把握できます。
ミハイル・サマリン :
私たちの経験では、3つの要素の組み合わせが決定的だと言えます。長期的なサポートの可能性の評価、顧客の予算、ユーザーエクスペリエンスの許容可能なトレードオフです。 後者を評価するために、そのような基準が可能です:アプリケーションの使用の頻度と期間は何ですか? ユーザーが1週間に1回5分間それを使用する場合、すべての欠陥に注意して、毎日長時間使用されるアプリケーションよりもはるかに大きな妥協策を講じ、クロスプラットフォームの手段でより多くのことを行うことができます。
来年、何かが変わると思いますか?たとえば、Xamarinは新しい品質への移行により、はるかに人気が出るでしょうか?
デニス・クレトフ :
私は楽観的です。 Xamarinの無料バージョンの登場により、プロジェクトでの使用数は劇的に増加するはずです。
マキシム・エヴトゥフ :
大きなプラスは、MicrosoftがXamarinを購入したことです-Xamarinは無料になりました。 しかし、Xamarinエラーがオープンソースのおかげでより早く修正されることを除いて、劇的な変更は何もありません(少なくともそうすることを望みます)。 Xamarinの人気が高まった場合、これも良いことです。なぜなら、この技術に精通した優れた専門家が十分にいないからです。
ミハイル・サマリン :
はい、インディー開発者を犠牲にして上昇します。 そして、XamarinとToolsの両方が現在オープンソースであるという事実により、ライセンスの価格がこれまで問題にならなかった企業環境で。 これにより、選択に安心感と自信が加わります。 さらに、C#、MacのXamarin Studio、WindowsのVisual Studioは非常に優れたコレクションであることを覚えておく必要があります。 次のプロジェクトである100%iOS固有のXamarinに会った後、iOS固有の100%だけの開発者がXamarinを使用したケースを見てきました。 C#言語がどれだけ快適かという理由だけで。
昨年、サンクトペテルブルクのメビウス会議でミハイル・サマリンは他の多くの人たちの間でこの問題について話し、彼の昨年の報告書はYouTubeに投稿されました 。 そして、6月4日のMobius 2016で、デニス・クレトフとマキシム・イェヴトゥクは共同レポートで、彼らが社内でXamarinとMvvmCrossを使用して選択したアプローチを実装する方法の実際の例を示します-お見逃しなく!