モバイルクライアントサーバーアプリケーションのアーキテクチャ

遅かれ早かれ、複雑なプロジェクトには外部サーバーが追加されます。 ただし、理由はまったく異なります。 ネットワークから追加情報をダウンロードするもの、クライアントデバイス間でデータを同期するもの、アプリケーション実行ロジックをサーバー側に転送するものがあります。 原則として、後者にはほとんどの「ビジネス」アプリケーションが含まれます。 すべてのアクションがソースシステムのフレームワーク内でのみ実行される「サンドボックス」パラダイムから離れると、プロセスのロジックが絡み合い、絡み合い、ノードによって結び付けられるため、アプリケーションプロセスへのエントリの開始点を理解することが難しくなります。 この時点で、最初の場所は、アプリケーション自体の機能プロパティではなく、そのアーキテクチャであり、結果として、拡張性です。

敷設された基盤により、壮大な建築アンサンブル、または「ドープ」（鶏足の小屋）を作成できます。鶏の足の小屋は、その存在中に、目に見えないように見えます。元のプロジェクトではなく、ビルダーのチーム。

計画はプロジェクトの成功の鍵ですが、最小時間は顧客によって割り当てられます。 パターンを構築すること-開発者のスリーブのエースであり、時間が不利な場合に好ましくない組み合わせをカバーすることが、決定的な要因であることが判明しました。 基礎となる実用的なソリューションを使用すると、顧客に最も関連があると思われるタスク（まだ建設されていない屋根に煙突パイプを塗装するなど）に進むためのクイックスタートが可能になります。

この記事では、モバイルデバイス向けのスケーラブルなシステムを構築し、クライアントサーバーアプリケーションの90〜95％をカバーし、秘跡の「ナイフエッジ」からの最大距離を提供する原理を説明します。





この記事の仕上げに取り組んでいる間に、同様の記事がハブで公開されました（ http://habrahabr.ru/company/redmadrobot/blog/246551/ ）。 私は著者のすべてのアクセントに同意しませんが、一般的に、私のビジョンはそこに提示された資料と矛盾せず、交差しません。 読者は、どのアプローチがより柔軟で関連性が高いかを判断できます。







サーバー側からのクライアントサーバーインタラクションの一般的な構造は次のとおりです。

ここでは、2つのことを理解することが重要です。

1. 1つのアカウントを使用して北と通信する多くのクライアントが存在する場合があります。
2. 原則として、各クライアントには独自のローカルストレージがあります。 *

*場合によっては、ローカルストレージをクラウドと同期し、それに応じて各クライアントと同期できます。 これは特殊なケースであり、ほとんどの場合、アプリケーションのアーキテクチャに影響を与えないため、省略します。



一部の開発者は「サーバー側」を排除しようとしているため、一部のアプリケーションは「クラウド」内のストレージの同期を中心に構築されていることに注意してください。 つまり、実際には、2リンクシステムもありますが、展開のアーキテクチャをオペレーティングシステムのレベルに移行しています。 場合によっては、そのような構造は正当化されますが、そのようなシステムはそれほど簡単にスケーリングされず、その機能は非常に制限されます。







一般的なアプリケーション構造



最も基本的な抽象化レベルでは、サーバー指向アプリケーションは次のアーキテクチャ層で構成されます。

1. アプリケーションのコア。ユーザーとの対話には使用できないシステムコンポーネントが含まれます。
2. グラフィカルユーザーインターフェイス
3. コンポーネントの再利用：ライブラリ、ビジュアルコンポーネントなど。
4. 環境ファイル：AppDelegate、.plistなど
5. アプリケーションリソース：グラフィックファイル、サウンド、必要なバイナリファイル。

ストレスに強いアーキテクチャを構築するための最も重要な条件は、システムコアをGUIから分離し、一方が他方なしで正常に機能できるようにすることです。 一方、ほとんどのRADシステムは反対のメッセージから来ています-型はシステムの骨格を形成し、機能は筋肉を構築します。 原則として、これはアプリケーションがそのインターフェースによって制限されないことを意味します。 また、インターフェイスは、ユーザーの観点とクラス階層の観点の両方から明確な解釈を行います。







コア



アプリケーションのコアは、次のレイヤーで構成されています。

