Swiftyinsta: Caminho para `2.0`

Olá Stefano,
Devo agradecer a você por me ajudar e contribuir com esta biblioteca, não há nada mais do que sua participação me deixa feliz.
Esta é uma boa ideia, saltando para a versão 2.0 com bons recursos e mudanças.
Eu estava pensando em implementar algumas funções extras que ajudam o usuário a lidar com a biblioteca mais facilmente,
características como receber:

• Mídia de alta qualidade [vídeo ou imagem]
• Mídia de baixa qualidade [vídeo ou imagem]
• Miniatura de imagem para mídia
• Funções estatísticas (calculando o total de curtidas, comentários, ...)
• Recurso de atraso mais flexível (editando-o em tempo de execução ou ligando-o e desligando-o) com maneiras mais fáceis.
• e etc....
  o que economiza muito tempo para os usuários, são apenas ideias.
  Como a biblioteca está crescendo com o passar do tempo, a biblioteca definitivamente precisa de documentação .
  definitivamente precisamos corrigir as convenções de nomenclatura, porque há muitos erros. e eu gosto da ideia UserReference que foi legal.
  development ramificação
  devemos convidar outros usuários para contribuir e compartilhar ideias aqui para tornar a próxima versão mais poderosa.
  Obrigado novamente.
  Cumprimentos.

1. manipulador de permissões mais fácil, descartando o modelo Singleton e todos os .shared , permitindo que os usuários executem várias contas ao mesmo tempo [eu posso começar a trabalhar nisso hoje ou amanhã, se estiver tudo bem]

Comecei a trabalhar nisso. O mecanismo de autenticação real está em vigor, só preciso terminar de reescrever cada método para todos os diferentes manipuladores (😱) e, em seguida, basta fazer as mesmas alterações em Siwa .

O que eu fiz até agora:

• APIBuilder , HttpSettings e RequestMessageModel sumiram. Agora você instancia diretamente APIHandler com alguns Settings pegando (opcional) delay , queues , device (atualizando automaticamente o User-Agent ) e session ( URLSession ).
• Não há mais protocolos *Handler . Não havia nenhum ponto real para eles. Cada *Handler agora pode ser chamado através da instância APIHandler ( UserHandler é .accounts , FeedHandler é .feeds , etc. .), são propriedades preguiçosas e específicas da própria instância. Eu fiz o mesmo para HttpHelper e PaginationHelper (também conhecido PaginationHandler em 1.* ). Isso remove toda a duplicação de código onde cada método teve que ser reescrito para APIHandler , e isso significa " multitarefa " com vários APIHandler s para diferentes usuários logados.
• A autenticação agora é tratada por um único método na instância APIHandler : authenticate(with request: Login.Request, completionHandler: escaping (Result<(Login.Response, APIHandler), Error>) -> Void) , onde Login.Request é um enum que pode levar um SessionCache item (que é semelhante a 1.* SessionCache ), e é usado para "fazer login novamente" e com Siwa (no futuro), ou um LoginWebView (também conhecido InstagramLoginWebView ) — e é muito mais simples do que é agora. Literalmente uma ligação e pronto. Isso remove toda a duplicação de código entre Siwa e SwiftyInsta : se você quiser autenticação "headless", use Siwa e passe o sessionCache , caso contrário use o _web ver_ em SwiftyInsta .
• Cada método que aceita um _user_ pk ou username agora leva um item UserReference .

Conto terminar tudo até amanhã, e então eu poderia empurrar para development para mais testes. Estou realmente super animada 💪
Estou ansioso para saber seus pensamentos e opiniões.

As mudanças parecem muito boas, development branch adicionado também.
Estou trabalhando em uma lista de recursos e ferramentas como Logger e etc.
E sobre Autenticação, este novo método suporta todos os 3 tipos de autenticações?

1. Login privado da API
2. Login na Web
3. Siwa

Eu terminei com todas as mudanças acima. Estou testando por um tempo e, em seguida, envio um _pull request_.

E sobre Autenticação, este novo método suporta todos os 3 tipos de autenticações?

No momento, ele suporta _web login_ e Siwa (teoricamente, já que Siwa usa *.shared , então ele precisará ser atualizado, mas estou planejando fazê-lo o mais rápido possível - ou seja, certo agora , enquanto isso, você só pode testá-lo com _web login_). Eu sinto que a autenticação username + password fornecida com SwiftyInsta não estava à altura, tbh. E como você fez um trabalho incrível em Siwa , eu realmente sinto que ele pode ser retirado da biblioteca principal (mas é apenas minha opinião).
Acredito fortemente que os usuários que desejam fazer autenticação username + password devem fazê-lo desde o início (ou seja, com Siwa ), sem complicar demais todo o resto e duplicar bases de código. Novamente, apenas minha opinião.
Também pode ser adicionado novamente 😊

(Tentei corrigir erros de digitação e erros ao longo do caminho quando os vi, mas sinto que alguns métodos - por exemplo, os estranhos POST , podem ainda não funcionar como pretendido. Eles não funcionaram em 1.* e eles podem não estar em 2.0 . Idk)

@sbertix @canaksoy
Mais ideias? Qualquer atualização?

Suporte para watchOS , tvOS e macOS

Eu estava pensando em suporte a vários sistemas operacionais # 61
Vou tentar trabalhar nisso mais tarde.

Respostas de limpeza

• Mídia de alta qualidade [vídeo ou imagem]
• Mídia de baixa qualidade [vídeo ou imagem]
• Miniatura de imagem para mídia
• Funções estatísticas (calculando o total de curtidas, comentários, ...)
• Recurso de atraso mais flexível (editando-o em tempo de execução ou ligando-o e desligando-o) com maneiras mais fáceis.
• e etc....

Sobre isso, fiquei pensando… por que não racionalizar a forma como as respostas são apresentadas ao usuário?
Ao invés de retornar diretamente o arquivo decodificado (que poderia se tornar uma propriedade raw ), por que não retornar um struct limpo, com data já formatada, imagens com qualidades diferentes (como você disse), estatísticas embutidos neles... etc.

por exemplo, em vez de empurrar MediaModel como está, retornando algo mais próximo de…

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 */
}

Sim, esta é uma boa ideia, devemos editar modelos de qualquer maneira. alguns deles estão faltando algumas propriedades e há muitas duplicatas entre os modelos de protocolos inúteis e ....
Devemos definitivamente melhorar os modelos e a forma como eles representam os dados para o usuário.

Que tal impor regras de sintaxe por meio de swiftlint ?
Fácil de adicionar suporte para Travis CI , mas na verdade super longo para alterar toda a base de código de acordo.
Mas deve valer a pena, imho.
O que você acha? @TheM4hd1