コアデータと管理対象ドキュメントを使用して、最初にオフラインにします

Valentin ChernovはiOS開発者としてMegaFonに参加し、今日の主なトレンドになりました-オフラインになります：Valentinはモバイル個人アカウントを開発しています-MegaFonのメインアプリケーションです。残高の確認、料金の変更、サービスとサービスの接続と切断、コンテストへの参加、MegaFonパートナーの個人的なオファーの使用が可能です。



MegaFonは、その重要な成長ポイントの1つとして、不安定な通信を処理する機会を選択しました。ロシアには、通信が一時的に切断されたり、長期間失われたりする場所があります。そして、この場合でも、アプリケーションは失敗することなく動作する必要があります。



Valentinは、過去5か月間にこのタスクがどのように実行されたか、プロジェクトのアーキテクチャがどのように選択および実装されたか、どのテクノロジーが使用されたか、それらが何を達成し、将来何が計画されているかについて話しました。Valentinはモバイルアプリケーション開発者のApps Live2020カンファレンスで話しました。

仕事

ビジネスによると、ユーザーが不安定なネットワーク接続でアプリケーションを正常に操作できるように、オフラインになります。私たちは開発チームとして、最初にオフラインを保証する必要がありました。アプリケーションは、不安定なインターネットや完全に存在しないインターネットでも機能します。今日は、私たちがどこから始めたのか、そしてこの方向でどのような最初のステップを踏んだのかをお話します。

テクノロジースタック

標準のMVCアーキテクチャに加えて、次のものを使用します。

Swift + Objective-C

ほとんどのコード（プロジェクトの80％）はObjective-Cで書かれています。そしてすでにSwiftで新しいコードを書いています。

モジュラーアーキテクチャ

グローバルコードチャンクをモジュールに論理的に分割して、コンパイル、プロジェクトの立ち上げ、開発を高速化します。

サブモジュール（ライブラリ）

使用されるライブラリをより細かく制御するために、gitサブモジュールを介してすべての追加ライブラリを接続します。したがって、それらのいずれかのサポートが突然停止した場合、私たちは自分で状況を修正することができます。

ローカルストレージのコアデータ

選択する際の主な基準は、ネイティブ性とiOSフレームワークとの統合でした。そして、コアデータのこれらの利点は決定的でした：

• スタックと受け取ったデータを自動保存します。
• , ( , ..)
• ;
• ;
• ;
• ;
• UI (FRC);
• (NSPredicates).

UIManaged document

UIキットには、UIDocumentのサブクラスであるUIManagedDocumentと呼ばれる組み込みクラスがあります。その主な違いは、管理対象ドキュメントが初期化されるときに、ローカルストレージまたはリモートストレージ内のドキュメントの場所にURLが指定されることです。次に、ドキュメントオブジェクトは、箱から出してすぐにコアデータスタックを完全に作成します。これは、メインアプリケーションパッケージのオブジェクトモデル（.xcdatamodeld）を使用してドキュメントの永続ストレージにアクセスするために使用されます。私たちはすでに21世紀に住んでいますが、それは便利で理にかなっています。

• UIDocumentは、特定の頻度で現在の状態自体を自動保存します。特に重要なセクションでは、手動で保存をトリガーできます。
• . - — , , - , — , , .
• UIDocument .
• Core data .
• iCloud . , .
• .
• ドキュメントベースのアプリパラダイムが使用されます-このデータを格納するためのコンテナとしてデータモデルを表します。Appleのドキュメントで従来のMVCモデルを見ると、コアデータはこのモデルを操作するために正確に作成されており、より高いレベルの抽象化でデータを処理するのに役立ちます。モデルレベルでは、UIManagedDocumentを作成されたスタック全体に接続することで機能します。また、ドキュメント自体を、コアデータとキャッシュからのすべてのデータ（画面、ユーザーから）を格納するコンテナーと見なします。さらに、写真、ビデオ、テキストなど、あらゆる情報を含めることができます。

アプリケーション、その起動、ユーザー認証、およびそのすべてのデータは、ユーザーの履歴を格納する一種の大きなドキュメント（ファイル）と見なされます。

処理する

アーキテクチャの設計方法

私たちの設計プロセスはいくつかの段階で行われます。