1. （開始層）プログラム実行の開始のワークフローを定義する開始層。
2. （ネットワーク層）トランスポート相互作用のメカニズムを提供するネットワーク層。
3. （APIレイヤー）クライアントとサーバー間の対話のためのコマンドの統一システムを提供するAPIレイヤー。
4. （ネットワークキャッシュレイヤー）クライアントとサーバーのネットワーク相互作用を加速するネットワークキャッシュレイヤー。
5. （検証項目レイヤー）ネットワーク検証レイヤー
6. （ネットワークアイテムレイヤー）ネットワーク経由で送信されるデータエンティティのレイヤー
7. （データモデル）データエンティティの相互作用を可能にするデータモデル。
8. （ローカルキャッシュレイヤー）既に受信したネットワークリソースへのローカルアクセスを提供するローカルキャッシュのレイヤー。
9. （ワークフローレイヤー）特定のアプリケーションに固有のクラスとアルゴリズムを含むワークフローレイヤー。
10. （ローカルストレージ）ローカルストレージ

システムの開発者が直面する主なタスクの1つは、これらのレイヤーの相互に独立した機能を保証することです。 各レイヤーは、割り当てられた機能のパフォーマンスのみを保証する必要があります。 原則として、階層の上位レベルに位置するレイヤーは、他のレイヤーの実装の詳細を把握してはなりません。



ジュニアおよびシニア開発者の観点から問題を解決するプロセスを検討してください。

目的：ネットワークからデータを受信するプログラム「通貨計算機」を作成し、為替レートのグラフを作成します。

ジュニア：

1）問題の声明に基づいて、アプリケーションは次の部分で構成されることがわかります。

1. 数学演算（加算、減算）の形式
2. グラフ表示フォーム
3. 追加のフォーム：スプラッシュスクリーン、約。

2）次のようにフォームの依存関係を作成します。計算のフォームは、アプリケーションの主なものです。 スプラッシュフォームを起動します。これは、特定のボタンをクリックすることで、一定の期間が経過すると非表示になります。

3）スプラッシュ画面の表示時間-ネットワークからデータをロードするのにかかった時間に相当します。

4）ネットワークからのダウンロードはスプラッシュフォームの表示中にのみ実行されるため、データロードコードはフォーム内に配置され、フォームの完了時に、フォームとともにメモリから削除されます。



このアプリケーションはどの程度機能しますか？ DelphiやVisual Studioを使用すると、現時点でこの問題を解決できることを疑う人はいないと思います。 Xcodeを使用すると、これが少し難しくなりますが、あまり負担をかけずに行うこともできます。 ただし、プロトタイプの出現により、スケーラビリティの問題が発生し始めています。 グラフを表示するには、前の期間のデータを保存する必要があることが明らかになります。 問題ではありませんが、チャートフォーム内にデータウェアハウスを追加できます。 ただし、データはさまざまなプロバイダーから、さまざまな形式で提供される場合があります。 さらに、算術演算は異なる通貨で実行できるため、選択を確実にする必要があります。 グラフの形式でこのような選択を行うことは多少非論理的ですが、可能ですが、グラフに表示するものはそのような設定に依存します。 これは、設定ウィンドウに追加のパラメーターを入力した場合、何らかの方法でそれらをメインフォームからグラフウィンドウに転送する必要があることを意味します。 この場合、渡されたパラメーターを格納し、メインフォームを介して1つのフォームから別のフォームへのアクセスを提供するローカル変数を作成するのが論理的です。 まあなど。 推論の連鎖は非常に長い間構築することができ、相互作用の複雑さが増します。



シニア：

問題のステートメントにより、別々のクラスで記述できるいくつかのサブタスクを区別できます。

1）ネットワークからデータをダウンロードします。

1. 受信データの検証
2. 永続ストレージにデータを保存します。
3. データ計算。
4. 加算操作
5. 減算演算
6. 指定された基準（アプリケーション設定）によるデータのフィルタリング
7. アプリケーション開始クラス。

2）次の主要な形式で構成されるインターフェイスの関連操作を確認します。

1. メインコントローラー（不可視の場合があります）
2. 計算フォーム
3. チャートフォーム
4. スプラッシュとについて
5. オプション設定フォーム。

3）アプリケーションが実行のために起動された後、データのロードを担当するオブジェクトの作成（インスタンス）（大多数の場合非同期）が実行され、プロセスが開始されます。 アプリケーションのメインコントローラーはスプラッシュスクリーンを表示し、この時点で、スプラッシュフォームを非表示にする代わりにフォームを形成します。

