Issue Link :link:

This fixes #43 where building with Carthage on Xcode 10.2 was failing due to Swift 3 being deprecated.

Goals :soccer:

• Allow using AlamofireNetworkActivityIndicator with Xcode 10.2.

Implementation Details :construction:

• All targets had their Swift version updated from 3.0 to 4.0.
• Updated README.md for bumped requirements.

Testing Details :mag:

No changes made to testing due to Travis not having an xcode10.2 official release image available yet. Would be good to add an iOS 12.2 simulator to tests and build against Xcode 10.2 in the future once the image is available.

Hi there! We were able to use AlamofireNetworkActivityIndicator without Alamofire by just removing the notification registration methods. I'd love to figure out a way to expose this class as its own framework in such a way that Alamofire users could still use this seamlessly as they do today, but folks like us could install a subspec that didn't require Alamofire. I'd be open to doing the work here too. Thanks!

This PR adds the NetworkActivityIndicatorManager class and all the tests to verify behavior. Code coverage is currently at 98% and looking good.

The general approach is fairly similar to AFN with a simplification of not having to swizzle the NSURLSessionTask.State changes since we can rely on the Request methods directly. While this approach does not work if the user uses the task property directly to resume or suspend the task, this should be able to be resolved with documentation. This is certainly a better tradeoff than swizzling the task state. AFN couldn't use this approach b/c there is no concept of a Request.

@jshier and I have a huge conversation on the design choices of using NSNotification instead of closures on the Manager or Request classes. We decided that it is best in this case to use notifications since it is a broadcast that could have multiple observers.

• [X] I've read, understood, and done my best to follow the *CONTRIBUTING guidelines.

What did you do?

Xcode 10.2

carthage bootstrap --platform iOS

What did you expect to happen?

Install AlamofireNetworkActivityIndicator from Carthage package manager

What happened instead?

Build Failed
Task failed with exit code 65:

Build system information
error: SWIFT_VERSION '3.0' is unsupported, supported versions are: 4.0, 4.2, 5.0. (in target 'AlamofireNetworkActivityIndicator')

** ARCHIVE FAILED **

Alamofire Environment

Alamofire version: 4.8.1 AlamofireNetworkActivityIndicator: 2.3.0 Xcode version: 10.2 (10E125) Swift version: Swift 4.0 4.2 5.0 macOS version running Xcode: 10.14.3

Issue Link :link:

This fixes #32, making Alamofire optional.

Goals :soccer:

• Allow using AlamofireNetworkActivityIndicator without Alamofire

Implementation Details :construction:

• This uses the new (in Swift 4.1) #if canImport to conditionally import Alamofire and setup the default notification listening behavior that is currently used by Alamofire users.
• If Alamofire cannot be imported, no notification listening is setup by default, and clients of this library can now register notifications used by other libraries for this library to listen to.

Testing Details :mag:

• [x] Add tests for the public notification method
• [x] Setup travis to test with and without Alamofire

The indicator works great. However there's a threading issue in decrementActivityCount().

This has a line:

guard activityCount > 0 else { return }

