Swiftyinsta: `2.0`으로 가는 길

안녕하세요 스테파노
저를 도와주시고 이 라이브러리에 기여해주셔서 감사합니다. 여러분의 참여가 저를 행복하게 하는 것 이상은 없습니다.
좋은 기능과 변경 사항이 있는 버전 2.0 으로 이동하는 것은 좋은 생각입니다.
나는 사용자가 라이브러리를 더 쉽게 다룰 수 있도록 도와주는 몇 가지 추가 기능을 구현하는 것에 대해 생각하고 있었습니다.
수신과 같은 기능:

• 고품질 미디어 [비디오 또는 이미지]
• 저품질 미디어 [비디오 또는 이미지]
• 미디어용 이미지 축소판
• 통계 기능(총 좋아요, 댓글 계산 등)
• 더 쉬운 방법으로 더 유연한 지연 기능(런타임에서 편집하거나 켜기-끄기).
• 등등....
  이는 사용자에게 많은 시간을 절약해 줍니다. 이는 아이디어일 뿐입니다.
  라이브러리는 시간을 전달하여 성장하고 있기 때문에, 라이브러리는 확실히 문서를 필요로한다.
  매우 실수가 많기 때문에 명명 규칙을 수정해야 합니다. UserReference 아이디어가 좋았습니다.
  development 분기도 필요합니다.
  우리는 다음 버전을 더 강력하게 만들기 위해 다른 사용자를 여기에서 기여하고 아이디어를 공유하도록 초대해야 합니다.
  다시 한번 감사합니다.
  문안 인사.

1. 싱글 톤 모델을 떨어 뜨리고 쉽게 허가 처리기, 모든 .shared , 동시에 여러 계정을 실행하는 사용자를 허용하는 [나는이 오늘 또는 내일 작업을 시작할 수있는 경우의 확인]

이 작업을 시작했습니다. 실제 인증 메커니즘이 준비되어 있습니다. 다른 모든 핸들러(😱)에 대해 모든 단일 메서드를 다시 작성하기만 하면 됩니다. 그런 다음 Siwa 동일한 변경을 적용하기

내가 지금까지 한 일:

• APIBuilder , HttpSettings 및 RequestMessageModel 가 사라졌습니다. 이제 Settings (선택 사항) delay , queues , device (자동으로 User-Agent 업데이트)를 사용하여 APIHandler 를 직접 인스턴스화합니다 delay User-Agent ) 및 session ( URLSession ) 매개변수.
• 더 이상 *Handler 프로토콜이 없습니다. 그들에게는 실질적인 의미가 없었습니다. 모든 *Handler 는 이제 APIHandler 인스턴스를 통해 호출할 수 있습니다( UserHandler is .accounts , FeedHandler is .feeds 등). .), 그것들은 게으른 속성이며 인스턴스 자체에 고유합니다. HttpHelper 및 PaginationHelper ( PaginationHandler 에서 1.* PaginationHandler 라고도 함)에 대해 동일한 작업을 수행했습니다. 이렇게 하면 APIHandler 대해 모든 단일 메서드를 다시 작성해야 하는 코드 중복이 모두 제거되며, 이는 로그인한 사용자마다 APIHandler 여러 개를 사용하는 " 멀티태스킹 "을 의미합니다.
• 인증은 이제 APIHandler 인스턴스에서 하나의 단일 방법으로 처리됩니다. authenticate(with request: Login.Request, completionHandler: escaping (Result<(Login.Response, APIHandler), Error>) -> Void) , 여기서 Login.Request 는 SessionCache 둘 중 하나를 취할 수 있는 enum 입니다 SessionCache 항목( 1.* SessionCache 과 유사)이며 "다시 로그인"하는 데 사용되며 Siwa (향후) 또는 LoginWebView (aka 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_을 통해서만 테스트할 수 있습니다. SwiftyInsta 와 함께 제공되는 username + password 인증이 tbh에 미치지 못한 것 같습니다. 그리고 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 대한 지원을 쉽게 추가할 수 있지만 실제로 전체 코드베이스를 적절하게 변경하는 데는 매우 오래 걸립니다.
하지만 그만한 가치가 있어야 합니다.
어떻게 생각해? @TheM4hd1