モバイルアプリケーションの開発におけるクロスプラットフォームとネイティブアプローチの組み合わせ

1つのモバイルプラットフォームのみのアプリケーションをリリースすることは関係ないため、iOSとAndroidの2つのバージョンを同時に開発する必要があります。 ここでは、2つの方法を選択できます。各オペレーティングシステムの「ネイティブ」プログラミング言語で作業するか、クロスプラットフォームフレームワークを使用します。



DD Planetのプロジェクトの1つを開発するとき、私は最後の選択肢に頼っていました。 また、この記事では、クロスプラットフォームアプリケーションの開発経験、遭遇した問題、見つかった解決策について説明します。

クロスプラットフォームモバイルアプリケーションを開発するための3つのアプローチ

まず、iOSとAndroidの2つのアプリケーションを同時に取得する必要がある場合にどのアプローチを使用するかを検討します。



1つ目は、時間とリソースの両面で最も高価なもので、プラットフォームごとに個別のアプリケーションを開発します。 このアプローチの複雑さは、各オペレーティングシステムが独自のアプローチを必要とするという事実にあります：これは、開発が行われている言語（Androidの場合はJavaまたはKotlin、iOSの場合はObjective-CまたはSwift）とUI部分の記述方法の両方で表現されますアプリケーション（それぞれaxmlおよびxibまたはストーリーボードファイル）。



この事実だけでも、このアプローチでは2つの開発チームを編成する必要があるという事実につながります。 さらに、各プラットフォームのロジックを複製する必要があります：APIおよびビジネスロジックとの相互作用。









しかし、使用されるAPIの数が増えたらどうなるでしょうか？









これは、人的資源の必要量をどのように減らすかという疑問を投げかけます。 プラットフォームごとにコードを複製する必要性を取り除きます。 この問題を解決する十分な数のフレームワークとテクノロジーがあります。



クロスプラットフォームフレームワーク（Xamarin.Formsなど）を使用すると、1つのプログラミング言語でコードを記述し、データロジックとUIロジックを一度に1箇所で記述することができます。 したがって、2つの開発チームを使用する必要はなくなります。 そして、プロジェクトをコンパイルした結果、2つのネイティブアプリケーションが出力されます。 これが2番目のアプローチです。









多くの人は、Xamarinが何であるか、または少なくともそれについて聞いたことがあると思いますが、どのように機能しますか？ Xamarinは、.NETプラットフォームのオープンソース実装であるMonoに基づいています。 Monoには、独自のC＃コンパイラ、ランタイム、およびWinFormsとASP.Netの実装を含む多数のライブラリが含まれています。



プロジェクトの目標は、C＃で記述されたプログラムをWindows以外のオペレーティングシステム（Unixシステム、Mac OSなど）で実行できるようにすることです。 Xamarinフレームワーク自体は、本質的には、開発者にプラットフォームのSDKとこれらのコンパイラーへのアクセスを提供するクラスライブラリです。 次に、Xamarin.Formsを使用すると、両方のプラットフォーム用に同じ言語で記述できるだけでなく、XAMLマークアップを使用して画面を設計することもできます。 プロジェクトのアセンブリの結果、コンパイル段階ですべてのXFコントロールが各プラットフォームのネイティブに変換されるため、すべてのプラットフォームでほぼ同じ外観になります。









開発者は、プラットフォームの機能（指紋スキャナーやバッテリーレベルなど）にアクセスする必要がある場合、または制御動作を微調整する必要がある場合にのみ、各プラットフォームのコードを記述することを強制されます。 場合によっては、アプリケーションの開発時にプラットフォーム依存のコードを記述する必要がある場合がありますが、この場合でも、プラットフォーム機能をインターフェイスに持ち込んで、後で共通プロジェクトから操作することを禁止する人はいません。



1つのプログラミング言語、小さなコードなど。 それはすべて美しいように聞こえますが、Xamarin.Formsは特効薬ではなく、その美しさはすべて現実の石の上で壊れています。 組み込みのXFコントロールがそれらの要件を満たさなくなった状況が発生するとすぐに、画面とコントロールの構造はますます複雑になります。 一般的なプロジェクトの画面を快適に使用するには、ますます多くのカスタムレンダリングを作成する必要があります。



これは、アプリケーションを開発するときに使用する3番目のアプローチに進みます。



Xamarin Formsを使用すると、作業が単純化されるのではなく、複雑になる可能性があることが既にわかっています。 そのため、アーキテクチャが複雑な画面、ネイティブのものとは根本的に異なる設計要素およびコントロールを実装するために、妥協と、最初と2番目のアプローチを組み合わせる可能性が見つかりました。



