Swift + VK.API、またはSwiftyVKのストーリー

今日、私はかつてどのようにSwiftプログラミング言語に精通し、OSXの下でVKontakteソーシャルネットワーク用のアプリケーションを作成することに決めたかについてお話したいと思います（残念ながらまだ終了していません）。 当時、新しい言語を抑制し、VK.APIでそれを越えるときに直面しなければならなかった落とし穴。 このすべての結果を正確に一般に公開し、VK.APIを操作するためにライブラリの形で次の自転車を考え出さなければならなかった理由を正当化するようにしてください。
誰もが興味を持っているなら、猫へようこそ。

パート1：こんにちは、Swift！

2014年6月2日の夕方でした。 Apple製品のユーザーであり、オブジェクト開発者でもない初心者として、私はラップトップの画面に閉じ込められ、そこでWWDC 2014プレゼンテーションのショットが次々と点滅していました。 今回も例外ではありませんでした。 予想通り、超自然的なものは何も提示されず、新しいOSXインターフェイスは少しフラストレーションを残しました。 残りの15分間を調べて、世俗的な事柄に取りかかるつもりでした。 しかし、ここでは、有名な「もう1つ」がなくても、次のXcodeアップデートを装って、Craig FederigiがSwiftという名前の新しいプログラミング言語を紹介します。

それはまさに私が待っていたものでした。 objc構文に慣れようとはしなかったが、多くの点が非常に不便でした。 それは、コードを書く過程で自分自身を定期的に思い出させる致命的なかゆみのようでした。 この日の数週間前に、objcがより人道的で読みやすいものになることを夢見ていたことを覚えています。 私はこれに関するhabrの記事に出くわしましたが、解決策は有用以上のものを妨害する松葉杖であることがわかりました。 そして、これで完了です。 信じられませんでした。 しかし、夕方の残りは間違いなく失われました。 すべての計画は背景に消えていきました。 最初のタスクは、新しいXcodeをすばやくまとめて、この奇妙な鳥が何であるかを調べることでした。 夢の王国が私に手招きをするまで、私はノベルティで遊びました。抵抗する力はもうありませんでした。 しかし、The Swift Programming Languageの在庫を増やして、午前中に新しくリリースされたswiftの複雑さをすべて勉強することに近づいていくことを誓いました。

すぐに言ってやった。 私は自分に割り当てられたタスクを熱心に取り上げました。 私は前述の本全体を読み直し、何が起こっているのかを理解するためにそれからコード例を解析しようと非常に熱心に試みました。 そして、それが完成したとき、彼は基本構造の所有に成功し、この言語に夢中になりました。 簡略化された読み取り可能な構文、静的型付け、オプション値、ジェネリックおよびその他の多くのSwiftのことは、私を無関心にさせませんでした。 絶対にもう老人オブジェクトに戻りたくありませんでした（おそらく時間がかかるでしょう）。

パート2：曲を転送して

だから。 言語トレーニング資料が学習され、基本が分解されたので、ベータ状態のままの言語でアプリケーションを作成するという少し無謀な決定が下されるほど、微妙なところまで深く入りたいと思いました。

その前に、日常的な動作を自動化するための小さなプログラムのみを作成したことは言う価値があります。 それらが単なるスクリプトの一種であるとは言いません。 いいえ、これらは、OOP、マルチスレッド、グラフィカルインターフェイス、さらには正常に動作し、日常生活を楽にするデザインパターンを使用した小さなオブジェクトアプリケーションでした。 今だけ彼らは私のために特定のタスクを解決し、この理由のために彼らが誰かにとって非常に有用になることはありそうにない（彼らを適切な状態に持って行って脇に置くアイデアがあるが、突然私は間違っている）。

私のすべての頭脳の動機は一つの考えでした-このことがないか、私たちが望むように実装されていないなら、私はそれをどのように見たいか知っています、そして私はそれを自分でする必要があります。 今回は同じロジックに従いました。 しばらくの間、OSXでVKontakteソーシャルネットワーク用のアプリケーションを作成するというアイデアが頭にありました。アナログはまったく私に合わなかったからです（リリースにはまだ程遠いため、どのようなアプリケーションかは言いません。これは記事の本質ではありません） 。 このプロジェクトは、私が普段やっていたよりもはるかに大きくなり、通常よりも多くの労力と頭脳を必要としました。 Swiftの開発をさらに深く掘り下げ、保留中のアイデアを実現する良い機会だと思いました。 さらに、私の友人の1人はすでにVK.APIの作業に精通しており、Swiftの学習も望んでいました。 それは私にさらにインスピレーションを与えました。

それで、仕事の後に見たいもののより明確な概念を頭の中に作り込もうとしました。 私の友人がこの考えを持っているので、たった1つだけが、それほど発火しなかった。 しかし、APIを使用して、彼はまだ私を助けてくれました。

