Swiftyinsta: En route vers le « 2.0 »

Salut Stefano,
Je dois vous remercier de m'avoir aidé et d'avoir contribué à cette bibliothèque, il n'y a rien de plus que votre participation me rend heureux.
C'est une bonne idée de passer à la version 2.0 avec de bonnes fonctionnalités et des changements.
Je pensais à mettre en œuvre des fonctions supplémentaires qui aident l'utilisateur à gérer plus facilement la bibliothèque,
des fonctionnalités telles que la réception :

• Médias de haute qualité [vidéo ou image]
• Média de faible qualité [vidéo ou image]
• Vignette d'image pour les médias
• Fonctions statistiques (calcul du total des likes, commentaires, ...)
• Fonctionnalité de délai plus flexible (la modifier au cours de l'exécution ou l'activer/la désactiver) avec des moyens plus simples.
• et etc....
  ce qui fait gagner beaucoup de temps aux utilisateurs, ce ne sont que des idées.
  Parce que la bibliothèque grandit en passant le temps, la bibliothèque a définitivement besoin de documentation .
  nous devons absolument corriger les conventions de nommage, car il y a beaucoup d'erreurs. et j'aime l'idée de UserReference qui était sympa.
  development branche
  nous devrions inviter d'autres utilisateurs à contribuer et à partager des idées ici pour rendre la prochaine version plus puissante.
  Merci encore.
  Salutations.

1. gestionnaire d'autorisations plus simple, abandonnant le modèle Singleton et tous les .shared , permettant aux utilisateurs d'exécuter plusieurs comptes en même temps [Je pourrais commencer à travailler dessus aujourd'hui ou demain, si ça va]

J'ai commencé à travailler là-dessus. Le mécanisme d'authentification réel est en place, je dois juste finir de réécrire chaque méthode pour tous les différents gestionnaires (😱), puis tout ce qu'il faut, c'est apporter les mêmes modifications à Siwa .

Ce que j'ai fait jusqu'à présent :

• APIBuilder , HttpSettings et RequestMessageModel ont disparu. Maintenant vous instanciez directement APIHandler avec quelques Settings prenant (facultatif) delay , queues , device (mise à jour automatique du User-Agent ) et session ( URLSession ).
• Plus *Handler protocoles *Handler peut maintenant être appelé via l'instance APIHandler ( UserHandler est .accounts , FeedHandler est .feeds , etc. .), ce sont des propriétés paresseuses et elles sont spécifiques à l'instance elle-même. J'ai fait la même chose pour HttpHelper et PaginationHelper (aka PaginationHandler dans 1.* ). Cela supprime toute la duplication de code où chaque méthode devait être réécrite pour APIHandler , et cela signifie " multitâche " avec plusieurs APIHandler s pour différents utilisateurs connectés.
• L'authentification est désormais gérée par une seule méthode dans l'instance APIHandler : authenticate(with request: Login.Request, completionHandler: escaping (Result<(Login.Response, APIHandler), Error>) -> Void) , où Login.Request est un enum qui peut soit prendre un SessionCache item (qui est similaire à 1.* SessionCache ), et il est utilisé pour "se reconnecter" et avec Siwa (à l'avenir), ou un LoginWebView (aka InstagramLoginWebView ) — et c'est tellement plus simple qu'aujourd'hui. Littéralement un appel et vous avez terminé. Cela supprime toute la duplication de code entre Siwa et SwiftyInsta : si vous voulez une authentification "headless", utilisez Siwa et passez le sessionCache , sinon utilisez le _web vue_ dans SwiftyInsta .
• Chaque méthode unique acceptant un _user_ pk ou username prend désormais un élément UserReference la place.

Je compte tout finir d'ici demain, puis je pourrais le pousser à development pour des tests plus poussés. Je suis vraiment super excité
J'ai hâte de connaître vos pensées et opinions.

Les changements semblent très bons, la branche development a également été ajoutée.
Je travaille sur une liste de fonctionnalités et d'outils tels que Logger et etc.
Et à propos de l'authentification, cette nouvelle méthode prend en charge les 3 types d'authentification ?

1. Connexion API privée
2. Connexion Internet
3. Siwa

J'ai terminé avec tous les changements ci-dessus. Je le teste pendant un moment, puis je fais une _pull request_.

Et à propos de l'authentification, cette nouvelle méthode prend en charge les 3 types d'authentification ?

À l'heure actuelle, il prend en charge _web login_ et Siwa (théoriquement puisque Siwa utilise *.shared , il devra donc être mis à jour, mais je prévois de le faire dès que possible - c'est-à-dire juste maintenant , en attendant, vous ne pouvez le tester qu'avec _web login_). J'ai l'impression que l'authentification username + password fournie avec SwiftyInsta n'était pas à la hauteur, tbh. Et puisque vous avez fait un travail incroyable pour cela dans Siwa , j'ai vraiment l'impression qu'il peut être supprimé de la bibliothèque principale (mais ce n'est que mon opinion).
Je crois fermement que les utilisateurs souhaitant faire username authentification password devraient le faire dès le début (c'est-à-dire avec Siwa ), sans trop compliquer tout le reste, et sans dupliquer les bases de code. Encore une fois, juste mon avis.
Il peut tout aussi bien être rajouté 😊

(J'ai essayé de corriger les fautes de frappe et les erreurs en cours de route lorsque je les ai repérées, mais j'ai l'impression que certaines méthodes - par exemple les étranges POST , pourraient toujours ne pas fonctionner comme prévu. Elles ne l'ont pas fait dans 1.* et ils pourraient ne pas dans 2.0 . Idk)

@sbertix @canaksoy
Plus d'idées ? toute mise à jour?

Prise en charge de watchOS , tvOS et macOS

Je pensais au support multi OS #61
J'essaierai de travailler dessus plus tard.

Réponses de nettoyage

• Médias de haute qualité [vidéo ou image]
• Média de faible qualité [vidéo ou image]
• Vignette d'image pour les médias
• Fonctions statistiques (calcul du total des likes, commentaires, ...)
• Fonctionnalité de délai plus flexible (la modifier au cours de l'exécution ou l'activer/la désactiver) avec des moyens plus simples.
• et etc....

A ce propos, je pensais… pourquoi ne pas rationaliser la manière dont les réponses sont présentées à l'utilisateur ?
Au lieu de retourner directement le fichier décodé (qui pourrait devenir comme une propriété raw ), pourquoi ne pas retourner un struct nettoyé, avec la date déjà formatée, des images avec des qualités différentes (comme vous l'avez dit), des statistiques incrusté dans eux… etc.

par exemple, au lieu de pousser MediaModel comme c'est le cas, retourner quelque chose de plus proche 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 */
}

Oui c'est une bonne idée, nous devrions éditer les modèles de toute façon. certains d'entre eux manquent quelques propriétés et il y a beaucoup de doublons entre les modèles de protocoles inutiles et ....
Nous devons certainement améliorer les modèles et la façon dont ils représentent les données pour l'utilisateur.

Qu'en est-il de l'application des règles de syntaxe via swiftlint ?
Facile à ajouter à la prise en charge de Travis CI , mais en fait très long pour modifier l'ensemble de la base de code en conséquence.
Mais ça devrait valoir le coup, à mon humble avis.
Qu'en penses-tu? @LeM4hd1