4）データの読み込みが終了すると、検証オブジェクトとローカルストレージプロバイダーオブジェクトが作成されます。 データが必要な検証に合格した場合、ローカルストレージプロバイダーに転送できます。

5）グラフを表示するために、ローカルストレージオブジェクトとデータ設定オブジェクトが作成されます。 データ設定がローカルストレージプロバイダーに転送され、フィルターがインストールされたデータが取得されます。

6）計算を実行するために、電卓オブジェクトと操作オブジェクトが作成されます。 フォームから受け取ったデータは、計算機オブジェクトと、計算の実行方法を正確に知っている2つの操作オブジェクトの1つに転送されます。



もちろん、このアプローチではより多くのプログラミング作業が必要になるため、最初はより多くの時間がかかります。 ただし、サブタスクに基づいて、まず、その作業が並列化が容易であることは明らかです-1人の開発者がカーネルの構築に忙しい一方で、他の開発者はUIを作成およびデバッグします。 カーネルはコンソール内で安全に動作し、デバイスでUIをクリックします。特に、独立した単体テストを両方の部分にねじ込むことができます。 もう1つの間違いない利点は、2番目のアプローチがはるかにスケーラブルであることです。 プロジェクトの機能を修正する場合、視覚的な表現に制限的なフレームワークがないため、変更は何倍も速くなります。 ビジュアルフォーム自体（GUI）は、カーネル内の既存のタスクに基づいて必要な最小値を表示します。







開始レイヤー：

iOSでは、アプリケーションはデリゲートクラスオブジェクトを起動することで起動します。 その目的は、システムコールを受信して​​アプリケーションに転送し、アプリケーションGUIの初期設定を実行することです。 アプリケーションの開始、またはシステムからのメッセージの受信に関係しないすべてのアルゴリズムとメカニズムは、別々のクラスに配置する必要があります。 初期構成の完了直後に、制御は、残りのアプリケーション構成操作を実行するクラスに転送する必要があります：許可、条件に応じたインターフェースの再構成、初期データのロード、必要なトークンの取得など。 開発者が犯す典型的な間違いは、AppDelegateでホストされる巨大なスパゲッティコードです。 外部フレームワークのほとんどすべての例には、理解を容易にするための独自のコードがあります。 不運なプログラマーはリファクタリングに時間を浪費せず、単に「何でも」をコピーします。 CoreDataを作成するために組み込みテンプレートを使用する場合、状況は非常に典型的です。

多くの場合、次の機能の実装を確認できます。

1. Facebookセッションのセットアップと維持
2. アプリケーションがUITabbarControllerをサポートする場合、タブマネージャーを設定します。
3. バックグラウンドに入るときにCoreDataをクリアしてデータを保存します。
4. 更新の確認と初期化
5. 外部統計サーバーの通知
6. データモデルの同期

より洗練されたソリューションは、シングルトンクラスStartを作成し、そこにAppDelegateに送られるデータを転送し、さらにワークプロセスでデータを希釈するために開始することです：CoreDataの場合-ソーシャルネットワークの場合-別の場合



ネットワーク層：

クライアントからサーバーにメッセージを送信し、そこから必要な情報を取得するトランスポート層の基本的なアルゴリズムを提供します。 原則として、メッセージはJSON形式とマルチパート形式で送信できますが、一部のエキゾチックなケースでは、一般的にXMLまたはバイナリストリームになります。 また、各メッセージには、オーバーヘッド情報を含むヘッダーが含まれる場合があります。 たとえば、アプリケーションキャッシュ内の要求/応答ストレージの期間をそこに記述することができます。

ネットワーク層は、アプリケーションが使用するサーバーやそのコマンドシステムについて何も知りません。 ネットワーク接続エラー処理は、次のアプリケーションレベルの仮想メソッドによって実行されます。 このレイヤーのタスクは、処理メソッドを呼び出して、ネットワークから受信した情報を処理メソッドに転送することだけです。

さらに、ネットワークから直接情報を要求する前に、ネットワーク層はローカルキャッシュをポーリングし、そこに応答がある場合、すぐにそれをユーザーに返します。