最初に思いついたのは、Objective-CのVK.APIを操作するためのライブラリを見つけることでした（Swiftの利点により、プロジェクトでobjcコードを使用できます）。 これにより、開発が大幅に簡素化され、リクエスト/レスポンスのロジックに煩わされることなく、データを受信して​​モデルに分散し、新しいデータをサーバーに送信するだけで済みます。

VKの公式ドキュメントを詳しく調べると、まず公式SDKに注目しました。 iOS用に作成されましたが、どういうわけかOSXにネジ止めできますか？ いいえということが判明しました。 リクエスト自体に加えて、UIKitには多くの関連性があり、AppKitでナットをねじることはほとんど不可能でした。 必死のグーグル検索でも何も得られませんでした。 すべてのライブラリはiOS専用に開発されたか、数年前に著者が未完成の作品をほこりだらけの棚に投げ捨てました。 私に合った選択肢は一つもありません。 もちろん、これは私を悲しませましたが、私はアイデアの実現を取り上げたので、私は停止しませんでした。 ライブラリがありませんか？ 私たちは彼女なしでできる！

パート3：私たちは私たちのもので、新しい家を建てます

最初に行うことは、承認プロセスを把握することでした。 それはすべて、oAuthプロトコルを通過するという理由だけで判明しました。 少なくとも、APIにテストリクエストを送信しようとするために、ブラウザーのアドレスバーから特定の権限を持つトークンにログインしてティアアウトすると、すぐに判明しました。 それからもう少し複雑ですが、これをアプリケーション自体に実装する必要がありました。 承認ページをロードするWebViewが作成され、そのWebFrameLoadDelegateはページのURLを見てトークンをキャッチしました。 最初は、3つのオプションしかありませんでした。URLにトークンがある場合、それを選択してWebViewを削除します。 ユーザーが認証を拒否した場合、アプリケーションを完全に閉じます。突然他のページに移動することにした場合、ユーザーに許可せずに認証に戻ります。

NSURLConnectionを使用して、同期的にリクエストを送信しました。 NSJSONSerializationを使用したParsilの応答と、最終的に次の構成が得られました。

(((jsonObject as? NSDictionary)?["phoneNumbers"] as? NSArray)?[0] as? NSDictionary)?["number"] as? NSString 

同意する、最も楽しい光景ではありません。 この時点で、オプションの操作は地獄に変わります。 問題の詳細については、 こちらをご覧ください 。

ここのどこかで、起こるすべてが良くも便利でもないことが明らかになり始めました。 さらに、APIはエラー、認証要求、認証、キャプチャ入力を返す場合があります。 これらのことは何らかの形で予見され処理される必要があります。 少し考えてから、APIを操作するすべてのロジックを別のライブラリに抽象化することが最も論理的であると判断されました。 第一に、アプリケーション内でVKと通信するためのコードを広めないようにし、第二に、それを再利用して、よりローカルにエラーを排除することが可能になります。 iOSとobjcには多くのライブラリがあるため（公式のSDKは1つで十分ですが）、SwiftとOSX専用に独自のものを作成することにしました。

一般に、iOSで書いた場合、このような問題は発生しませんが、デスクトップまたはラップトップユーザーであり、iOSよりもOSXが大好きなので、私は自分でやることをすべてやります。私がより積極的に使用しているプラ​​ットフォーム。 はい、そして私の謙虚な意見では、より大きな可能性があります。 しかし、味と色...

パート4：開発。 または、SwiftyVKの簡単なレビュー

簡潔な名前VKで最初に登場した構造-エントリポイント、承認、リクエスト作成、および指揮者SwiftyVK。 最初は、承認と認証解除のためのメソッドと、アプリケーションを使用してクラスに実装する必要がある委任プロトコルのドラフトのみがありました。

次に、完全な承認を実装する必要がありました。 既存のソリューションが基礎として採用され、頭に浮かびました。 アプリケーションは、承認中に、取得する権利を譲渡する必要があります。 公式SDKでは、権利のリストは文字列の配列として渡されます。 私はSwift静的型付けを使用することを決定し、権限から列挙型を作成しました。これにより、次のように配列を転送する承認が可能になります。

 [.messages,.offline,.friends,.wall,.photos,.audio,.video,.docs] 

以前は、認証後に受け取ったトークンは、プログラムが終了するまで変数として保存されていました。 今では、ストレージをよりよく管理する必要がありました。 あまり詳しく説明しない場合、これはトークンを含む文字列、その戻りのロジック、および関連性の検証を直接格納するTokenクラスのオブジェクトです。 トークンが古い場合、新しいトークンが要求されます。 トークンはNSCodingプロトコルをサポートし、NSUserDefaultsまたはその他の選択場所に保存できます。 私たちは当然2つのトークンを必要としないため、オブジェクト自体はシングルトンとして存在します。

