Swiftyinsta: 通往“2.0”之路

嗨斯特凡诺，
我必须感谢你帮助我并贡献了这个库，没有什么比你的参与让我高兴了。
这是一个好主意，跳到具有良好功能和更改的2.0 版。
我正在考虑实现一些额外的功能来帮助用户更轻松地处理库，
接收等功能：

• 高质量媒体 [视频或图像]
• 低质量媒体 [视频或图像]
• 媒体的图像缩略图
• 统计功能（计算总喜欢，评论，...）
• 更灵活的延迟功能（在运行时编辑它，或将其打开）以更简单的方式。
• 等等....
  这为用户节省了大量时间，这些只是想法。
  因为图书馆是随着时间的推移而成长起来的，所以图书馆肯定需要文档。
  我们肯定需要修复命名约定，因为有很多错误。 我喜欢UserReference这个不错的主意。
  development分支也是需要的。
  我们应该邀请其他用户在这里贡献和分享想法，以使下一个版本更强大。
  再次感谢。
  问候。

1. 容易许可处理机，丢弃辛格尔顿模型和所有的.shared ，允许用户在同一时间运行多个帐户[我可能会启动这个在今天或明天的工作，如果它的确定]

我已经开始着手这方面的工作了。 实际的身份验证机制已经到位，我只需要为所有不同的处理程序 (😱) 重写每个方法，然后只需对Siwa进行相同的更改。

到目前为止我所做的：

• APIBuilder 、 HttpSettings和RequestMessageModel不见了。 现在您直接实例化APIHandler并使用一些Settings （可选） delay 、 queues 、 device （自动更新User-Agent ) 和session ( URLSession ) 参数。
• 不再有*Handler协议。 他们没有实际意义。 现在可以通过APIHandler实例调用每个*Handler （ UserHandler是.accounts ， FeedHandler是.feeds等.)，它们是惰性属性，并且特定于实例本身。 我对HttpHelper和PaginationHelper （又名PaginationHandler in 1.* ）做了同样的事情。 这消除了所有代码重复，其中每个方法都必须为APIHandler重写，这意味着为不同的登录用户使用多个APIHandler的“多任务处理”。
• 现在，身份验证由APIHandler实例中的一种方法处理： authenticate(with request: Login.Request, completionHandler: escaping (Result<(Login.Response, APIHandler), Error>) -> Void) ，其中Login.Request是一个enum ，它可以采用SessionCache item （类似于1.* SessionCache ），它用于“重新登录”并与Siwa （将来）或LoginWebView （又名InstagramLoginWebView ）——它比现在简单多了。 从字面上看，一个电话，你就完成了。 这将删除Siwa和SwiftyInsta之间的所有代码重复：如果您想要“无头”身份验证，请使用Siwa并传递sessionCache ，否则使用 _web在SwiftyInsta查看_。
• 每个接受 _user_ pk或username现在都需要一个UserReference项目。

我指望在明天之前完成所有事情，然后我可以将其推到development以进行进一步测试。 我真的超级兴奋💪
我期待着了解您的想法和意见。

更改似乎非常好，还添加了development分支。
我正在研究功能和工具列表，例如Logger等。
关于身份验证，这种新方法支持所有 3 种身份验证？

1. 私有 API 登录
2. 网页登录
3. 西瓦

我已完成上述所有更改。 我正在测试它一段时间，然后推送一个_pull request_。

关于身份验证，这种新方法支持所有 3 种身份验证？

现在它支持 _web login_ 和Siwa （理论上因为Siwa使用*.shared ，所以它需要更新，但我打算尽快这样做 - 意思是正确的现在，与此同时，您只能使用 _web login_ 对其进行测试）。 我觉得像username + password认证提供SwiftyInsta是没有达到标准，TBH。 而且由于您在Siwa为它做了出色的工作，我真的觉得它可以从主库中删除（但这只是我的意见）。
我坚信想要进行username + password身份验证的用户应该从一开始就这样做（即使用Siwa ），而不会使其他一切过于复杂，并复制代码库。 再说一次，只是我的看法。
它也可以再次添加😊

（当我发现它们时，我试图修复拼写错误和错误，但我觉得有些方法 - 例如奇怪的POST那些，可能仍然无法按预期工作。他们没有在1.*并且它们可能不在2.0 。Idk）

@sbertix @canaksoy
更多想法？ 任何更新？

支持watchOS 、 tvOS和macOS

我在考虑多操作系统支持 #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 ，但实际上要相应地更改整个代码库的时间很长。
但这应该是值得的，恕我直言。
你怎么认为？ @TheM4hd1