このレイヤーのコンテンツは、どのトランスポートテクノロジーが最も近いかに大きく依存します。 開発者の武器では、次のオプションが最も需要があります。

• ソケットは、同期要求と非同期要求を含む最も低レベルのアプローチであり、TCP接続とUDP接続の両方で機能することができます。 ほとんど何でもできますが、タスクに集中する必要があり、忍耐力があまりなく、大量のコードが必要です。
• WebSocketは、TCP上のヘッダーの使用に基づくアプローチです。 詳細はこちらをご覧ください： habrahabr.ru/post/79038モバイル開発は、十分な柔軟性がなく、それをサポートするためにかなり大量のコードを必要とするため、あまり使用されません。
• WCFはおそらく最も先進的なメカニズムですが、すべての利点を上回る非常に深刻なマイナスを持っています。 Microsoftの腸で発明されたアプローチは、アプリケーションロジックとリモートノースの間の関係を仲介するプロキシクラスの作成に依存しています。 WSDLスキーム（ en.wikipedia.org/wiki/Web_Services_Description_Language ）に基づいてプロキシクラスを生成できる場合、「軽快に」動作します。 また、このクラスは、サーバーAPIが更新されるたびに再生成する必要があります。 また、Visual Studio開発者にとってこれがZephyrの使いやすさで行われた場合、iOS開発者にとっては、開発でMonoTouchを使用している人にとっても、それは絶対に不可能な作業です。
• RESTは、上記のすべてのアプローチ（ en.wikipedia.org/wiki/REST ）の信頼できる、 実績のある妥協案です。 もちろん、各アプローチの機能の一部を放棄する必要がありますが、これは最小限の労力で迅速かつ非常に効率的に行われます。

GitHubにはREST接続を使用できる多くのライブラリが含まれています。iOSの場合、AFNetworkingが最も人気があります。



RESTは、GET、POST、PUT、HEAD、PATCH、およびDELETE要求の使用に依存しています。 このような動物園はRESTFul（ habrahabr.ru/post/144011 ）と呼ばれ、原則として、動作中のモバイルアプリケーション、Webサイト、デスクトップ、および宇宙ステーション用のユニバーサルAPIが1つのバンドルで記述されている場合にのみ使用されます。

ほとんどのアプリケーションでは、コマンドシステムをGETとPOSTの2つのタイプに制限していますが、POSTだけで十分です。

GET要求は、ブラウザーで使用する文字列として送信され、要求のパラメーターは「＆」文字で区切って渡されます。 POST要求も「ブラウザ文字列」を使用しますが、パラメータはメッセージの不可視の本文内に隠されています。 最後の2つのステートメントは、以前にリクエストに出会ったことがない人たちの落胆に陥ります。実際には、この技術は開発者にとって完全に透過的であり、そのようなニュアンスを掘り下げる必要はありません。

上記では、サーバーに送信されるものについて説明しました。 しかし、サーバーから来るものははるかに興味深いです。 AFNetworkingを使用する場合、サーバー側で受信します原則として、iOS開発者はJSONベースのシリアル化された辞書を呼び出しますが、これは完全に真実ではありません。 True J​​SONの形式はやや複雑ですが、純粋な形式では使用する必要はほとんどありません。 ただし、知っておく必要がある違いがあります-ニュアンスがあります。

Microsoft Windows Serverにインストールされたサービスを使用している場合、ほとんどの場合、そこでWCFが使用されます。 ただし、Windows Framework 4以降では、RESTプロトコルのみをサポートするクライアントは、アクセスを完全に透過的に宣言的にすることができます。 APIに関する説明を得るために時間を無駄にする必要はありません。コマンドシステムに関するドキュメントはIIS（Microsoft Webサーバー）によって自動的に生成されます。



以下は、Objective-CでAFNetworking 2を使用してネットワーク層を実装するための最小コードです。



これは、ネットワークのGETおよびPOSTメッセージを送信するのに十分です。 ほとんどの場合、これらのファイルを調整する必要はありません。



APIレイヤー：

RESTコマンドについて説明し、ホストを選択します。 レイヤーAPIは、ネットワークプロトコルの実装やアプリケーションの他の機能に関する知識とは完全に分離されています。 技術的には、アプリケーションの他の部分を変更せずに完全に置き換えることができます。



