Anciens Pods, Dépendances, Logging, pétage de plomb

LeChatNoirLeChatNoir Membre, Modérateur

Salut à tous,

Hier, j'ai cru devenir fou et revenir à mes jeunes années de débutant :(

La faute à une appli qui devient complexe par manque de temps.

J'utilise un framework à travers CocoaPod qui lui même a une dépendance vers CocoaLumberJack. Mais la dépendance est du type "~>1.x". Or CocoaLumberJack a bien évolué entre temps et est en version 3 ou 4.x.

Jusqu'à présent, pas de soucis, je n'utilisais pas LumberJack.

Or, j'ai un bug utilisateur impossible à reproduire pour moi.

Du coup, j'ai pensé à faire une version TestFlight dans laquelle j'ajouterai de la log dans un fichier puis un envoi de ce fichier.
CocoaLumberJack permet de faire ça.

J'ai donc décidé de l'utiliser. C'est là que les pb commencent...

J'arrive à utiliser la version 1.9 embarquée dans mes pods.

Or cette version étant vieille, elle n'a pas de directive @objC. Donc dans mon app, je ne peux pas l'utiliser partout où j'ai du swift...

Après, j'suis parti en live complet. J'ai voulu virer mon pod qui utilise LumberJack, récup' le code pour l'intégrer direct dans mon app, y virer l'utilisation de LumberJack et intégrer la nouvelle version.

Bref, j'ai tout casser. Et à 4h du mat', j'ai laché l'affaire...

Vous l'aurez compris, c'est un peu une bouteille à la mer que je lance.

Si quelqu'un a une bonne idée pour m'aider dans ce debugging, je suis preneur.
Peut être que l'idée de logger dans un fichier n'est pas la meilleure...

C'est un pb de restauration d'achat InApp. Pas trivial comme truc. J'ai un utilisateur (un seul mais j'ai peur que ca se propage) pour qui la restauration plante systématiquement.

Merci de votre écoute !

Réponses

  • LarmeLarme Membre

    Quid de faire un wrapper sur LumberJack en 1.x just pour ton usage que tu appellerais à la main ?
    Sinon, je suppose que ton framework est à jour et que l'auteur n'a jamais mis à jour son LumberJack?

  • LeChatNoirLeChatNoir Membre, Modérateur

    Non mon framework n'est pas à jour mais les versions plus récentes pètent tout. Et bien sûr, je n'ai jamais pris le temps de m'en occuper :(
    C'est les limites du dev amateur... A un moment donné, ça coince...

    Pour le wrapper, c'est pas idiot et j'y ai pensé. Mais je ne sais pas faire :(

  • LarmeLarme Membre

    Si j'ai bien tout suivi, tu es en Swift, et CocoaLumberJack est en Objective-C.
    Alors je créerais une classe MyCocoaLumberJack en Objective-C, qui fait les appels comme il faut à CocoaLumberJack pour les méthodes/init qui t'intéressent, et de mettre devant les trucs qu'ils te manque actuellement dessus ?

  • LeChatNoirLeChatNoir Membre, Modérateur

    Le pb étant que cette version de cocoaLumberJack n'est pas "swift compliant". C'est à dire qu'elle ne comporte pas les directives @objc. Du coup, je sais pas trop comment faire...

  • LeChatNoirLeChatNoir Membre, Modérateur

    Larme, je vais verser la mienne :)

    Je te remercie pour ta réponse qui m'a guidé vers la lumière ^^

    Effectivement, c'était assez simple.

    Une nouvelle classe en Obj-C lumberWrapper (NSObject) dans laquelle j'importe le module cocoaLumberJack.
    Je définie une méthode pour logger (ex -(void)logInfo:(NSString)toLog fromMethod:(NSString)method;).

    Dans mon bridge.h, j'importe le header de cette classe.

    Et dans mon swift, je n'ai plus qu'à définir une instance et à l'utiliser

    fileprivate let lumberWrapper = CALumberWrapper.init()
    self.lumberWrapper.logInfo("CeQueJeVeuxLogger", fromMethod: "MaMethode")
    

    Merci :smiley:

Connectez-vous ou Inscrivez-vous pour répondre.