Xamarin Formsを使用しない一般的なPCLプロジェクトと、Xamarin AndroidとXamarin iOSの2つのプロジェクトという3つのプロジェクトがあります。 1つの言語、2つのプロジェクト間の共通ロジックですべてを記述する機会はまだありますが、単一のXAMLマークアップの制限はありません。 UIコンポーネントは各プラットフォームで制御され、Androidではネイティブツール、ネイティブAXML、iOSではXIBファイルを使用します。 コアプロジェクトとプラットフォームプロジェクト間の接続はデータレベルでのみ編成されるため、各プラットフォームにはガイドラインに従う機能があります。



このような関係を整理するには、MVVMデザインパターンと、Xamarinのかなり一般的な実装であるMVVMCrossを使用できます。 その使用により、作業の「ビジネスロジック」全体を記述する各画面に共通のViewModelを保持し、そのレンダリングをプラットフォームに委ねることができます。 また、2人の開発者が同じ画面（一方はロジック-もう一方はUI）を操作し、お互いに干渉しないようにすることができます。 パターンの実装に加えて、作業に十分な数のツール（DIおよびIoCの実装）を取得します。 プラットフォームとの相互作用を一般的なコードのレベルに上げるには、開発者はインターフェイスを宣言してプラットフォームに実装するだけです。 通常、MvvmCrossは独自のプラグインのセットをすでに提供しています。 チームでは、プラットフォームと共通コード間でメッセージを交換するためにメッセンジャープラグインを使用し、ファイルを操作する（ギャラリーから画像を選択するなど）プラグインを使用します。

複雑な設計とマルチレベルナビゲーションの問題を解決します

前に述べたように、画面上で複雑な表現を使用する場合、フレームワークは人生をより複雑にする可能性があります。 しかし、複雑な要素とは何ですか？ 私は主にiOS開発に携わっているため、このプラットフォームの例を検討します。 たとえば、入力フィールドのような些細なものには、いくつかの状態と、切り替えと視覚化のための十分なロジックがあります。









ユーザー入力を処理する過程で、このような入力コントロールがここで開発されました。 入力フィールドの上に名前を上げ、マスクを操作し、接頭辞を設定し、接尾辞を付け、CapsLockが押されたときに通知し、エラー情報の入力と出力の禁止の2つのモードで情報を検証します。 コントロール内のロジックは約1000行かかります。 そして、入力フィールドの設計で何が複雑になるのでしょうか？



私たちが見た複雑なコントロールの簡単な例。 画面はどうですか？









まず、ほとんどの場合、単一のアプリケーション画面は単一のクラス-UIViewControllerであり、その動作を説明することを明確にします。 開発中、マルチレベルナビゲーションの作成が必要でした。 開発されたアプリケーションの概念は、不動産の管理と、隣人や自治体とのやり取りに帰着します。 そのため、プロパティ、プレゼンテーションレベル（自宅、都市、地域）、コンテンツタイプの3つのレベルのナビゲーションが構築されました。 すべての切り替えは、1つの画面内で実行されます。



これは、ユーザーがどこにいても、どのようなコンテンツを見ているかを理解できるようにするために行われました。 そのようなナビゲーションを整理するために、アプリケーションのメイン画面は1つのコントローラーから遠く離れて構成されています。 視覚的には3つの部分に分けることができますが、誰がここで使用されているコントローラーの数を推測できますか？









15個のメインコントローラー。 そして、これはコンテンツのためだけです。



ここでは、そのようなモンスターはメイン画面に住んでいて、かなり気分がいいです。 もちろん、1画面に15個のコントローラーがあります。 これはアプリケーション全体の速度に影響するため、何らかの方法で最適化する必要があります。



同期初期化を拒否しました。すべてのビューモデルは、必要な場合にのみバックグラウンドで初期化されます。 レンダリング時間を短縮するために、これらの画面のxibファイルも破棄しました。絶対位置決めと計算は、要素間の依存関係を計算するよりも常に高速です。



非常に多くのコントローラーを追跡するには、理解する必要があります。

• それぞれの状態はどのような状態ですか？
• ユーザーはどこにいますか。
• 別のコントローラーに移動するときに彼が期待するもの。

これを行うために、ユーザーの位置、ユーザーが表示するコンテンツの種類、ナビゲーションの履歴などに関する情報を保存する別のナビゲーションプロセッサを作成しました。 彼は初期化の順序と必要性を制御します。



各タブはコントローラーのスライダーであるため（スワイプトランジションを作成するため）、それぞれを独自の状態にすることができます（たとえば、「ニュース」は一方を開き、もう一方は「投票」を行います）。 これには、同じナビゲーションプロセッサが続きます。 プレゼンテーションのレベルを自宅から地域に変更しても、同じ種類のコンテンツにとどまります。

データの流れをリアルタイムで制御します

アプリケーション内の非常に多くのデータを使用して、すべてのセクションの関連情報の配信をリアルタイムで整理する必要があります。 この問題を解決するには、3つの方法を区別できます。