承認は、シートビューの任意のウィンドウまたは別のウィンドウで開始できます。 ログイン後、APIリクエストの送信を開始します。 応答を送信および受信するロジックを実装する必要がありました。 これは、Request / Connection、Response、NSURLFabricのクラス/構造のグループによって行われます。 ライブラリ自体の外では、最初のものだけが表示されます-要求と、要求を構成し、VKontakteサーバーへの遠隔サイトに送信できるようにするそのプロパティ/メソッドの一部。 接続-要求の送信、応答の待機、エラーの処理、コールバックの呼び出しのロジック。 NSURLFabricは、NSURLRequestから構成され、送信準備が整った状態で収集する静的メソッドを持つファクトリです。 応答は、リクエスト、エラー、成功フィールド、およびサーバーからの応答をエラーまたは成功した応答に解析するロジックを持つ単純な構造です。

NSJSONSerializationを使用してJSONがどのように解析されるかが上に示されました。 値を取得するためのより便利なSwiftネイティブのメソッドを取得するために、最初にこの問題について説明した同じ記事のライブラリを使用しましたが、解析に疑問符が使用される場所が多く残っているため、後でSwiftyJSONに切り替えました私にとって、非常に便利な図書館です。 その助けにより、問題は完全に解決されました。

エラーは、NSErrorに似たErrorクラスに実装されます。 エラーオブジェクトはNSErrorで初期化することもできますが、多くの場合、これはJSONから取得されます。 一部のエラーはSwiftyVKで直接処理されます。 たとえば、アプリケーションが承認を必要とするリクエストを送信したが、承認されていない場合、エラーメッセージが返され、承認ウィンドウが表示され、それを渡すとリクエストがリダイレクトされます。 captchaでも同様です。 この機能を無効にするには、リクエストパラメータcatchErrorsをfalseに設定する必要があります。 次に、既知のSwiftyVKエラーが返された場合でも、エラー処理ブロックが実行されます。

長い間、私は同期リクエストと非同期リクエストに悩まされていました。 マルチスレッドと非同期の複雑さという点ではありません。 ここで複雑なことはありません。 問題は、メインスレッドで同期リクエストを送信したことが原因でした。 この状況は判明する可能性があります-アプリケーションは同期リクエストを送信します。 送信元のストリームは、応答ブロックまたはエラーが呼び出されるまでブロックされます。 APIはエラーを返します。これは、エラーブロックを呼び出す前に認証/キャプチャ入力が必要であることを示します。 ウィンドウはメインスレッドから表示される必要があり、既にブロックされて応答を待機しています。 その結果、デッドロックとタイトハング。 私がこれを回避する松葉杖の方法を考え出そうとしなかった限り、どこかで何かがうまくいきませんでした。 終了-メインスレッドからのエラーチェックを伴う同期リクエストの場合、アサートは、送信してはならない記述とともに機能します。 もちろん、これは最善の方法ではありませんが、いずれにしてもデッドハングよりはましです。

Swiftは強く型付けされた言語であるため、将来間違いを犯す場所ができるだけ少なくなるように、すべてを強く型付けしたかったのです。 おそらく誰かにとって最も議論の余地があるのは、クエリ引数を入力することです。 公式SDKでは、これらは文字列として送信されます。 交差点Arg：Stringを導入することにしました。この引数には、現在可能なすべてのクエリ引数がリストされています。 エラーを最小限に抑えることに加えて、これにより、引数を設定するときにXcodeで自動補完を使用できます。

さらに便利なように、特定のAPIメソッドのリクエストをすばやく作成するためのメソッドのサブグループグループを含むAPI構造が導入されました。 その結果、リクエストの作成は次のようになります。

  let req = VK.API.Friends.get([ .count : "1", .fields : "city,domain" ]) 

私にとっては、非常にシンプルで読みやすく、簡潔です。

単純な要求の送信に加えて、カスタムメソッド名（文字列を渡す）、実行、またはリモートプロシージャで要求を送信することができます。 さらに、ファイル読み込み（他のほとんどのライブラリにはない）とLongPoolクライアント（これは他のどこにもありません）の実装。

パート5 最後

原則として、これがSwiftyVKのすべてです。 長い間、私はそれをアップロードしませんでした。なぜなら、私はそれをテストして頭に浮かんだからです。 今、彼は一般の人々と会う準備ができていると思います。 新しい言語の利点を利用して、VK.APIを操作するための最もシンプルで理解しやすいライブラリを作成しようとしました。 開発の最後に、OSXでのみそれを行うという考えに戻り、iOSのピアサポートを追加したと言いたいと思います。 tvOSでもそれをしたかったのですが、まだWebViewがなく、oAuthを使用してログインすることはできません。 できるだけ早く-そうすぐに。 watchOSでは、誰がそれを必要とするかわからないので、それをしないことにしました。 私以外の人がこのライブラリを必要とするかどうかさえわかりません。 しかし、私が間違っていて、誰かがSwiftyVKに興味を持っている場合は、ご利用いただきありがとうございます。 すべての願いについて書いてください-私たちはそれを行います。

英語版のドキュメントとソースコードはこちらで読むことができます 。

PS：この場所を読んでくれたなら、時間をありがとうございました。