To prevent the activityCount going negative. (I'm curious why this line was introduced.) I have a situation where the activityCount would go negative. The debugger hits the else part of the guard. I believe the timing hole is around AlamoFire's resume() method.

AlamoFire's Request.resume() method (I added the comments):

public func resume() {
    if startTime == nil { startTime = CFAbsoluteTimeGetCurrent() }

    task.resume()

    // TIMING HOLE HERE. 
    // The task comes back fast (e.g. from cache) before we call postNotificationName. 
    // The decrement is called in the result callback, and activityCount should go to -1. (But doesn't due to the guard > 0)
    // Then this thread resumes and posts its notification about the task starting.
    // Now the activity indicator's count is 1... forever above zero, so the indicator stays on.
    NSNotificationCenter.defaultCenter().postNotificationName(Notifications.Task.DidResume, object: task)
}

I see no reason for the guard activityCount > 0 line. Removing it would fix this hole.

What did you do?

I tried to install from SPM with and without Alamofire 5.0.2 installed

What did you expect to happen?

The package installed

What happened instead?

Xcode shows me this error:

Showing All Messages : terminated(128): /Applications/Xcode.app/Contents/Developer/usr/bin/git -C /Users/diego/Library/Developer/Xcode/DerivedData/TestAlamofire-gvqycjnmlwcnmvfowrhyoettyohc/SourcePackages/checkouts/AlamofireNetworkActivityIndicator submodule update --init --recursive output: fatal: No url found for submodule path 'Carthage/Checkouts/Alamofire' in .gitmodules

Alamofire Environment

**Alamofire version: 5.0.2 **AlamofireNetworkActivityIndicator: 3.0.0 **Xcode version: 11.3.1 (11C504) **Swift version: 5.1 **macOS version running Xcode: 10.15.3 (19D76)

Demo Project

Create a new empty project and try to install AlamofireNetworkActivityIndicator from SPM with or without Alamofire installed will show this error:

I cannot build it with Carthage because Xcode 10.2 doesn't support Swift 3.X. Could you upgrade it to minimum Swift 4.0 at least.

SWIFT_VERSION = 3.0;

Issue Link :link:

Apple renamed RunLoop.Mode in Swift 4.2, which broke compilation. Xcode 10 and Swift 4.2 are out now, so I thought I'd open a PR.

Goals :soccer:

Swift 4.2 support.

Implementation Details :construction:

Added a simple #if swift(>=4.2) block around the relevant code. Also incremented the podspec version.

Testing Details :mag:

@jshier I noticed you had your own branch where you were also tweaking some tests and playing around with the Alamofire version - wasn't sure about that but figured I should leave that out...?

What did you do?

I was using the AlamofireImage swift library to download image thumbnails for a table view. I was also using this library to show the user network usage during the thumbnail downloading process.

What did you expect to happen?

Whenever a image thumbnail was being downloaded the network activity indicator would show up.

What happened instead?

Normally the activity indicator does show up, however when I scroll down the table view quickly, the activity indicator will no longer show up.

Further debugging I found that the activityCount in the NetworkActivityIndicatorManager would actually go in the negatives.

I found that there were more notifications calls Notification.Name.Task.DidComplete than the corresponding Notification.Name.Task.DidResume.

My suspicions are that when scrolling quickly through the list, the AlamofireImage library will eventually queue up the network requests as the maximumActiveDownloads limit has been reached. And because the cell which has an image that has been queued may not even start the download network request before it gets cancelled, as the cell is being recycled, the Notification.Name.Task.DidComplete gets called for the request, but it never did send the Notification.Name.Task.DidResume as it never got started.

The issue may in fact lie in the AlamofireImage library but wanted to bring it up here as the issue is noticeable with this library.

Example log

...
networkRequestDidStart = -9
networkRequestDidComplete = -10
networkRequestDidComplete = -11
networkRequestDidComplete = -12
networkRequestDidComplete = -13
networkRequestDidStart = -12
networkRequestDidStart = -11
networkRequestDidComplete = -12
networkRequestDidComplete = -13
networkRequestDidStart = -12
networkRequestDidComplete = -13
networkRequestDidStart = -12
networkRequestDidComplete = -13
...

Alamofire Environment

• Xcode (9.4.1)
• Mac OSX (10.13.5)
• Swift 4.1
• Devices running iOS 11+
• Alamofire (4.7.2)
• AlamofireImage (3.3.1)
• AlamofireNetworkActivityIndicator (2.2.1)

Demo Project

Here's a link to a very basic project that should highlight the problem. I found the negative activityCount by adding print statements around the lines in the NetworkActivityIndicatorManager:

@objc private func networkRequestDidStart() {
        incrementActivityCount()
        print("networkRequestDidStart = \(activityCount)")
    }

    @objc private func networkRequestDidComplete() {
        decrementActivityCount()
        print("networkRequestDidComplete = \(activityCount)")
    }

GitHub Project

Goals :soccer:

Remove BITCODE_GENERATION_MODE settings which leads to make binary always bitcode even target to device.

Implementation Details :construction:

If this project is added as subproject to other project, this project generate bitcode ALWAYS which should not be happened when build target to device directly. (for running on it)

And more that, Alamofire project build correctly as is, so these error occurs while linking AlamofireNetworkActivityIndicator:

ld: bitcode bundle could not be generated because '<Alamofire Framework Binary Path>' was built without full bitcode. All frameworks and dylibs for bitcode must be generated from Xcode Archive or Install build file '<Alamofire Framework Binary Path>' for architecture armv7

Testing Details :mag:

I tested it through embed as subproject, and carthage build.

Bumps tzinfo from 1.2.7 to 1.2.10.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps cocoapods-downloader from 1.3.0 to 1.6.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps redcarpet from 3.5.0 to 3.5.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.