Motivation

I just want to pass dependencies to Output class which inherits BufferedOutput. The interface of initializer can't be changed because it's required by Output protocol. But the initializer is used only in OutputSetting and no need to instantiate from common initializer instead of closure.

What changed

I changed to use closure to instantiate OutputSetting and remove OutputOptions because no need to use common interface of initializer. And I added InstantiatableOutput for backward compatibility. If you used OutputSetting.init(O.Type,tagPattern: TagPattern), need to conform InstantiatableOutput

As of #16, the Logger starts all outputs on a background queue. As a result of this, the BufferedOutput.setUpTimer() function is now being executed on the background queue set by the logger and not the main queue as it was in 3.3.0.

This PR currently introduces a unit test that replicates the issue.

It appears that this can be simply fixed by scheduling the timer on RunLoop.main instead of RunLoop.current however I'm not familiar with Puree enough to know if this change will be safe or not so I have the following questions:

1. Is there a better way to write this unit test? I worry that it might be unreliable.
2. Does scheduling the Timer to run on RunLoop.main defeat the object of #16? I think that it is ok to do this but just want to be sure that the results (BufferedOutput.tick(_:) will run on the main thread) are acceptable.

I can commit a fix once it's been decided how we should proceed

Hi✋ This is tiny proposal. I think that tag pattern shouldn't allow empty, space or newline only string.

In validation, returns false asap if found string that empty, space or newline only in the tag pattern.

Motivation

I wanted to specify a custom configuration forBufferdOutput, but when I initialize the configuration, I got the following error. initializer is inaccessible due to 'internal' protection level.

What changed

• I've added a public memberwise initializer according to the following document. 7ab39af

https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html

As with the default initializer above, if you want a public structure type to be initializable with a memberwise initializer when used in another module, You must provide a public memberwise initializer yourself as part of the type's definition.

• Changed to use the sizeLimit private property like any other properties. ae8aa95

• add chunkDataSizeLimit to BufferedOutput.Configuration
• send logs before total data size in buffer reached its size limit even if buffered log count is less than count limit
• add a test case

Apparently (after Googling), Swift classes are deallocated from the thread that they were last retained on meaning that you cannot guarantee the thread that deinit is executed from.

In the case of Logger, if you last called a function where self was captured internally in it's internal dispatch queue (i.e Logger.resume()) then the deinit function is executed from the internal dispatch queue.

In the current implementation, deinit calls Logger.shutdown() that then attempts to execute dispatchQueue.sync { ... } while already on the internal dispatch queue resulting in the framework crashing with EXC_BAD_INSTRUCTION

You can reproduce the scenario with the following test case:

func testLoggerDeallocation() {

    let configuration = Logger.Configuration(logStore: logStore,
                                             dateProvider: DefaultDateProvider(),
                                             filterSettings: [FilterSetting(PVLogFilter.self, tagPattern: TagPattern(string: "pv")!)],
                                             outputSettings: [OutputSetting(PVLogOutput.self, tagPattern: TagPattern(string: "pv")!)])
    var logger: Logger? = try? Logger(configuration: configuration)
    XCTAssertNotNil(logger)

    logger?.postLog(["foo":"bar"], tag: "pv")
    logger?.suspend()

    weak var weakLogger: Logger? = logger
    logger?.resume()
    logger = nil

    let exp = expectation(description: #function)
    DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
        XCTAssertNil(weakLogger)
        exp.fulfill()
    }
    waitForExpectations(timeout: 10.0, handler: nil)
}

This change removes the deinit implementation as it seems unnecessary although I'm not sure if we actually need to be able to suspend the outputs or not still?

If we still need to suspend the outputs then maybe I should add it back but call dispatchQueue.async instead of .sync?

Thank you for awesome library.

Motivation and Context

We are want to use an AppExtension project. (ex: Share Extension, Today Extension)

Description

If this option set to YES. Puree-Swift can't use NS_EXTENSION_UNAVAILABLE apis.

• UIApplication.shared

Minor Enhancement

• Was going through your repo, saw a small enhancement, which I guess , it's quiet important too, so I made the changes.

Changes

• Added the License section in Readme.md just to enhance the feel of readme.

Future Updates

• Right now going through your repo, trying my best to add a feature, soon I will push a PR :).

Happy Coding!

Motivation and Context

Currently, FileLogStore has an IUO property. In the real world apps, it sometimes causes crashes.

So I modified the initialization interface of LogStore to avoid IUO properties.

Description

I use a throwable initializer instead of prepare method.

Compatibility

This PR doesn't impact users who uses default LogStores. Most users may use default LogStore. Users who own their custom LogStores have to change their implements to adapt to the new interface.

Be explicit about retry strategy when a write returns.

An use case would be when the network becomes unavailable. We should suspend retries and the output until the next time we resume the output (when the network resumes)

Intended behavior and usage:

When a chunk write fails due to unavailable internet connection, we will stop retrying. We will also drop the failed chunk from currentWritingChunks, allowing it to be re-flushed after we resume the output. We will make the following changes in the calling app:

1. Suspend the output on app backgrounding: there is no need to continue the flush timer.
2. Resume the output after network becomes available, AND after app foregrounding. The reason it needs to be an AND here is that if the network becomes available when the app is backgrounded, we’re not sure we’ll receive the notification. However, it’s okay to resume multiple times because currentWritingChunks are not re-added to the buffer to be flushed.
3. Set retry count and intervals configurations to be shorter than they are now. Due to the changed mentioned, we reduce some unnecessary consumption of a chunk's retry limit. However, we cannot make these settings too low, because the connection could simply be bad for a long time without the phone being in airplane mode.

Effects:

• We will not attempt to retry a chunk when the phone is in airplane mode or explicitly disconnected from the carrier.
• If a disconnection is not detected, queued retries will be unaffected after app backgrounding (but will not execute while in background)
• The downside is that, once the app returns to the foreground, the dropped chunks will immediately be re-created and retried, whereas previously they would wait until their next retry interval. If this causes a network crowding issue, we can explore staggering the requests.

App restart:

• Previously, chunks that exceeded their retry count will be attempted again after app restart (force quit). This will continue to be the case, with the addition that dropped chunks will also be retried.
• Either way, this is dangerous because invalid entries will never clear out of the system if there is a programmer error. We should add a lifetime limit for each log entry, either by timestamp or by load count.

This PR merges 4.0.0-beta branch into master.

I added this commit to bump up version. https://github.com/cookpad/Puree-Swift/commit/4e0a20b53aed74cb7dc0be04ec4774d36d8be5c5