クラスはClientBaseから継承されます。 クラスコードは非常に単純なので、クラスコード全体を提供する必要さえありません。APIの統一された記述で構成されています。



sayingにもあるように、「これ以上はありません。」



ネットワークキャッシュレイヤー：

このキャッシングレイヤーは、iOS SDKレベルでクライアントとサーバー間のネットワーク交換を加速するために使用されます。 回答の選択は、システムの制御外にいる当事者によって実行され、ネットワークトラフィックの減少を保証するものではなく、それを加速します。 アプリケーションまたはシステムからデータまたは実装メカニズムにアクセスすることはできません。 SQLiteストレージを使用します。



これに必要なコードは単純すぎて、ネットワークにアクセスできるプロジェクトでは使用できません。



アプリケーション内のどこからでも一度呼び出す必要があります。 たとえば、開始レイヤーから。



検証アイテムレイヤー：

ネットワークから受信したデータの形式は、サーバー開発者により依存しています。 アプリケーションは、最初に指定された形式の使用を物理的に制御できません。 複雑な構造のデータの場合、エラー修正は複雑さにおいてアプリケーション自体の開発に匹敵します。 エラーの存在は、アプリケーションのクラッシュを伴います。 データ検証メカニズムを使用すると、不正な動作のリスクが大幅に削減されます。 検証レイヤーは、サーバーへのほとんどのリクエストのJSONスキームと、ロードされたスキームに対して受信データをチェックするクラスで構成されます。 受信したパケットがスキームと一致しない場合、アプリケーションによって拒否されます。 呼び出し元のコードはエラー通知を受け取ります。 同様の通知がコンソールログに記録されます。 さらに、サーバーコマンドを呼び出して、エラーに関するレポートをサーバー側に送信できます。 主なことは、そのようなメッセージを送信するコマンドが何らかのエラー（4xxまたは5xx）を引き起こす場合、再帰から抜け出す方法を提供することです。

次のデータをサーバーに送信することは理にかなっています。

• エラーが発生したアカウント。
• どのチームがエラーを引き起こしました。
• サーバーに転送されたデータ。
• サーバーから受信した応答。
• UTC時間*
• チームのステータスコード。 検証エラーの場合、常に200です。
• サーバーの応答が満たさないスキーム。

* UTC時間は、コマンドが呼び出された時刻であり、応答がサーバーに返された時刻ではありません。 原則として、それらは一致しますが、アプリケーションには要求キューメカニズムがあるため、理論的には、失敗したコマンドの呼び出しとサーバーによるレコードの記録の間に月が経過する可能性があります。

JSON要求スキームは、新しいAPIコマンドを実装した後にサーバー開発者によって提供されると想定されています。



各スキームおよび各チームは、以前に合意した特定の基準を満たす義務があります。 上記の例では、サーバー応答には2つのメインフィールドと1つのオプションフィールドが含まれている必要があります。

「ステータス」が必要です。 OKまたはERROR識別子（または「200」タイプのHTTPコード）が含まれます。

「Reason」が必要エラーが発生した場合、エラーの原因の説明が含まれます。 それ以外の場合、このフィールドは空です。

「データ」はオプションです。 コマンドの結果が含まれます。 エラーの場合、欠落

回路例：



Maxim Luninによって開発されたライブラリのおかげで、非常に簡単になりました。 （ habrahabr.ru/post/180923 ）



検証クラスコードを以下に示します。



検証呼び出しは非常に簡単です。



ネットワークアイテムレイヤー：

JSONからデシリアライズされた表現へのデータのマッピングを担当するのはこのレイヤー上です。 この層は、オブジェクトまたはオブジェクトリレーショナル変換を実装するクラスを記述するために使用されます。 ネットワーク上には、オブジェクトリレーショナル変換を実装する多数のライブラリがあります。 たとえば、JSONモデル（ github.com/icanzilb/JSONModel ）または同じMaxim Luninライブラリ。 しかし、すべてがそれほどバラ色ではありません。 マッピングの問題を軽減しません。



マッピングとは何かを説明しましょう：

構造内に同一のデータを返す2つのクエリがあるとします。 たとえば、アプリケーションのユーザー、および「識別子」や「ユーザー名」などのフィールドを持つユーザーの友人。 問題は、サーバー開発者が1つのリクエストで「id」、「username」、2番目の「ident」、「user_name」のフィールドを渡すことができることです。 このような不一致は、一連のトラブルを引き起こす可能性があります。

