XCGLogger
1.0.0
XCGLogger est le module de journal de débogage d'origine à utiliser dans des projets Swift.
SWIFT n'inclut pas de préprocesseur C C, les développeurs ne sont donc pas en mesure d'utiliser les macros de journal de débogage #define qu'ils utiliseraient dans Objective-C. Cela signifie que notre façon traditionnelle de générer de beaux journaux de débogage ne fonctionne plus. Le recours à des appels print tout simplement anciens signifie que vous perdez beaucoup d'informations utiles, ou vous oblige à taper beaucoup plus de code.
XCGLOGGER vous permet de enregistrer les détails de la console (et éventuellement un fichier, ou d'autres destinations personnalisées), tout comme vous le feriez avec NSLog() ou print() , mais avec des informations supplémentaires, telles que la date, le nom de la fonction, le nom de fichier et le numéro de ligne.
Partir de ceci:
Simple message
À ceci:
2014-06-09 06:44:43.600 [Debug] [AppDelegate.swift:40] application(_:didFinishLaunchingWithOptions:): Simple message
Exécuter:
git submodule add https://github.com/DaveWoodCom/XCGLogger.git
dans votre dossier de référentiel.
Ajoutez la ligne suivante à votre Cartfile .
github "DaveWoodCom/XCGLogger" ~> 7.1.5
Ensuite, exécutez carthage update --no-use-binaries ou simplement carthage update . Pour plus de détails sur l'installation et l'utilisation de Carthage, visitez sa page de projet.
Les développeurs exécutés 5.0 et plus dans Swift devront ajouter $(SRCROOT)/Carthage/Build/iOS/ObjcExceptionBridging.framework à leurs fichiers d'entrée dans la phase de construction Copy Carthage Frameworks.
Ajoutez quelque chose de similaire aux lignes suivantes à votre Podfile . Vous devrez peut-être vous ajuster en fonction de votre plate-forme, version / branche, etc.
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '12.0'
use_frameworks!
pod 'XCGLogger', '~> 7.1.5'
La spécification du pod XCGLogger à elle seule comprendra le cadre central. Nous commençons à ajouter des sous-espèces pour vous permettre d'inclure également des composants facultatifs:
pod 'XCGLogger/UserInfoHelpers', '~> 7.1.5' : incluez un code expérimental pour aider à gérer l'utilisation des dictionnaires userInfo pour marquer les messages de journal.
Puis exécutez pod install . Pour plus de détails sur l'installation et l'utilisation de Cocoapods, visitez son site Web officiel.
Remarque: Avant les cocoapodes 1.4.0, il n'a pas été possible d'utiliser plusieurs gousses avec un mélange de versions Swift. Vous devrez peut-être vous assurer que chaque pod est configuré pour la version SWIFT correcte (vérifiez les cibles dans le projet POD de votre espace de travail). Si vous ajustez manuellement la version Swift pour un projet, il réinitialise la prochaine fois que vous exécutez pod install . Vous pouvez ajouter un crochet post_install dans votre podfile pour automatiser les versions Swift correctes. C'est largement non testé, et je ne suis pas sûr que ce soit une bonne solution, mais cela semble fonctionner:
post_install do |installer|
installer.pods_project.targets.each do |target|
if ['SomeTarget-iOS', 'SomeTarget-watchOS'].include? "#{target}"
print "Setting #{target}'s SWIFT_VERSION to 4.2n"
target.build_configurations.each do |config|
config.build_settings['SWIFT_VERSION'] = '4.2'
end
else
print "Setting #{target}'s SWIFT_VERSION to Undefined (Xcode will automatically resolve)n"
target.build_configurations.each do |config|
config.build_settings.delete('SWIFT_VERSION')
end
end
end
print "Setting the default SWIFT_VERSION to 3.2n"
installer.pods_project.build_configurations.each do |config|
config.build_settings['SWIFT_VERSION'] = '3.2'
end
end
Vous pouvez bien sûr l'ajuster en fonction de vos besoins.
Ajoutez l'entrée suivante aux dépendances de votre package:
.Package(url: "https://github.com/DaveWoodCom/XCGLogger.git", majorVersion: 7)
Utiliser:
Cette méthode de démarrage rapide est destinée à vous faire fonctionner avec le journal. Vous devez cependant utiliser l'utilisation avancée ci-dessous pour tirer le meilleur parti de cette bibliothèque.
Ajoutez le projet XCGLogger en tant que sous-projet à votre projet et ajoutez la bibliothèque appropriée comme dépendance de vos cibles. Sous l'onglet General de votre cible, ajoutez XCGLogger.framework et ObjcExceptionBridging.framework à la section Embedded Binaries .
Ensuite, dans chaque fichier source:
import XCGLoggerDans votre appdegate (ou un autre fichier global), déclarez une constante globale à l'instance XCGLogger par défaut.
let log = XCGLogger . defaultDans le
application ( _ application : UIApplication , didFinishLaunchingWithOptions launchOptions : [ UIApplicationLaunchOptionsKey : Any ] ? = nil ) // iOS, tvOSou
applicationDidFinishLaunching ( _ notification : Notification ) // macOSfonction, configurez les options dont vous avez besoin:
log . setup ( level : . debug , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true , writeToFile : " path/to/file " , fileLevel : . debug ) La valeur de writeToFile: peut être une String ou URL . Si le fichier existe déjà, il sera effacé avant de l'utiliser. Omettez le paramètre ou définissez-le sur nil pour enregistrer uniquement sur la console. Vous pouvez éventuellement définir un niveau de journal différent pour la sortie du fichier à l'aide du paramètre fileLevel: :. Réglez-le sur nil ou omettez-le pour utiliser le même niveau de journal que la console.
Ensuite, chaque fois que vous souhaitez enregistrer quelque chose, utilisez l'une des méthodes de commodité:
log . verbose ( " A verbose message, usually useful when working on a specific problem " )
log . debug ( " A debug message " )
log . info ( " An info message, probably useful to power users looking in console.app " )
log . notice ( " A notice message " )
log . warning ( " A warning message, may indicate a possible error " )
log . error ( " An error occurred, but it's recoverable, just info about what happened " )
log . severe ( " A severe error occurred, we are likely about to crash now " )
log . alert ( " An alert error occurred, a log destination could be made to email someone " )
log . emergency ( " An emergency error occurred, a log destination could be made to text someone " ) Les différentes méthodes définissent le niveau de journal du message. XCGLOGGER imprimera uniquement des messages avec un niveau de journal qui est supérieur ou égal à son paramètre de niveau de journal actuel. Ainsi, un enregistreur avec un niveau de .error ne publiera que des messages de journal avec un niveau de .error ,. .severe ,. .alert ou .emergency
XCGLogger vise à être simple à utiliser et à vous faire fonctionner rapidement avec aussi peu que 2 lignes de code ci-dessus. Mais cela permet un contrôle et une flexibilité beaucoup plus importants.
Un enregistreur peut être configuré pour livrer des messages de journal à une variété de destinations. En utilisant la configuration de base ci-dessus, le journal de bûchera publiera les messages de journal à la console de débogage Xcode standard et éventuellement un fichier si un chemin est fourni. Il est très probable que vous voudrez envoyer des journaux à des endroits plus intéressants, tels que la console du système Apple, une base de données, un serveur tiers ou une autre application telle que NSLogger. Ceci est accompli en ajoutant la destination à l'enregistreur.
Voici un exemple de configuration de l'enregistreur à sortir dans le journal du système Apple ainsi qu'un fichier.
// Create a logger object with no destinations
let log = XCGLogger ( identifier : " advancedLogger " , includeDefaultDestinations : false )
// Create a destination for the system console log (via NSLog)
let systemDestination = AppleSystemLogDestination ( identifier : " advancedLogger.systemDestination " )
// Optionally set some configuration options
systemDestination . outputLevel = . debug
systemDestination . showLogIdentifier = false
systemDestination . showFunctionName = true
systemDestination . showThreadName = true
systemDestination . showLevel = true
systemDestination . showFileName = true
systemDestination . showLineNumber = true
systemDestination . showDate = true
// Add the destination to the logger
log . add ( destination : systemDestination )
// Create a file log destination
let fileDestination = FileDestination ( writeToFile : " /path/to/file " , identifier : " advancedLogger.fileDestination " )
// Optionally set some configuration options
fileDestination . outputLevel = . debug
fileDestination . showLogIdentifier = false
fileDestination . showFunctionName = true
fileDestination . showThreadName = true
fileDestination . showLevel = true
fileDestination . showFileName = true
fileDestination . showLineNumber = true
fileDestination . showDate = true
// Process this destination in the background
fileDestination . logQueue = XCGLogger . logQueue
// Add the destination to the logger
log . add ( destination : fileDestination )
// Add basic app info, version info etc, to the start of the logs
log . logAppDetails ( )Vous pouvez configurer chaque destination de journal avec différentes options en fonction de vos besoins.
Un autre modèle d'utilisation commun est d'avoir plusieurs bûcherons, peut-être un pour les problèmes d'interface utilisateur, un pour le réseautage et un autre pour les problèmes de données.
Chaque destination de journal peut avoir son propre niveau de journal. En tant que commodité, vous pouvez définir le niveau de journal sur l'objet logarithmique lui-même et il passera ce niveau à chaque destination. Définissez ensuite les destinations qui doivent être différentes.
Remarque : Un objet de destination ne peut être ajouté qu'à un objet d'enregistrement, l'ajout à une seconde le supprimera du premier.
Vous pouvez également utiliser une fermeture pour initialiser votre variable globale, afin que toute initialisation soit effectuée en un seul endroit
let log : XCGLogger = {
let log = XCGLogger ( identifier : " advancedLogger " , includeDefaultDestinations : false )
// Customize as needed
return log
} ( ) Remarque : Cela crée l'objet journal paresseusement, ce qui signifie qu'il n'est pas créé tant qu'il n'est pas nécessaire. Cela retarde la sortie initiale des informations d'information de l'application. Pour cette raison, je recommande de forcer l'objet logarithmique à créer au lancement de l'application en ajoutant la ligne let _ = log en haut de votre méthode didFinishLaunching si vous ne connectez pas déjà quelque chose sur le lancement de l'application.
Vous pouvez enregistrer les chaînes:
log . debug ( " Hi there! " )Ou à peu près tout ce que vous voulez:
log . debug ( true )
log . debug ( CGPoint ( x : 1.1 , y : 2.2 ) )
log . debug ( MyEnum . Option )
log . debug ( ( 4 , 2 ) )
log . debug ( [ " Device " : " iPhone " , " Version " : 7 ] ) Nouveau sur xcglogger 4, vous pouvez désormais créer des filtres pour s'appliquer à votre enregistreur (ou à des destinations spécifiques). Créez et configurez vos filtres (exemples ci-dessous), puis ajoutez-les à l'enregistreur ou aux objets de destination en définissant la propriété filters en option sur un tableau contenant les filtres. Les filtres sont appliqués dans l'ordre dans lequel ils existent dans le tableau. Pendant le traitement, chaque filtre est demandé si le message du journal doit être exclu du journal. Si un filtre exclut le message du journal, il est exclu. Les filtres n'ont aucun moyen d'inverser l'exclusion d'un autre filtre.
Si la propriété filters d'une destination est nil , la propriété filters du journal est utilisée à la place. Pour avoir un journal de destination tout, tout en faisant filtrer toutes les autres destinations, ajoutez les filtres à l'objet journal et définissez la propriété filters d'une destination sur un tableau vide [] .
Remarque : Contrairement aux destinations, vous pouvez ajouter le même objet filtrant à plusieurs journalistes et / ou des destinations multiples.
Pour exclure tous les messages de journal d'un fichier spécifique, créez un filtre d'exclusion comme tel:
log . filters = [ FileNameFilter ( excludeFrom : [ " AppDelegate.swift " ] , excludePathWhenMatching : true ) ] excludeFrom: prend un Array<String> ou Set<String> afin que vous puissiez spécifier plusieurs fichiers en même temps.
excludePathWhenMatching: par défaut est true afin que vous puissiez l'omettre à moins que vous ne vouliez également faire correspondre le chemin.
Pour inclure les messages de journal uniquement pour un ensemble spécifique sur les fichiers, créez le filtre à l'aide de l'installateur includeFrom: initialiseur. Il est également possible de simplement basculer la propriété inverse pour retourner le filtre d'exclusion à un filtre d'inclusion.
Afin de filtrer les messages de journal par balise, vous devez bien sûr être en mesure de définir une balise sur les messages de journal. Chaque message de journal peut désormais avoir des données supplémentaires définies par l'utilisateur qui leur sont jointes, à utiliser par des filtres (et / ou des formateurs, etc.). Ceci est géré avec un userInfo: Dictionary<String, Any> objet. La touche de dictionnaire doit être une chaîne dans les noms de noms pour éviter les collisions avec des ajouts futurs. Les clés officielles commenceront par com.cerebralgardens.xcglogger . La touche de balise est accessible par XCGLogger.Constants.userInfoKeyTags . Vous ne voulez certainement pas taper cela, alors n'hésitez pas à créer un raccourci mondial: let tags = XCGLogger.Constants.userInfoKeyTags . Maintenant, vous pouvez facilement marquer vos journaux:
let sensitiveTag = " Sensitive "
log . debug ( " A tagged log message " , userInfo : [ tags : sensitiveTag ] ) La valeur des balises peut être un Array<String> , Set<String> ou simplement une String , selon vos besoins. Ils fonctionneront tous de la même manière lorsqu'ils sont filtrés.
Selon votre flux de travail et votre utilisation, vous créez probablement des méthodes plus rapides pour configurer le dictionnaire userInfo . Voir ci-dessous pour d'autres raccourcis possibles.
Maintenant que vous avez vos journaux tagués, vous pouvez filtrer facilement:
log . filters = [ TagFilter ( excludeFrom : [ sensitiveTag ] ) ] Tout comme le FileNameFilter , vous pouvez utiliser includeFrom: ou basculer inverse pour inclure uniquement des messages de journal qui ont les balises spécifiées.
Le filtrage par développeur est exactement comme le filtrage par balise, uniquement en utilisant la clé userInfo de XCGLogger.Constants.userInfoKeyDevs . En fait, les deux filtres sont des sous-classes de la classe UserInfoFilter que vous pouvez utiliser pour créer des filtres supplémentaires. Voir Extension XCGlogger ci-dessous.
Dans les grands projets avec plusieurs développeurs, vous voudrez probablement commencer à taguer les messages de journal, ainsi que pour indiquer le développeur qui a ajouté le message.
Bien que extrêmement flexible, le dictionnaire userInfo peut être un peu lourd à utiliser. Il existe quelques méthodes possibles que vous pouvez utiliser pour simplement les choses. Je les teste toujours moi-même, donc ils ne font pas encore officiellement partie de la bibliothèque (j'adorerais les commentaires ou d'autres suggestions).
J'ai créé un code expérimental pour aider à créer les dictionnaires UserInfo. (Incluez le sous-espèce UserInfoHelpers en option si vous utilisez des cocoapodes). Vérifiez l'application de démonstration iOS pour le voir en usage.
Il existe deux structures conformes au protocole UserInfoTaggingProtocol . Tag et Dev .
Vous pouvez créer une extension sur chacun d'eux qui convient à votre projet. Par exemple:
extension Tag {
static let sensitive = Tag ( " sensitive " )
static let ui = Tag ( " ui " )
static let data = Tag ( " data " )
}
extension Dev {
static let dave = Dev ( " dave " )
static let sabby = Dev ( " sabby " )
} Avec ces types, il y a un opérateur surchargé | qui peut être utilisé pour les fusionner dans un dictionnaire compatible avec le paramètre UserInfo: les appels de journalisation.
Ensuite, vous pouvez enregistrer des messages comme ceci:
log . debug ( " A tagged log message " , userInfo : Dev . dave | Tag . sensitive ) Il y a quelques problèmes actuels que je vois avec ces UserInfoHelpers , c'est pourquoi je l'ai rendu facultatif / expérimental pour l'instant. J'adorerais entendre des commentaires / suggestions d'amélioration.
| fusionne les dictionnaires tant qu'il n'y a pas Set . Si l'un des dictionnaires contient un Set , il en utilisera l'un, sans les fusionner. Préférant le côté gauche si les deux côtés ont un ensemble pour la même clé.userInfo: a besoin d'un dictionnaire, vous ne pouvez pas passer dans un seul objet Dev ou Tag. Vous devez en utiliser au moins deux avec le | Opérateur pour le convertir automatiquement en un dictionnaire compatible. Si vous ne voulez qu'une seule balise par exemple, vous devez accéder manuellement au paramètre .dictionary : userInfo: Tag("Blah").dictionary . Toutes les méthodes de journal fonctionnent sur les fermetures. En utilisant le même sucre syntaxique que la fonction assert() de SWIFT, cette approche garantit que nous ne gaspillons pas les ressources de construction de messages de journal qui ne seront pas sortis de toute façon, tout en préservant un site d'appel propre.
Par exemple, l'instruction du journal suivant ne gaspillera pas les ressources si le niveau de journal de débogage est supprimé:
log . debug ( " The description of ( thisObject ) is really expensive to create " ) De même, disons que vous devez itérer une boucle afin de faire un calcul avant de journaliser le résultat. Dans Objective-C, vous pouvez mettre ce bloc de code entre #if #endif et empêcher le code d'exécuter. Mais dans Swift, auparavant, vous devrez toujours traiter cette boucle, gaspiller des ressources. Avec XCGLogger c'est aussi simple que:
log . debug {
var total = 0.0
for receipt in receipts {
total += receipt . total
}
return " Total of all receipts: ( total ) "
} Dans les cas où vous souhaitez exécuter sélectivement le code sans générer de ligne de journal, renvoyer nil ou utiliser l'une des méthodes: verboseExec , debugExec , infoExec , warningExec , errorExec et severeExec .
Vous pouvez créer votre propre objet DateFormatter et le affecter à la bûcheron.
let dateFormatter = DateFormatter ( )
dateFormatter . dateFormat = " MM/dd/yyyy hh:mma "
dateFormatter . locale = Locale . current
log . dateFormatter = dateFormatterXCGLogger prend en charge l'ajout de codes de mise en forme à vos messages de journal pour activer la couleur à divers endroits. L'option d'origine était d'utiliser le plug-in xcodecolors. Cependant, Xcode (à partir de la version 8) ne prend plus officiellement en charge les plug-ins. Vous pouvez toujours afficher vos journaux en couleur, mais pas dans Xcode pour le moment. Vous pouvez utiliser la prise en charge des couleurs ANSI pour ajouter de la couleur à vos objets FileDestination et afficher vos journaux via une fenêtre de terminal. Cela vous donne quelques options supplémentaires telles que l'ajout de gras, d'italique ou (s'il vous plaît ne clignotez pas)!
Une fois activé, chaque niveau de journal peut avoir sa propre couleur. Ces couleurs peuvent être personnalisées comme vous le souhaitez. Si vous utilisez plusieurs journalistes, vous pouvez alternativement définir chaque enregistreur sur sa propre couleur.
Un exemple de configuration du formateur ANSI:
if let fileDestination : FileDestination = log . destination ( withIdentifier : XCGLogger . Constants . fileDestinationIdentifier ) as? FileDestination {
let ansiColorLogFormatter : ANSIColorLogFormatter = ANSIColorLogFormatter ( )
ansiColorLogFormatter . colorize ( level : . verbose , with : . colorIndex ( number : 244 ) , options : [ . faint ] )
ansiColorLogFormatter . colorize ( level : . debug , with : . black )
ansiColorLogFormatter . colorize ( level : . info , with : . blue , options : [ . underline ] )
ansiColorLogFormatter . colorize ( level : . notice , with : . green , options : [ . italic ] )
ansiColorLogFormatter . colorize ( level : . warning , with : . red , options : [ . faint ] )
ansiColorLogFormatter . colorize ( level : . error , with : . red , options : [ . bold ] )
ansiColorLogFormatter . colorize ( level : . severe , with : . white , on : . red )
ansiColorLogFormatter . colorize ( level : . alert , with : . white , on : . red , options : [ . bold ] )
ansiColorLogFormatter . colorize ( level : . emergency , with : . white , on : . red , options : [ . bold , . blink ] )
fileDestination . formatters = [ ansiColorLogFormatter ]
} Comme pour les filtres, vous pouvez utiliser les mêmes objets de format pour plusieurs bûcherons et / ou plusieurs destinations. Si la propriété formatters d'une destination est nil , la propriété formatters de Logger sera à la place.
Voir l'extension XCGLogger ci-dessous pour plus d'informations sur la création de vos propres formateurs personnalisés.
En utilisant des drapeaux Swift Build, différents niveaux de journal peuvent être utilisés dans le débogage par rapport à la stadification / production. Accédez à Build Paramètres -> Compiler Swift - Flags personnalisés -> Autres indicateurs Swift et ajoutez -DDEBUG à l'entrée de débogage.
#if DEBUG
log . setup ( level : . debug , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true )
#else
log . setup ( level : . severe , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true )
#endif Vous pouvez définir n'importe quel nombre d'options de la même manière. Voir l'application iOSDemo mise à jour pour un exemple d'utilisation de différentes destinations de journaux en fonction des options, recherchez USE_NSLOG .
Par défaut, les destinations de journaux fournies traiteront les journaux sur le fil sur lequel ils ont appelé. Il s'agit de s'assurer que le message du journal s'affiche immédiatement lors du débogage d'une application. Vous pouvez ajouter un point d'arrêt immédiatement après un appel de journal et voir les résultats lorsque le point d'arrêt frappe.
Cependant, si vous ne déboguez pas activement l'application, le traitement des journaux sur le thread actuel peut introduire un coup de performances. Vous pouvez désormais spécifier un processus de destination ses journaux sur une file d'attente de répartition de votre choix (ou même utiliser une valeur par défaut fournie).
fileDestination . logQueue = XCGLogger . logQueueou même
fileDestination . logQueue = DispatchQueue . global ( qos : . background )Cela fonctionne extrêmement bien lorsqu'il est combiné avec la méthode de configurations alternatives ci-dessus.
#if DEBUG
log . setup ( level : . debug , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true )
#else
log . setup ( level : . severe , showThreadName : true , showLevel : true , showFileNames : true , showLineNumbers : true )
if let consoleLog = log . logDestination ( XCGLogger . Constants . baseConsoleDestinationIdentifier ) as? ConsoleDestination {
consoleLog . logQueue = XCGLogger . logQueue
}
#endifLorsque vous utilisez la configuration avancée de l'enregistreur (voir une utilisation avancée ci-dessus), vous pouvez maintenant spécifier que le journaliste ajoute à un fichier journal existant, au lieu de l'écraser automatiquement.
Ajoutez le paramètre shouldAppend: OPTIONNELLE lors de l'initialisation de l'objet FileDestination . Vous pouvez également ajouter le paramètre appendMarker: pour ajouter un marqueur au fichier journal indiquant où une nouvelle instance de votre application a commencé à ajouter. Par défaut, nous ajouterons -- ** ** ** -- si le paramètre est omis. Réglez-le sur nil pour sauter le marqueur.
let fileDestination = FileDestination(writeToFile: "/path/to/file", identifier: "advancedLogger.fileDestination", shouldAppend: true, appendMarker: "-- Relauched App --")
Lors de la connexion dans un fichier, vous avez la possibilité de faire pivoter automatiquement le fichier journal vers une destination archivée et de créer automatiquement un nouveau fichier journal à la place de l'ancien.
Créez une destination à l'aide de la classe AutoRotatingFileDestination et définissez les propriétés suivantes:
targetMaxFileSize : Auto tourne une fois le fichier plus grand que celui-ci
targetMaxTimeInterval : Auto tourne après cette plusieurs secondes
targetMaxLogFiles : nombre de fichiers journaux archivés à conserver, les plus anciens sont automatiquement supprimés
Ce sont toutes des directives pour l'enregistreur, pas des limites difficiles.
Vous pouvez créer des destinations de journaux alternatives (en plus de celles intégrées). Votre destination de journal personnalisée doit implémenter le protocole DestinationProtocol . Instanciez votre objet, configurez-le, puis ajoutez-le à l'objet XCGLogger avec add(destination:) . Il existe deux classes de destination de base ( BaseDestination et BaseQueuedDestination ) dont vous pouvez hériter pour gérer la majeure partie du processus pour vous, vous obligeant à implémenter une seule méthode supplémentaire dans votre classe personnalisée. Jetez un coup d'œil à ConsoleDestination et FileDestination pour des exemples.
Vous pouvez également créer des filtres ou des formateurs personnalisés. Jetez un œil aux versions fournies comme point de départ. Notez que les filtres et les formateurs ont la possibilité de modifier les messages de journal lorsqu'ils sont traités. Cela signifie que vous pouvez créer un filtre qui dépouille les mots de passe, met en évidence des mots spécifiques, chiffrer les messages, etc.
XCGLogger est le meilleur enregistreur disponible pour Swift en raison des contributions de la communauté comme vous. Il existe de nombreuses façons de continuer à le rendre super.
Remarque : Lors de la soumission d'une demande de traction, veuillez utiliser de nombreux versets de petits commits, un énorme engagement. Il est beaucoup plus facile de fusionner lorsqu'il existe plusieurs demandes de traction qui doivent être combinées pour une nouvelle version.
Si vous trouvez cette bibliothèque utile, vous trouverez certainement cet autre outil utile:
Watchdog: https://watchdogforxcode.com/
Veuillez également consulter certains de mes autres projets:
Le journal de modification est maintenant dans son propre fichier: changelog.md