1. 技術仕様の分析。
2. UMLダイアグラムのレンダリング。主にクラス図、フローチャート、シーケンス図の3種類のUML図を使用します。これは上級開発者の直接の責任ですが、経験の少ない開発者もこれを行うことができます。これは、タスクにうまく飛び込み、そのすべての微妙な点を学ぶことができるので、歓迎されています。これは、技術的な割り当ての欠陥を見つけるのに役立つだけでなく、タスクに関するすべての情報を構造化するのにも役立ちます。また、アプリケーションのクロスプラットフォームの性質を考慮に入れようとしています。Androidチームと緊密に連携し、2つのプラットフォームで同じ図を描き、4人のギャングから一般的に受け入れられている主なデザインパターンを使用しようとしています。
3. アーキテクチャのレビュー。原則として、隣接するチームの同僚がレビューと評価を行います。
4. 1つのUIモジュールの例での実装とテスト。
5. スケーリング。テストが成功した場合、アプリケーション全体でアーキテクチャを拡張します。
6. リファクタリング。私たちが何かを逃したかどうかを確認するため。

このプロジェクトを開発してから5か月後、プロセス全体を3つの段階で示すことができます。何が起こったのか、どのように変化したのか、そして結果として何が起こったのかです。

どうした

私たちの出発点は、標準のMVCアーキテクチャでした-これらは相互接続されたレイヤーです：

• 目的Cを使用して完全にプログラムされたUIレイヤー。
• プレゼンテーションクラス（モデル）;
• ネットワークと連携するサービスレイヤー。

アクティビティインジケータは、データを受信するプロセスがインターネットの速度に敏感である図の場所に配置されました。ユーザーは迅速な結果を望んでいますが、一部のローダー、インジケータ、およびその他の信号を確認する必要があります。これらは、ユーザーエクスペリエンスの成長のポイントでした。

移行期間

移行期間中、画面のキャッシュを実装する必要がありました。ただし、アプリケーションは大きく、レガシーのObjective Cコードが多数含まれているため、Swiftコードを挿入してすべてのサービスとモデルを削除することはできません。キャッシュと並行して、他にも多くの製品タスクが開発中であることを考慮する必要があります。



何も壊すことなく、現在のコードに可能な限り効率的に統合し、最初の反復を可能な限りスムーズに実行するための簡単な方法を見つけました。前の図の左側では、ネットワーク要求に関連するすべてのものを完全に削除しました。サービスは、インターフェイスを介してDataSourceFacadeと通信するようになりました。そして今、これはサービスが機能するファサードです。 DataSourceから、以前にネットワークから受信したデータを期待します。また、データデータ自体には、このデータを抽出するためのロジックが隠されています。



図の右側では、データ取得をコマンドに分割しています。コマンドパターンは、いくつかの基本的なコマンドを実行して結果を取得することを目的としています。 iOSの場合、NSOperationの継承者を使用







します。ここに表示される各コマンドは、予期されるアクションの論理ユニットを含む操作です。これは、データベース（またはネットワーク）からデータを取得し、このデータをコアデータに格納することです。たとえば、AcquireCommandの主なタスクは、データソースをファサードに戻すだけでなく、ファサードを介してデータを受信するようにコードを設計する機能を提供することです。つまり、操作との対話はこのファサードを通過します。



そして、操作の主なタスクは、DataSourceデータをDataSourceFacadeに渡すことです。もちろん、データをできるだけ早くユーザーに表示するようにロジックを構築します。通常、DataSourceFacade内には、NSOperationsを開始する操作キューがあります。構成された条件に応じて、キャッシュからのデータを表示するタイミングと、ネットワークから受信するタイミングを決定できます。ファサード内のデータソースの最初の要求で、コアデータデータベースに移動し、そこからFetchCommand（存在する場合）を介してデータを取得し、すぐにユーザーに返します。



同時に、ネットワークを介してデータの並列要求を開始し、この要求が実行されると、結果がデータベースに送られ、データベースに保存され、その後、データデータの更新を受け取ります。このアップデートはすでにUIにあります。このようにして、データの待機時間を最小限に抑え、データを即座に受信するユーザーは違いに気づきません。データベースがネットワークから応答を受信するとすぐに、更新されたデータを受信します。

どのようになりましたか

私たちはそのようなより簡潔な計画に行きます（そして私たちは最後に来るでしょう）：







今これから私たちは持っています：

• UIレイヤー、
• データデータを提供するファサード、
• このデータデータを更新とともに返すコマンド。

DataSourceとは何ですか、なぜそれについて多く話すのですか

