iOSのオフラインモードとRealmでの実装の機能

投稿者Ekaterina Semashko、強力なジュニアiOS開発者、DataArt



プロジェクトについて少し：Swiftで書かれたiOSプラットフォーム用のモバイルアプリケーション。 アプリケーションの目的は、会社の従業員とその友人の間で割引カードを共有する機能です。



このプロジェクトの目標の1つは、人気のあるテクノロジとライブラリを実際に研究して試してみることでした。 ローカルデータの保存にはRealmが、サーバーの操作にはAlamofireが、認証にはGoogle Sign-Inが、画像の読み込みにはPINRemoteImageが使用されました。



アプリケーションの主な機能：

• マップの追加、編集、削除。
• 他の人のカードを見る;
• 店舗名/ユーザー名でカードを検索します。
• お気に入りにカードを追加して、すばやくアクセスできます。

ネットワークに接続せずにアプリケーションを使用する機能は最初から想定されていましたが、読み取りモードでのみでした。 つまり カードに関する情報は表示できましたが、インターネットがなければカードを変更できませんでした。 このため、アプリケーションには常に、サーバーからのデータベースのすべてのカードとブランドのコピーに加えて、現在のユーザーのお気に入りのリストがありました。 検索もローカルに実装されました。



その後、記録モードを追加してオフラインで拡張することにしました。 ユーザーが行った変更に関する情報は、インターネット接続が表示されたときに保存および同期されました。 このような読み取り/書き込みオフラインモードの実装について説明します。

---

モバイルアプリケーションの完全なオフラインモードには何が必要ですか？ 特に、インターネット接続の品質へのユーザーの依存を削除する必要があります。

1. UIでのユーザーのアクションに対するユーザーへの応答の依存関係をサーバーから削除します。 まず、リクエストはローカルストレージとやり取りしてから、サーバーに送信されます。
2. ローカルの変更をマークして保存します。
3. 同期メカニズムを実装する-インターネット接続が表示されたら、サーバーに変更を送信する必要があります。
4. 同期されている変更と同期されていない変更をユーザーに示します。

オフライン優先アプローチ

まず、サーバーおよびデータベースとやり取りするための既存のメカニズムを変更する必要がありました。 目標は、ユーザーがインターネットの有無に夢中になるのを防ぐことでした。 まず、ローカルデータウェアハウスとやり取りし、サーバー要求をバックグラウンドで送信する必要があります。



前のバージョンでは、データストレージレイヤーとネットワークレイヤーの間に強力な接続がありました。 データを操作するメカニズムは次のとおりです。まず、NetworkManagerクラスを介してサーバーに要求が行われ、結果がリポジトリクラスを介してデータベースに保存された後、結果を待ちました。 次に、図に示すように、結果がUIに渡されました。









オフライン優先アプローチを実装するために、NetworkManagerとRepositoryが呼び出される順序を制御する新しいFlowクラスを導入して、データストレージレイヤーとネットワークレイヤーを分離しました。 これで、データは最初にRepositoryクラスを介してデータベースに保存され、次に結果がUIに送信され、ユーザーはアプリケーションでの作業を続けます。 バックグラウンドで、サーバーへの要求が行われ、応答後、データベースおよびUIの情報が更新されます。

オブジェクト識別子を使用する

新しいアーキテクチャでは、いくつかの新しいタスクが登場し、そのうちの1つはidオブジェクトを操作します。 以前は、オブジェクトの作成時にサーバーからそれらを受け取りました。 ただし、オブジェクトはローカルで作成されたため、IDを生成し、同期後にそれらを現在のIDに更新する必要がありました。 ここで、レルムの最初の制限に出会いました。オブジェクトを作成した後、その主キーを変更することはできません。



最初のオプションは、オブジェクトの主キーを放棄し、idを通常のフィールドにすることでした。 しかし同時に、主キーを使用する利点は失われました：オブジェクトのフェッチを高速化するレルムインデックス、作成フラグでオブジェクトを更新する機能（存在しない場合はオブジェクトを作成する）、およびオブジェクトの一意性への準拠。



主キーを保存したかったのですが、サーバーからのオブジェクトのIDにはできませんでした。 その結果、実際のソリューションでは、サーバー、オプションフィールド、およびプライマリキーとなる2番目のローカルの2つの識別子を持つことになりました。



その結果、ローカルIDは、オブジェクトをローカルで作成するときにクライアントで生成され、オブジェクトがサーバーから取得された場合は、サーバーIDと等しくなります。 アプリケーションでは単一の真実のソースがデータベースであるため、サーバーからデータを受信すると、オブジェクトには現在のローカル識別子が付加され、それだけで機能します。 サーバーにデータを送信すると、サーバー識別子が送信されます。

同期されていない変更を保存する

サーバーにまだ送信されていないオブジェクトへの変更は、ローカルに保存する必要があります。 これは、次の方法で実装できます。

