SwiftyBeaver logging in dynamic frameworks

In this lesson

In this lesson, I will show you how easy it is to use SwiftyBeaver in both your applications and your dynamic frameworks.

Transcript

Tap on time to skip ahead

00:11

Hello everyone! In this lesson, I want to talk about supporting/using SwiftyBeaver in your dynamic frameworks. So it’s very similar to supporting or using SwiftyBeaver in your applications. But there’s one difference.

00:32

I’m here in one of my own dynamic frameworks called the LoLDataDragonContentProvider. Like in the AppDelegate, I’m importing SwiftyBeaver and I’m also declaring a logger alias to the SwiftyBeaver.self class. Down here, I’m logging at the .Debug level, something that happens in my dynamic framework. And here I am in another dynamic framework called the SwiftProtocolsSQLite framework. I look down here at some of my own code, I’ve done the same thing… import SwiftyBeaver, initialize a logger and add log statements in my code. The difference is, in the dynamic frameworks, you will not configure SwiftyBeaver anywhere. So no matter where you look throughout the code, there’s no addDestination(). You don’t do that in your dynamic frameworks. All you do is import SwiftyBeaver. It’s a dependency of your framework. So it will be able to compile properly. Whether or not your statements are actually logged anywhere is under the control of the application that uses it. If you want to see your own output in your tests, like here, you can certainly addDestination() in your tests. But when configuring SwiftyBeaver to be used in dynamic frameworks, simply import it, log your statements, but don’t add any destinations.

02:24

I’m back in my application and you’ll notice that this application depends upon the LolDataDragonContentProvider framework and the SwiftProtocolsSQLite framework, among many others. And it’s this application that is controlling where the destinations are for the log statements. So I have my own log statements within the AppDelegate and other classes within the app. But frameworks have their own logging using SwiftyBeaver. And the configuration that the application makes against SwiftyBeaver controls whether or not the statements logged from the dynamic frameworks actually will get logged in the application.

03:14

Let me summarize what I said just to make sure it’s clear. I’m back in the application, I ran the app. I have log statements in my own AppDelegate, but I’m also using dynamic frameworks, conceivably written by somebody else that supports SwiftyBeaver logging without adding destinations. If we look at the log, you can see here, this statement was generated by my own AppDelegate, as was this. But these other statements like here, were not, or here. These were generated by other dynamic frameworks and the only reason they’re appearing is because the application itself imports SwiftyBeaver and adds destinations. So I encourage you, as a developer of dynamic frameworks, to support logging with SwiftyBeaver and let those applications that use your frameworks choose to use SwiftyBeaver to output the statements that you log in your own dynamic frameworks.