1. タイマーまたはトリガーによってAPIにアクセスし、画面上の関連コンテンツを再要求します。
2. サーバーに永続的に接続し、リアルタイムで変更を受信します。
3. コンテンツの変更でプッシュを受信します。

それぞれのアプローチには長所と短所があるため、それぞれの長所のみを選択して、3つすべてを使用することをお勧めします。 アプリケーション内のコンテンツを、ホット、レギュラー、およびサービスのいくつかのタイプに条件付きで分割しました。 これは、イベントからユーザーへの通知までの許容時間を決定するために行われます。 たとえば、チャットメッセージを送信した直後に表示したい-これはホットコンテンツです。 別のオプション：近隣からのポーリング。 これが通常のコンテンツであるため、彼を今、またはすぐに見ても違いはありません。 アプリケーション内の小さな通知（未読メッセージ、コマンドなど）は、緊急配信が必要なサービスコンテンツですが、大量のデータを必要としません。



判明した：

• ホットコンテンツ-APIとの永続的な接続。
• 通常のコンテンツ-APIへのhttpリクエスト。
• システムコンテンツ-プッシュ通知。

最も興味深いのは、一定の接続を維持することです。 Webソケットを操作するための独自のクライアントを作成することは、うさぎの穴の一歩であるため、他のソリューションを探す必要があります。 その結果、SignalRライブラリーで停止しました。 それが何であるか見てみましょう。



ASP.Net SignalRは、クライアントとサーバー間の双方向通信を提供する、リアルタイムでのクライアントとサーバーの対話を簡素化するマイクロソフトのライブラリです。 サーバーには、接続、接続切断イベント、接続クライアントをグループに結合するメカニズム、および承認を管理するための本格的なAPIが含まれています。



SignalRは、websocket、LongPolling、およびhttpリクエストの両方をトランスポートとして使用できます。 トランスポートのタイプを強制的に指定するか、ライブラリを信頼できます。websocketを使用できる場合、websocketを介して動作し、これが不可能な場合は、許容されるトランスポートが見つかるまで停止します。 この事実は、モバイルデバイスでの使用が計画されているという事実を考えると、非常に実用的であることがわかりました。



合計、どのような利益が得られますか：

• クライアントとサーバー間で任意のタイプのメッセージを交換する機能。
• Webソケット、ロングプーリング、およびHttpリクエストを自動的に切り替えるメカニズム。
• 接続の現在のステータスに関する情報。
• クライアントをグループにまとめる機会。
• グループ内でメッセージを送信するロジックを操作するための実用的な方法。
• サーバーをスケーリングする機能。

もちろん、これはすべてのニーズを満たしているわけではありませんが、生活が著しく楽になります。



プロジェクト内では、SignalRライブラリでラッパーが使用されます。これにより、ラッパーの操作がさらに簡単になります。

• 接続の状態を監視し、指定された条件に従って、また中断が発生した場合に再接続します。
• 接続を迅速に置換または再開することができ、古い接続を非同期で強制終了し、ガベージコレクターに引き裂くために提供します-判明したように、接続メソッドはクロージャーメソッド（破棄または停止）よりも10倍速く動作し、これがそれを閉じる唯一の方法です;
• メッセージを送信するためのキューを編成して、接続の再接続または再オープンによって送信が中断されないようにします。
• 予期しないエラーが発生した場合に、適切なデリゲートに制御を移します。

これらの各ラッパー（クライアントと呼びます）は、キャッシュシステムと連携して動作し、接続が切断された場合に、この間に見逃した可能性のあるデータのみを要求できます。 複数の活性化合物が同時に保持されるため、「それぞれ」。 アプリケーション内には本格的なメッセンジャーがあり、サービスを提供するために別のクライアントが使用されます。



2番目のクライアントは、通知の受信を担当します。 既に述べたように、通常のタイプのコンテンツはhttp-requestsを介して取得されますが、将来的には、その更新はこのクライアントにあります。

アプリケーションのデータを視覚化する

データを取得することと表示することは別です。 リアルタイムのデータ更新には独自の問題があります。 少なくとも、これらの更新をユーザーに提示する方法を決定する必要があります。 アプリケーションでは、次の3種類の通知を使用します。

1. 未読コンテンツの通知。
2. 画面上のデータの自動更新。
3. コンテンツ提供。

新しいコンテンツがあることを示す最も一般的でありふれた方法は、セクションアイコンを強調表示することです。 したがって、ほとんどすべてのアイコンには、未読のコンテンツ通知機能を赤い点として表示する機能があります。 さらに興味深いのは、自動更新です。