1. CoreDataを使用する場合、Objective-Cのデシリアライズされたデータオブジェクトはidフィールドを持つことができません
2. idおよびidentフィールドのシリアル化されたデータには、文字列またはNSNumberを含めることができます。 コンソールに表示する場合、2つの数字に違いはありませんが、違いはありません。 それらのハッシュコードは異なり、辞書はこれらのフィールドの意味を異なって認識します。
3. フィールド名の違いはサーバーの責任であり、サーバー開発者は名前をクライアント開発者にとって便利な統一された名前に置き換えるために、単に連絡を取らない場合があります。

これらの問題に対する普遍的な解決策はありませんが、重大な知的努力を必要とするほど複雑ではありません。



ローカルキャッシュレイヤー：







このレイヤーのタスクは次のとおりです。

1. ネットワークからダウンロードした画像をキャッシュします。
2. サーバーのリクエスト/レスポンスのキャッシュ
3. ネットワークおよびオフラインのユーザー作業がない場合に、要求のキューを形成します。
4. キャッシュされたデータを監視し、期限切れのデータを消去します。
5. 指定されたオブジェクトに関する情報をネットワークから受信できないことに関するアプリケーションの通知。

一般に、このレイヤーは別の大きな記事のトピックです。 しかし、開発者が考慮すべき微妙な違いがいくつかあります。

クエリキャッシングの場合、リスト1の手順をわずかにアップグレードできます。これには仮想メソッドを使用することを強くお勧めしますが、簡単にするために、クラスメソッドへの直接呼び出しを示します。



HttpCacheクラスには、クエリ結果を保存するメソッドに加えて、別の興味深いメソッドがあります。





これにより、受信したパケットの有効期限（日付が期限切れになる秒数）に関するサーバー応答ヘッダーからキー情報を抽出できます。 この情報を使用して、ローカルストレージにデータを書き込むことができ、同じリクエストを繰り返した場合は、以前に受信したデータを読み取るだけです。 メソッドが0を返す場合、そのようなデータは書き込めません。

したがって、サーバー上で、クライアント上で正確にキャッシュされるものを規制することができます。 標準のヘッダーフィールドが使用されていることに注意してください。 そのため、標準に関しては、自転車は発明されていません。



リスト1に別の小さな変更を加えると、キューの問題は簡単に解決されます。



HttpQueueクラスは、現在ネットワーク接続が存在するかどうかをチェックし、存在しない場合は、リクエストがミリ秒まで行われる時間でリクエストをリポジトリに書き込みます。 接続が再開されると、データはストレージから読み取られ、サーバーから転送されますが、要求キューはクリアされます。 これにより、ネットワークに直接接続せずに特定のクライアント/サーバー操作を提供できます。



ネットワーク接続の確認は、オブザーバーパターンと組み合わせてApple AFNetworkReachabilityManagerまたはReachabilityクラス（ developer.apple.com/library/ios/samplecode/Reachability/Introduction/Intro.html ）を使用して行われます。 彼のデバイスは、記事で説明するには原始的すぎます。

ただし、すべての要求をキューに送信する必要はありません。 それらのいくつかは、ネットワークの出現時に関係ない場合があります。 どのコマンドをキューキャッシュに書き込むか、およびキャッシュレイヤーレベルとAPIレイヤーレベルの両方で呼び出し時にのみ関連するコマンドを決定することができます。



リスト9の最初のケースでは、キューでsaveメソッドを呼び出す代わりに、仮想メソッドを挿入し、ApiLayerクラスから継承してLocalCacheLayerWithQueueおよびLocalCacheLayerWithoutQueueクラスを継承する必要があります。 次に、LocalCacheLayerWithQueueクラスの指定された仮想メソッドで、呼び出しを行います[HttpQueue request：endpoint：method：]



2番目のケースでは、ApiLayerクラスからのリクエスト呼び出しはわずかに変更されます





リスト9は、（queueAvailable）が提供されている場合のまさにこのケースです。



また、別の問題は画像キャッシュの問題です。 一般的に、質問は複雑ではないため、実装数は無限です。 たとえば、SDWebImageライブラリはこれを非常にうまく行います：（ github.com/rs/SDWebImage ）。



