Swiftyinsta: `2.0`への道

こんにちはステファノ、
私を助け、この図書館に貢献してくれたあなたに感謝しなければなりません。あなたの参加が私を幸せにすることに他なりません。
これは良い考えであり、優れた機能と変更を加えたバージョン2.0にジャンプします。
私は、ユーザーがライブラリをより簡単に扱うのに役立ついくつかの追加機能を実装することを考えていました。
受信などの機能：

• 高品質メディア[ビデオまたは画像]
• 低品質メディア[ビデオまたは画像]
• メディア用画像サムネイル
• 統計機能（いいね、コメントの合計を計算する、...）
• より柔軟な遅延機能（実行時に編集するか、オン/オフを切り替える）と簡単な方法。
• や。。など....
  これはユーザーの時間を大幅に節約します。これらは単なるアイデアです。
  図書館は時を経て成長しているので、図書館には間違いなくドキュメントが必要です。
  非常に間違いがあるので、命名規則を修正する必要があります。そして私はUserReferenceアイデアが好きです。
  developmentブランチも必要です。
  次のバージョンをより強力にするために、他のユーザーを招待して、ここでアイデアを提供および共有する必要があります。
  再度、感謝します。
  よろしく。

1. より簡単なパーミッションハンドラー、シングルトンモデルとすべての.shared削除し、ユーザーが同時に複数のアカウントを実行できるようにします[問題がなければ、今日または明日から作業を開始する可能性があります]

私はこれに取り組み始めました。 実際の認証メカニズムが整っているので、すべての異なるハンドラーのすべてのメソッドを書き直す必要があります（😱）。その後、 Siwa同じ変更を加えるだけです。

私がこれまでにしたこと：

• APIBuilder 、 HttpSettings 、 RequestMessageModelはなくなりました。 ここで、 APIHandlerを直接インスタンス化し、 Settingsを使用します（オプション） delay 、 queues 、 device （ User-Agent自動的に更新します） session （ URLSession ）パラメーター。
• これ以上*Handlerプロトコルはありません。 彼らにとって実際のポイントはありませんでした。 すべての*Handlerは、 APIHandlerインスタンスを介して呼び出すことができるようになりました（ UserHandlerは.accounts 、 FeedHandlerは.feedsなど） 。）、それらは怠惰なプロパティであり、インスタンス自体に固有です。 HttpHelperとPaginationHelper （ 1.* PaginationHandlerについても同じことをしました。 これにより、すべてのメソッドをAPIHandlerで書き直す必要があったすべてのコードの重複がなくなります。これは、ログに記録されたさまざまなユーザーに対して複数のAPIHandlerを使用する「マルチタスク」を意味します。
• 認証は、 APIHandlerインスタンスの1つのメソッドauthenticate(with request: Login.Request, completionHandler: escaping (Result<(Login.Response, APIHandler), Error>) -> Void)によって処理されるようになりました。ここで、 Login.Requestはenumであり、 SessionCache取ることができます。 1.* SessionCache似ています）。これは「ログインし直す」ために使用され、 Siwa （将来）またはLoginWebView （別名InstagramLoginWebView ）—そしてそれは現在よりもSiwaとSwiftyInsta間のすべてのコード重複が削除されます。「ヘッドレス」認証が必要な場合は、 Siwaを使用してsessionCache渡します。それ以外の場合は、_webを使用します。 view_ in SwiftyInsta 。
• _user_ pkまたはusernameいずれかを受け入れるすべてのメソッドは、代わりにUserReferenceアイテムを受け取るようになりました。

私は明日までにすべてを終えることを期待しています、そしてそれから私はさらなるテストのためにそれをdevelopmentにプッシュすることができました。 私は本当にとても興奮しています💪
ご意見・ご感想をお待ちしております。

変更は非常に良いようで、 developmentブランチも追加されました。
Loggerなどの機能とツールのリストに取り組んでいます。
そして、認証について、この新しい方法は3種類の認証すべてをサポートしますか？

1. プライベートAPIログイン
2. Webログイン
3. シワ

上記のすべての変更は完了です。 しばらくテストしてから、_pullrequest_をプッシュします。

そして、認証について、この新しい方法は3種類の認証すべてをサポートしますか？

現在、_web login_とSiwaサポートしています（理論的にはSiwaは*.sharedを使用するため、更新する必要がありますが、できるだけ早く実行する予定です。つまり、正しいことを意味しSwiftyInsta提供されるusername + password認証は、標準に達していなかったようです。 そして、あなたはそれのためにSiwaで素晴らしい仕事をしたので、私はそれがメインライブラリからドロップできるように本当に感じています（しかしそれは私の意見です）。
username + password認証を実行したいユーザーは、他のすべてを過度に複雑にしたり、コードベースを複製したりせずに、最初から（つまり、 Siwa ）認証を実行する必要があると強く信じています。 繰り返しますが、私の意見です。
もう一度追加することもできます😊

（タイプミスを修正しようとしましたが、それらを見つけたときに間違いがありましたが、いくつかの方法のように感じます。たとえば、奇妙なPOSTは、意図したとおりに機能しない可能性があります。 1.*では機能しませんでした。 2.0れていない可能性があります。Idk）

@sbertix @canaksoy
他のアイデア？ すべてのアップデート？

watchOS 、 tvOS 、 macOSサポート

マルチOSサポート＃61を考えていました
後でやってみます。

クリーニング応答

• 高品質メディア[ビデオまたは画像]
• 低品質メディア[ビデオまたは画像]
• メディア用画像サムネイル
• 統計機能（いいね、コメントの合計を計算する、...）
• より柔軟な遅延機能（実行時に編集するか、オン/オフを切り替える）と簡単な方法。
• や。。など....

これについて、私は考えていました…応答がユーザーに提示される方法を合理化してみませんか？
デコードされたファイル（ rawプロパティのようになる可能性があります）を直接返す代わりに、日付が既にフォーマットされた、品質の異なる画像（あなたが言ったように）、統計情報を含む、クリーンアップされたstruct返しませんか？それらに埋め込まれています…など。

たとえば、 MediaModelをそのままプッシュする代わりに、…に近いものを返します。

public struct MediaModel: Codable {
    /// `MediaModelJSON` would be equal to current `MediaModel`.
    public let rawResponse: MediaModelJSON

    // Accesories
    public var pk: Int! { return rawResponse.pk }
    public lazy var date: Date! = { return self.rawRespone.takenAt.flatMap { Date(timeIntervalSince1970: $0) }}()
    /* etc */
}

はい、これは良い考えです。とにかくモデルを編集する必要があります。 それらのいくつかはいくつかのプロパティを欠いており、モデルの役に立たないプロトコルと...の間で多くの重複があります。
モデルと、モデルがユーザーにデータを表す方法を確実に改善する必要があります。

swiftlint介して構文規則を適用するのはどうですか？
Travis CIにサポートを追加するのは簡単ですが、実際にはコードベース全体をそれに応じて変更するには非常に長い時間がかかります。
しかし、それは価値があるはずです、imho。
どう思いますか？ @ TheM4hd1