Swiftyinsta: Camino a `2.0`

Hola Stefano,
Debo decirte gracias por ayudarme y aportar esta biblioteca, no hay nada más que tu participación me hace feliz.
Esta es una buena idea, saltar a la versión 2.0 con buenas funciones y cambios.
Estaba pensando en implementar algunas funciones adicionales que ayuden al usuario a manejar la biblioteca más fácilmente,
características como recibir:

• Medios de alta calidad [video o imagen]
• Medios de baja calidad [video o imagen]
• Miniatura de imagen para medios
• Funciones estadísticas (cálculo de me gusta totales, comentarios, ...)
• Función de retraso más flexible (editándola en tiempo de ejecución o encendiéndola) con formas más fáciles.
• y etc....
  lo que ahorra mucho tiempo a los usuarios, estas son solo ideas.
  Debido a que la biblioteca está creciendo con el paso del tiempo, la biblioteca definitivamente necesita documentación .
  definitivamente necesitamos corregir las convenciones de nomenclatura, porque hay muchos errores. y me gusta la idea de UserReference que fue buena.
  También se necesita la sucursal development .
  deberíamos invitar a otros usuarios a contribuir y compartir ideas aquí para hacer que la próxima versión sea más poderosa.
  Gracias de nuevo.
  Saludos.

1. manejador de permisos más fácil, eliminando el modelo Singleton y todo el .shared , permitiendo a los usuarios ejecutar varias cuentas al mismo tiempo [podría comenzar a trabajar en esto hoy o mañana, si está bien]

He empezado a trabajar en esto. El mecanismo de autenticación real está en su lugar, solo necesito terminar de reescribir cada método para todos los diferentes controladores (😱), y luego todo lo que se necesita es hacer los mismos cambios en Siwa .

Lo que he hecho hasta ahora:

• APIBuilder , HttpSettings y RequestMessageModel se han ido. Ahora instancia directamente APIHandler con algunos Settings tomando (opcional) delay , queues , device (actualizando automáticamente el User-Agent ) y session ( URLSession ) parámetros.
• No más *Handler protocolos. No había ningún punto real para ellos. Cada *Handler ahora se puede llamar a través de la instancia de APIHandler ( UserHandler es .accounts , FeedHandler es .feeds , etc. .), son propiedades perezosas y son específicas de la instancia en sí. He hecho lo mismo para HttpHelper y PaginationHelper (también conocido como PaginationHandler en 1.* ). Esto elimina toda la duplicación de código donde cada método individual tuvo que ser reescrito por APIHandler , y significa " multitarea " con múltiples APIHandler s para diferentes usuarios registrados.
• La autenticación ahora se maneja mediante un solo método en la instancia de APIHandler : authenticate(with request: Login.Request, completionHandler: escaping (Result<(Login.Response, APIHandler), Error>) -> Void) , donde Login.Request es un enum que puede tomar un SessionCache elemento (que es similar a 1.* SessionCache ), y se usa para "volver a iniciar sesión" y con Siwa (en el futuro), o un LoginWebView (también conocido como InstagramLoginWebView ), y es mucho más simple de lo que es ahora. Literalmente una llamada y listo. Esto elimina toda la duplicación de código entre Siwa y SwiftyInsta : si desea autenticación "sin cabeza", use Siwa y pase sessionCache , de lo contrario use _web ver_ en SwiftyInsta .
• Todos los métodos que aceptan un _user_ pk o username ahora aceptan un elemento UserReference lugar.

Cuento con terminar todo para mañana, y luego podría empujarlo a development para realizar más pruebas. Estoy realmente súper emocionada 💪
Estoy deseando conocer vuestros pensamientos y opiniones.

Los cambios parecen muy buenos, también se agregó la rama development .
Estoy trabajando en una lista de características y herramientas como Logger y etc.
Y sobre la autenticación, ¿este nuevo método admite los 3 tipos de autenticación?

1. Inicio de sesión de API privada
2. Inicio de sesión web
3. Siwa

He terminado con todos los cambios anteriores. Lo estoy probando por un tiempo y luego envío una _solicitud de extracción_.

Y sobre la autenticación, ¿este nuevo método admite los 3 tipos de autenticación?

En este momento es compatible con _web login_ y Siwa (teóricamente, ya que Siwa usa *.shared , por lo que deberá actualizarse, pero planeo hacerlo lo antes posible, es decir, correcto ahora , mientras tanto, solo puedes probarlo con _web login_). Siento que la autenticación username + password provista con SwiftyInsta no estuvo a la altura, tbh. Y dado que ha hecho un trabajo increíble en Siwa , realmente siento que se puede eliminar de la biblioteca principal (pero es solo mi opinión).
Creo firmemente que los usuarios que deseen realizar una autenticación username + password deberían hacerlo desde el principio (es decir, con Siwa ), sin complicar demasiado todo lo demás ni duplicar las bases de código. Nuevamente, solo mi opinión.
También se puede agregar de nuevo 😊

(Traté de corregir errores tipográficos y errores en el camino cuando los descubrí, pero siento que algunos métodos, por ejemplo, los extraños POST , podrían no funcionar como se esperaba. No lo hicieron en 1.* y es posible que no estén en 2.0 . Idk)

@sbertix @canaksoy
¿Más ideas? ¿cualquier actualización?

Soporte para watchOS , tvOS y macOS

Estaba pensando en la compatibilidad con múltiples sistemas operativos # 61
Intentaré trabajar en ello más tarde.

Respuestas de limpieza

• Medios de alta calidad [video o imagen]
• Medios de baja calidad [video o imagen]
• Miniatura de imagen para medios
• Funciones estadísticas (cálculo de me gusta totales, comentarios, ...)
• Función de retraso más flexible (editándola en tiempo de ejecución o encendiéndola) con formas más fáciles.
• y etc....

Sobre esto, estaba pensando… ¿por qué no racionalizar la forma en que se presentan las respuestas al usuario?
En lugar de devolver directamente el archivo decodificado (que podría convertirse en una propiedad raw ), ¿por qué no devolver un struct limpio, con la fecha ya formateada, imágenes con diferentes calidades (como dijiste), estadísticas? incrustados en ellos... etc.

por ejemplo, en lugar de empujar MediaModel como está, devolviendo algo más cercano a...

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

Sí, esta es una buena idea, deberíamos editar modelos de todos modos. a algunos les faltan algunas propiedades y hay muchos duplicados entre modelos, protocolos inútiles y....
Definitivamente deberíamos mejorar los modelos y la forma en que representan los datos para el usuario.

¿Qué hay de hacer cumplir las reglas de sintaxis a través de swiftlint ?
Fácil de agregar soporte para Travis CI , pero en realidad muy largo para cambiar todo el código base en consecuencia.
Pero debería valer la pena, en mi humilde opinión.
¿Qué piensas? @TheM4hd1