一方、彼女が行う方法を知らないことがいくつかあります。 たとえば、指定された基準（画像の数、作成された日付など）に従って画像キャッシュをクリアしたり、特定のエラーをログに記録したり修正したりすることはできません。



ネットワークから画像を非同期でダウンロードし、MIMEエラーを修正する例を示します（たとえば、Amazonは多くの場合、Webサーバーが画像を送信する結果として、画像付きのバイナリファイルではなくデータストリームとして間違ったMIMEタイプを提供します）。



この方法は非常に冗長に見えるかもしれませんが、開発者の特定のニーズに合わせて簡単に変更できます。 重要な点のうち、画像URLのハッシュがキャッシュのキーとして使用されることに注意する必要があります。 このアプローチでは、デバイスのファイルシステム内で衝突が発生することはほとんどありません。

ファイルがキャッシュから読み取られるたびに、アクセス日が変更されます。 長時間再読み込みされないファイルは、アプリケーションの起動時でも安全に削除できます。



アプリケーションバンドルからのファイルの読み取りに関しては、開発者が忘れているニュアンスがあります。iOSSDKは、[UIImage imageNamed：]や[UIImage imageWithContentsOfFile：]などのメソッドを提供します。 最初のものを使用する方が簡単ですが、メモリの負荷に大きく影響します。実際には、ダウンロードされたファイルはアプリケーションが完了するまでデバイスのメモリに残ります。 これが大容量のファイルである場合、これは問題になる可能性があります。 2番目の方法をできるだけ頻繁に使用することをお勧めします。 さらに、ロード方法をわずかに改善すると便利です。



これで、ファイルがどの解像度で存在するかを気にする必要がなくなりました。



ワークフローレイヤー：

カーネルレイヤーに属さず、GUIを構成しない実装済みアルゴリズムはすべて、特定の一連のワークプロセスのクラスに配置する必要があります。 これらのプロセスはそれぞれ独自のスタイルで設計されており、GUIの対応するクラスのインスタンスにリンクを追加することにより、アプリケーションの主要部分に接続します。 ほとんどの場合、これらのプロセスはすべて視覚的ではありません。 ただし、たとえば、指定された表示アルゴリズムを使用して、事前定義されたアニメーションフレームの長いシーケンスを実装する必要がある場合など、いくつかの例外があります。

. flow . Google , , .





, , . . , , , .



, . «» « ». , «» «» .

— — « ». , flow «» , (Network Layer, Validation Items).



(callback), . , .

, , - . , . , , , , . , — , . . . , , .



Local storage:

, , , , . CoreData. , , , Apple , .

. CoreData , . , , CoreData . , , , , , , .



CoreData ( habrahabr.ru/post/191334 ), , , , , .



, . , , .







NSDictionary :

1. , .
2. , POST (. . , , , POST ).
3. .
4. .
5. ACID : en.wikipedia.org/wiki/ACID
6. .
7. .
8. .
9. (1 ).

/ iOS SDK NSDictionary , .



, . , .



, , , , 5, , , , , , , ViewController . () SQL ( ), , , . , , . , .



CoreData.



CoreData . - , . API profile, copyDataFromRemoteJSON, , ( NSManagedObject).

, :





, callback API , , , .



:

1. .
2. , . .
3. , , .
4. ( ) . .
5. . (. . , , , , /, , ).
6. ,

:

, NSFetchController , . , . . - . . , , , .



:

1. , ( ):
2. , , SQLite , «» . , - , , CoreData SQLite.
3. , .
4. . , , . , .
5. Database , , , .
6. ACID SQLite CoreData. . MagicRecords.
7. . , , , , .
8. CoreData . , CoreData .
9. , , , . , CoreData .
10. , . , CoreData .

- , :

1. CoreData , .
2. , 4S .
3. . , MagicalRecords (https://github.com/magicalpanda/MagicalRecord) .

CoreData, , , . — CoreData , , , , NoSQL XML.



MagicalRecords , UITableViewController, NSFetchController CoreData. , , . . . CoreData UI.







, CoreData , , , , :



1

API . , , , .

:

, .

, , .

.



2

: CoreData JSON , . , , , .

:

1. « » JSON .
2. , . . .
3. .
4. , .
5. SQLite .
6. .

結論：

, , , . , , GUI . -, UITabbar, -, , MVC MVVM. , . . , , .

, , .