1. 既存のオブジェクトにフィールドを追加する
2. 非同期オブジェクトを個別のテーブルに保存する。
3. 個々のフィールドの変更を何らかの形式で保存します。

クラスでRealmオブジェクトを直接使用することはありませんが、マルチスレッドの問題を回避するために自分でRealmオブジェクトを使用します。 インターフェイスの自動更新は、自動更新の結果サンプルを使用して行われます。ここでは、更新リクエストをサブスクライブします。 現在のアーキテクチャでは最初のアプローチのみが機能したため、既存のオブジェクトにフィールドを追加することを選択しました。



マップオブジェクトには、ほとんどの変更が加えられています。

• 同期済み-サーバー上にデータがありますか？
• deleted-true。カードがローカルでのみ削除される場合、同期が必要です。

前の部分で説明した識別子：

• localId-アプリケーションのエンティティのプライマリキー。サーバーIDと等しいか、ローカルで生成されます。
• serverId-サーバーのID。

別途言及する価値があるのは、画像の保存です。 本質的に、添付ファイルのフィールドdiskURLがサーバー上のイメージのserverURLフィールドに追加され、ローカルの非同期イメージのアドレスが保存されます。 イメージを同期するときに、デバイスのメモリを詰まらせないようにローカルのイメージが削除されました。

サーバー同期

サーバーと同期するために、インターネットが表示されたときに同期メカニズムが開始されるように、Reachabilityでの作業が追加されました。



最初に、送信する必要があるデータベースへの変更があるかどうかを確認します。 次に、実際のデータキャストの要求がサーバーに送信されます。その結果、クライアントに送信する必要のない変更（たとえば、サーバー上で既に削除されたオブジェクトの変更）は削除されます。 残りの変更は、サーバーへのリクエストをキューに入れます。



変更を送信するために、一括更新を実装し、変更をアレイで送信するか、すべてのデータを同期するために大量の要求を行うことができました。 しかし、その頃には、バックエンド開発者はすでに別のプロジェクトで忙しく、私たちの自由時間でしか助けていなかったため、変更の種類ごとに異なるリクエストが作成されます。



OperationQueueを使用してキューを実装し、各要求を非同期操作でラップしました。 一部の操作は互いに依存しています。たとえば、マップを作成する前にマップイメージを読み込むことができないため、イメージ操作の依存関係をマップ操作に追加しました。 また、サーバーに画像をアップロードする操作は、他の誰よりも低い優先順位が与えられ、それらが重いため、最後にキューに追加しました。



オフラインモードを計画するときの大きな問題は、同期中のサーバーとの競合を解決することでした。 しかし、実装中にこのポイントに達したとき、ユーザーが異なるデバイスで同じデータを変更するケースは非常にまれであることに気付きました。 したがって、最後のライターの勝ちメカニズムを実装するだけで十分です。 同期中、クライアントで未送信の変更が常に優先され、それらは変更されません。



エラー処理はまだ初期段階です。同期が失敗した場合、次回インターネットが表示されたときにオブジェクトが変更キューに追加されます。 そして、マージ後にまだ同期が取れていない場合、ユーザーはそれを残すか削除するかを決定します。

レルムを使用する場合の追加の回避策

Realmを使用する場合、さらにいくつかの問題に直面しました。 おそらく、この経験は誰かにとっても役に立つでしょう。



文字列で並べ替える場合、順序はUTF-8の文字の順序に従います。大文字と小文字を区別する検索サポートはありません。 たとえば、Magnet、Pyaterochka、Ribbonなど、小文字の名前が大文字の名前の後に来るという状況に直面しています。 リストが非常に大きい場合、小文字の名前はすべて下部に表示され、非常に不快です。



大文字と小文字を区別せずに並べ替え順序を保持するには、新しいlowercasedNameフィールドを導入し、名前の更新時に更新して、並べ替える必要がありました。



また、基本的にオブジェクトのリレーションのサブクエリが必要になるため、お気に入りのマップの存在による並べ替えのために新しいフィールドが追加されました。



Realmで検索する場合、大文字と小文字を区別しない検索にはCONTAINS [c]％@メソッドがあります。 しかし、残念ながら、ラテンアルファベットでのみ機能します。 ロシアのブランドについても、個別のフィールドを作成して検索する必要がありました。 しかし、後で検索時に特殊文字を除外することが私たちの手にあることが判明しました。

---

ご覧のとおり、モバイルアプリケーションの場合、変更を保存し、ほとんど血を流さずに同期するオフラインモードを実装することは非常に可能です。



いくつかの困難にもかかわらず、Realmを使用して実装することができますが、ライブ更新、ゼロコピーアーキテクチャ、および便利なAPIの形ですべての利点を享受できます。



そのため、接続の品質に関係なく、ユーザーがいつでもデータにアクセスできないようにする理由はありません。