DataSourceは、プレゼンテーションレイヤーにデータを提供し、事前定義されたプロトコルに従うオブジェクトです。また、プロトコルをUIに合わせて調整し、UIのデータを提供する必要があります（特定の画面や画面のグループには関係ありません）。



DataSourceには通常、2つの主な責任があります。

1. UIレイヤーに表示するためのデータを提供します。
2. データの変更をレイヤーUIに通知し、更新を受信したときに必要な変更のバッチを画面に送信します。

ここでは、Objective Cのレガシーコードが多数あるため、ここではDataSourceのいくつかのバリアントを使用します。つまり、SwiftDataSourceをどこにでも簡単に貼り付けることはできません。また、まだどこでもコレクションを使用していませんが、将来的には、CollectionView画面を使用するようにコードを書き直します。



DataSourceの1つの例：







これはコレクションのDataSource（CollectionDataSourceと呼ばれます）であり、インターフェイスの観点からはかなり単純なクラスです。 fetchedResultsControllerとCellDequeueBlockによって構成されたコレクションを取り込みます。 CellDequeueBlockは、セルを作成するための戦略を説明するタイプエイリアスです。



つまり、DataSourceを作成し、fetchedResultsControllerでperformFetchを呼び出してコレクションに割り当てた後、すべての魔法がDataSourceクラス、fetchedResultsControllerの相互作用、およびデータベースから更新を受信するデリゲートの機能に割り当てられます







。FetchedResultsControllerはDataSourceの中心です。 Appleのドキュメントには、この操作に関する多くの情報が記載されています。原則として、新しいデータと更新または削除されたデータの両方の助けを借りて、すべてのデータを受け取ります。同時に、ネットワークからのデータを同時に要求します。データが受信されてデータベースに保存されるとすぐに、データデータから更新が受信され、更新がUIに届きました。つまり、1つのリクエストでデータを受け取り、さまざまな場所に表示します。クールで便利、ネイティブです。



また、テーブルまたはコレクションで既製のDataSourceを使用できる場合は常に、それを実行します。







画面やテーブルが多く、コレクションが使用されていない（そしてObjective Cプログラミングが使用されている）場所では、必要なデータを評価します。画面用に、プロトコルを通じてDataSourceについて説明します。その後、ファサードを作成します。原則として、これは、データデータを要求するためのパブリックObjectiveCプロトコルでもあります。そして、Swiftコードへの入り口はすでに進行中です。



画面をSwift実装に完全に転送する準備ができたら、Objective Cラッパーを削除するだけで十分です。カスタムDataSourceのおかげで、Swiftプロトコルを直接操作できます。



現在、データデータの3つの主要なバリアントを使用しています。

1. TableViewDatasource +セル戦略（セルを作成するための戦略）;
2. CollectionViewDatasource +セル戦略（コレクションのオプション）;
3. CustomDataSourceはカスタムオプションです。今一番使っています。

結果

レガシーコードを設計、実装、および操作するためのすべてのステップの後、ビジネスは次の改善を受けました。

• キャッシングにより、ユーザーへのデータ配信速度が大幅に向上しました。これはおそらく明白で論理的な結果です。
• これで、オフラインの最初のパラダイムに一歩近づきました。
• アーキテクチャのクロスプラットフォームレビューのプロセスは、iOSおよびAndroidチーム内で設定されています。このプロジェクトに関与するすべての開発者は情報を持っており、チーム間で簡単に経験を交換できます。
• . , , legacy , .
• , — . , , , , , .

私たちにとってのボーナスは、アーキテクチャと図の操作がいかに面白くて楽しいかを理解したことです（これにより開発が簡素化されます）。はい、アーキテクチャアプローチの描画と調整に多くの時間を費やしましたが、実装に関しては、すべての画面で非常に迅速にスケーリングしました。



オフラインへのパスは最初に続きます-オフラインにするためにキャッシュする必要があるだけでなく、ユーザーはネットワーク接続なしで操作でき、インターネットが表示された後にサーバーとさらに同期します。

リンク

• ドキュメントベースのプログラミングガイド。これはかなり古いドキュメントであり、Appleはもはやそれを使用することを推奨していません。しかし、少なくとも追加の開発を探すことをお勧めします。そこにはたくさんの役立つ情報があります。
• Document-based WWDC:
• DataSources

Apps Live 2020 .

— Android iOS, . , , .