新しいコンテンツが画面を再配置せず、コントロールのサイズを変更しない場合にのみ、データの自動更新が可能です。 たとえば、調査画面：投票に関する情報は、進行状況バーの値とパーセンテージのみを変更します。 このような変更はサイズ変更を伴わず、問題なく即座に適用できます。



リストに新しいコンテンツを追加する必要がある場合、問題が発生します。 実際、アプリケーション内のすべてのリストはScrollViewであり、ウィンドウサイズ、コンテンツサイズ、スクロール位置などのいくつかの特性があります。 それらはすべて静的な開始点（座標0の画面上部; 0）を持ち、下に展開できます。 リストの最後に新しいコンテンツを追加しても、問題は発生せず、リストは継続します。 ただし、新しいコンテンツが上部に表示されるはずです。これは次の図です。









3つの要素で、2になります-スクロールが跳ね返ります。 また、新しいコンテンツは常に到着する可能性があるため、ユーザーは通常どおりスクロールできません。 あなたは言うかもしれません：新しいコンテンツのサイズを計算し、この値までスクロールダウンしてみませんか？ はい、できます。 ただし、スクロール位置を手動で制御する必要があり、その瞬間にユーザーが任意の方向にスクロールすると、アクションが中断されます。 そのため、このような画面は、ユーザーの同意なしにリアルタイムで更新することはできません。



この状況での最良の解決策は、ユーザーがフィードをスクロールしている間に誰かが新しいコンテンツを投稿したことをユーザーに通知することです。 このデザインでは、画面の隅にある赤い円のように見えます。 それをクリックすることにより、ユーザーは条件付きで同意し、画面上部に戻って新しいコンテンツを表示することに同意します。



もちろん、このアプローチでは、コンテンツの「スリップ」の問題を回避しましたが、それでも解決する必要がありました。 つまり、チャット画面では、画面との通信および対話中に、新しいコンテンツをさまざまな場所に表示する必要があるためです。



チャットリストと通常のリストの違いは、最新のコンテンツが画面の下部にあることです。 これは「テール」であるため、それほど困難なくコンテンツをそこに追加できます。 ユーザーはここで90％の時間を費やします。つまり、メッセージを送受信するときには、常にスクロール位置を維持し、それを下にシフトする必要があります。 ライブ会話では、そのようなアクションを頻繁に実行する必要があります。



2番目のポイント：上にスクロールするときの履歴の読み込み。 ストーリーをロードするとき、スクロールがスムーズで連続するように、メッセージをレビューレベル（バイアスを伴う）より上に配置する必要がある状況にあります。 そして、すでにわかっているように、ユーザーを邪魔しないために、スクロール位置を手動で制御することは不可能です。



そして解決策を見つけました。それを裏返しました。 スクリーンフリップは、2つの問題を同時に解決しました。

1. リストの末尾は上部にあるため、ユーザーのスクロールを妨げることなく、シームレスにストーリーを追加できます。
2. 最後のメッセージは常にリストの一番上にあり、その前に画面をスクロールする必要はありません。

また、このソリューションはレンダリングを高速化し、スクロールコントロールによる不要な操作を排除しました。



パフォーマンスといえば。 画面の最初のバージョンでは、メッセージのスクロール時に顕著なドローダウンが検出されました。 「金額」のコンテンツはテキスト、ファイル、写真などの雑多なものなので、セルのサイズを常に再計算し、お金の要素を追加および削除する必要があります。 したがって、バブルの最適化が必要でした。 メイン画面と同じように、生地を部分的に絶対位置でレンダリングしました。



iOSでリストを操作する場合、セルを描画する前に、その高さを知る必要があります。 したがって、新しいメッセージをリストに追加する前に、表示に必要なすべての情報を個別のストリームで準備し、セルの高さを計算し、ユーザーデータを処理し、必要なものをすべて見つけてキャッシュしてから、リストにセルを追加する必要があります。



その結果、スムーズなスクロールとオーバーロードされていないUIストリームが得られます。

要約すると：

• クロスプラットフォーム開発は時間とお金を節約します。
• 複雑なデザインのアプリケーションを作成して、一般的なコードではなくプラットフォームで記述する方が便利です。
• プラットフォームをデータレベルでのみ共通コードと通信し、各プラットフォームが独自のガイドラインを遵守できるようにすることをお勧めします。
• 絶対配置と遅延初期化により、複雑でリソース集約的な画面を実装できます。
• SignalR-リアルタイムでの双方向のクライアント/サーバー相互作用のための便利なソリューション。
• データをリアルタイムで更新する場合、ユーザーがアプリケーションと対話するのを妨げてはなりません。
• 問題をさまざまな角度から見ると、成功した、時には珍しい解決策を見つけることができます。
• 1つの画面で多数のコントローラーを使用し、複数のSignalR接続をセットアップし、画面を切り替え、コードを記述し、最適化し、実験します。