You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Documentation/Logger.md
+30-30Lines changed: 30 additions & 30 deletions
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@
13
13
## The Logger
14
14
15
15
Logging is done via a `Log` instance.
16
-
Depending the architecture/complexity of your applicationyou may have a single or multiple logger instances, each one with their own settings.
16
+
Depending on your application's architecture/complexity, you may have single or multiple logger instances, each with its settings.
17
17
18
18
The best way to create a log instance is to use the initialization via configuration callback:
19
19
@@ -29,42 +29,42 @@ let logger = Log {
29
29
}
30
30
```
31
31
32
-
`Configuration` object, passed inside the callback param, allows you to configure different aspect of the logger's behaviour. For example:
32
+
`Configuration` object, passed inside the callback param, allows you to configure different aspects of the logger's behavior. For example:
33
33
34
-
-`subsystem` and `category`: used to identify a logger specifing the main package and
35
-
-`level`set the minimum severity level accepted by the log (any message with a lower severity received by the logger is automatically discarded).
36
-
-`transports` defines one or more destinations for received messages. A transport can save your messages in a local file, a database or send it remotely to a web-service like the ELK stacks or Sentry.io.
37
-
-`isEnabled`: when `false` any message received by the log is ignored. It's useful to temporary disable reception of data.
38
-
-`isSynchronous`: Identify how the messages must be handled when sent to the logger instance. Typically you want to set if to `false` in production and `true` in development.
34
+
-`subsystem` and `category`: used to identify a logger specifying the main package and
35
+
-`level`sets the minimum severity level accepted by the log (any message with a lower severity received by the logger is automatically discarded).
36
+
-`transports` defines one or more destinations for received messages. A transport can save your messages in a local file or a database or send them remotely to a webservice like the ELK stacks or Sentry.io.
37
+
-`isEnabled`: when `false`, any message received by the log is ignored. Especially useful to temporarily disable all the functionalities.
38
+
-`isSynchronous`: Identify how the messages must be handled when sent to the logger instance. Typically you want to set it to `false` in production and `true` in development.
39
39
40
40
## Writing messages
41
41
42
-
Sending a message to a logger is pretty simple; simply append the severity level channel to your logger instance and call `write()` function:
42
+
Sending a message to a logger is pretty simple; append the severity level channel to your logger instance and call `write()` function:
43
43
44
44
```swift
45
45
logger.error?.write(msg: "Something bad has occurred")
46
46
logger.trace?.write(msg: "User tapped buy button for item \(item.id)")
47
47
```
48
48
49
49
> **Warning**
50
-
> The first message is accepted by the logger, but the second one is ignored because message's severity level is below the log's set level.
50
+
> The first message is accepted by the logger, but the second one is ignored because the message's severity level is below the log's set level.
51
51
52
52
Each event includes `message` but also several other properties used to enrich the context of the message (we'll take a look at `Scope` later below).
53
-
When you write a new message you can also customize the following fields.
53
+
When you write a new message, you can also customize the following fields.
54
54
55
55
-`message`: the message of the event (it can be a literal or interpolated message. Take a look here for more info).
56
-
-`object`: you can attach an object to the event (it must be conform to the `SerializableObject` protocol; all simple data types and `Codable` conform object are automatically supported).
57
-
-`extra`: you can attach a dictionary of key,value objects to give more context to an event.
58
-
-`tags`: tags is another dictionary but some transport may index these values for search (for example `SentryTransport` makes these value searchable inside its dashboard).
56
+
-`object`: you can attach an object to the event (it must conform to the `SerializableObject` protocol; all simple data types and `Codable` conform objects are automatically supported).
57
+
-`extra`: you can attach a dictionary of key-value objects to give more context to an event.
58
+
-`tags`: tags is another dictionary, but some transport may index these values for search. `SentryTransport`, for example, makes tags indexed.
59
59
60
60
Glider's offer different `write()` functions.
61
61
62
62
### Writing simple messages
63
63
64
-
For simple messages you can use the `write(msg:object:extra:tags:)` where the only required parameter is the message of the event.
64
+
For simple messages, you can use the `write(msg:object:extra:tags:)` where the only required parameter is the event's message.
65
65
66
66
> **Note**
67
-
> You should use this method when the creation of the text message is silly and fast. If your message is complex and you think it could takes some CPU effort consider using the `write()` function via closure.
67
+
> You should use this method when the creation of the text message is silly and fast. If your message is complex and you think it could take some CPU effort, consider using the `write()` function via closure.
68
68
69
69
```swift
70
70
// It generates an info message which includes the details of the operation.
Logging a message is easy, but knowing when to add the logic necessary to build a log message and tune it for performance can be a bit tricky. We want to make sure logic is encapsulated and very performant. Glider log level closures allow you to cleanly wrap all the logic to build up the message.
80
80
81
81
> **Note**
82
-
> Glider works exclusively with logging closures to ensure the maximum performance in all situations. Closures defer the execution of all the logic inside the closure until absolutely necessary, including the string evaluation itself.
82
+
> Glider works exclusively with logging closures to ensure maximum performance in all situations. Closures defer the execution of all the logic inside the closure until absolutely necessary, including the string evaluation itself.
83
83
84
-
In cases where the `Log` instance is disabled or channel is `nil` (severity of message is below `Log` severity), log execution time was reduced by 97% over the traditional log message methods taking a `String` parameter.
84
+
In cases where the `Log` instance is disabled, or channel is `nil` (severity of message is below `Log` severity), log execution time was reduced by 97% over the traditional log message methods taking a `String` parameter.
85
85
Additionally, the overhead for creating a closure was measured at 1% over the traditional method making it negligible.
86
86
87
87
In summary, closures allow Glider to be extremely performant in all situations.
@@ -94,11 +94,11 @@ logger.info?.write {
94
94
}
95
95
```
96
96
97
-
This is the best way to write an event and we suggest using it everytime.
97
+
This is the best way to write an event, and we suggest using it every time.
98
98
99
99
### Writing message by passing `Event`
100
100
101
-
Finally there are some situation where you need to create an event in a moment and send it later:
101
+
Finally there are some situations where you need to create an event in a moment and send it later:
102
102
103
103
```swift
104
104
let event =Event(message: "Message #\($0)", extra: ["idx":$0])
Messages can be simple literals string or may include data coming from variables read at runtime.
112
-
Glider supports privacy and formatting options allow to manage the visibility of values in log messages and how data is presented, as like the Apple's OSLog.
112
+
Glider supports privacy and formatting options, allowing to manage of the visibility of values in log messages and how data is presented, like Apple's OSLog.
113
113
114
-
When you create set a `message` for an event you can specify several attributes for each interpolated value:
114
+
When you create set a `message` for an event, you can specify several attributes for each interpolated value:
115
115
116
-
-`privacy`: Because users can have access to log messages that your app generates, use the `.private` or `.partialHide` privacy options to hide potentially sensitive information. For example, you might use it to hide or mask an account information or personal data. By default all data is visible in debug, while in production every variable - when not specified - is `private`.
116
+
-`privacy`: Because users can have access to log messages that your app generates, use the `.private` or `.partialHide` privacy options to hide potentially sensitive information. For example, you might use it to hide or mask account information or personal data. By default, all data is visible in debugging, while in production, every variable - when not specified - is `private`.
117
117
-`pad`: value printed consists of an original value that is padded with leading, middle or trailing characters to a specified total length. The padding character can be a space or a specified character. The resulting string appears to be either right-aligned or left-aligned.
118
118
-`trunc`: value is truncated to a max length (lead/trail/middle).
119
119
120
-
Moreover common data types also support formatting styles.
121
-
For example you can decide how to print `Bool` values (`true/false`, `1/0`, `yes/no`), `Double`, `Int`, `Date` (ISO8601 or custom format) and so on.
120
+
Moreover, common data types also support formatting styles.
121
+
For example, you can decide how to print `Bool` values (`true/false`, `1/0`, `yes/no`), `Double`, `Int`, `Date` (ISO8601 or custom format) and so on.
The `Log` class has an `isEnabled` property to allow you to completely disable logging. This can be helpful for turning off specific logger objects at the app level, or more commonly to disable logging in a third-party library.
147
+
The `Log` class has an `isEnabled` property to allow you to completely disable logging. This can be helpful for turning off specific logger objects at the app level or, more commonly, disabling logging in a third-party library.
148
148
149
149
```swift
150
150
let logger =Log { ... }
@@ -157,22 +157,22 @@ logger.isEnabled = true
157
157
158
158
## Severity Levels
159
159
160
-
Any new message received by a logger is encapsulated in a payload called `Event`; each event has its own severity which allows to identify what kind of data is received (is the event an error? or just a notice?).
160
+
Any new message received by a logger is encapsulated in a payload called `Event`; each event has its own severity, which allows identifying what kind of data is received (is the event an error? or just a notice?).
161
161
162
-
Severity of all levels is assumed to be numerically ascending from most important (`emergency`) to least important (`trace`).
162
+
The severity of all levels is assumed to be numerically ascending from most important (`emergency`) to least important (`trace`).
163
163
164
164
Glider uses the [RFC-5424](https://tools.ietf.org/html/rfc5424) standard with 9 different levels for your message (see [this discussion](https://forums.swift.org/t/logging-levels-for-swifts-server-side-logging-apis-and-new-os-log-apis/20365) on Swift Forum).
|`critical`| Logging at this level or higher could have a significant performance cost. The logging system may collect and store enough information such as stack shot etc. that may help in debugging these critical errors. |
170
+
|`critical`| Logging at this level or higher could have a significant performance cost. The logging system may collect and store enough information such as stack shot etc., that may help in debugging these critical errors. |
171
171
|`error`| Error conditions. |
172
172
|`warning`| Abnormal conditions that do not prevent the program from completing a specific task. These are meant to be persisted (unless the system runs out of storage quota). |
173
-
|`notice`| Conditions that are not error conditions, but that may require special handling or that are likely to lead to an error. These messages will be stored by the logging system unless it runs out of the storage quota. |
173
+
|`notice`| Conditions that are not error conditions but that may require special handling or that are likely to lead to an error. These messages will be stored by the logging system unless it runs out of the storage quota. |
174
174
|`info`| Informational messages that are not essential for troubleshooting errors. These can be discarded by the logging system, especially if there are resource constraints. |
175
-
|`debug`| Messages meant to be useful only during development. This is meant to be disabled in shipping code. |
175
+
|`debug`| Messages are meant to be useful only during development. This is meant to be disabled in the shipping code. |
Copy file name to clipboardExpand all lines: Documentation/NetWatcher.md
+9-9Lines changed: 9 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -16,19 +16,19 @@ It also works with Alamofire and RealHTTP, if that's your thing.
16
16
17
17
- No code to write and no imports.
18
18
- Record all app traffic that uses NSURLSession.
19
-
- Log the content of all requests, responses, and header with no hassles with SSL/HTTPS
19
+
- Log the content of all requests, responses, and headers with no hassles with SSL/HTTPS
20
20
- Find, isolate and fix bugs quickly.
21
21
- Also works with external libraries like Alamofire & RealHTTP.
22
22
- Ability to blacklist hosts from being recorded using the array ignoredHosts.
23
-
- Ability to share cURL rappresentation of API requests
23
+
- Ability to share cURL representation of API requests
24
24
25
25
## Installation
26
26
27
-
`NetWatcher` is not part of the Glider Core; you can install it by selecting the `GliderNetWatcher` package when installing main Glider dependency, or by using the `GliderNetWatcher.podspec` if you are using CocoaPods
27
+
`NetWatcher` is not part of the Glider Core; you can install it by selecting the `GliderNetWatcher` package when installing the main Glider dependency or by using the `GliderNetWatcher.podspec` if you are using CocoaPods
28
28
29
29
## Capture Taffic
30
30
31
-
If you want to capture all the network traffic inside the app just call `captureGlobally()` method:
31
+
If you want to capture all the network traffic inside the app, just call `captureGlobally()` method:
Most of the time you may want to capture sniffed traffics to send it to a Glider Transport service.
52
52
`NetWatcher` is perfectly integrated: just set your custom configuration before activating the sniffer:
53
53
54
-
The following example uses the `NetArchiveTransport` transport, a transport made to store network requests/responses directly in a compact, readable SQLite3 local database (it's like `SQLiteTransport`).
54
+
The following example uses the `NetArchiveTransport` transport; a transport made to store network requests/responses directly in a compact, readable SQLite3 local database (it's like `SQLiteTransport`).
55
55
56
56
```swift
57
57
// Setup the configuration
@@ -91,20 +91,20 @@ class UIApplication: UIApplicationDelegate, NetWatcherDelegate {
91
91
92
92
## Transports
93
93
94
-
`NetWatcher` has 2 transport specifically made to store network events.
95
-
You can, however, create your own implementation to suite your need.
94
+
`NetWatcher` has two transport specifically made to store network events.
95
+
You can, however, create your own implementation to suit your need.
96
96
97
97
### NetSparseFilesTransport
98
98
99
99
The `NetSparseFilesTransport` class is used to store network activity inside a root folder.
100
100
101
-
Each call is stored with a single textual file with the id of the network call and its creation date set to the origin call date.
101
+
Each call is stored with a single textual file with the id of the network call and its creation date set to the original call date.
102
102
Inside each file you can found `<cURL command for request>\n\n<raw response data>`.
103
103
104
104
```swift
105
105
let sparseArchive = NetSparseFilesTransport.Config {
106
106
$0.directoryURL= localFolderURL // location of the directory (will be created if not exists)
107
-
$0.resetAtStartup=false// do not remove previouslystored data at launch
107
+
$0.resetAtStartup=false// do not remove previously-stored data at launch
0 commit comments