fabriziobrancati / queuer Goto Github PK

Installed with CococaPods and running Xcode 8.3 / Swift 3.1.

Subclassing ConcurrentOperation in my own project with import Queuer as per the README.

On compile, getting the error:

Cannot inherit from non-open class ConcurrentOperation outside of its defining module.

and

Overriding non-open instance method outside of its defining module.

First error fixed by changing ConcurrentOperation from public to open. Must also change the overrides in the class to open to match Access Controls of Operation.

Second error fixed by making -ConcurrentOperation.execute() open as well.

Hi Fabrizio,

I've imported your Queuer framework by CocoaPod (pod Queuer) in my own Framework that it's used in my app. When I try to do the Archive Xcode shows me this error:
bitcode bundle could not be generated because '/MyFramework../Build/Products/Release-iphoneos/Queuer/Queuer.framework/Queuer' was built without full bitcode. All frameworks and dylibs for bitcode must be generated from Xcode Archive or Install build file '/MyFramework.../Build/Products/Release-iphoneos/Queuer/Queuer.framework/Queuer' for architecture armv7.

I've tried several options searched by google but all have failed. I've downloaded the Queuer framework project and I've added to my framework and it works (without changing any parameters).

Am I doing something wrong?
It's a shame I can't use it with CocoaPods.

Regards,

I have scenario where i need to resume or retry certain operation after killing and reopening app.

Ultimately how to bring persistence with (SQLite, Realm or UserDefaults) in this.

Hi @FabrizioBrancati , very a good job !! but examples would be appreciated for the Asynchronous Operation

Cheers
m.

Just wondered if it was possible to use this Queuer to push all alamofire requests into it with different priority scales? I think i read somewhere in an issue it wasn't possible with Alamofire or something along those lines but saw a new version was brought out.

Finishing a ConcurrentOperation with operation.finish(success: false) does nothing to its success property. I would expect success to be false if I finish the operation that way 🤔

For the following code, is the output after that the expected result, please?

class ViewController: UIViewController {
	var i:Int = 0
	override func viewDidLoad () {
		super.viewDidLoad()
		let queue = Queuer( name: "mike" )
		print( "a \(i)" )
		queue.addChainedOperations( [
			ConcurrentOperation{ self.i = 7 },
			ConcurrentOperation{ self.i = 5 },
			ConcurrentOperation{ self.i = 3 } ]
		) { print( "complete" ) }
		print( "b \(i)" )
		print( "hey 1" )
		print( "hey 2" )
		print( "hey 3" )
	}
}

a 0
b 3
complete
hey 1
hey 2
hey 3

https://github.fabriziobrancati.com/documentation/Queuer/

Can Queuer handle failed task executes and retry accordingly ? Say the task failed due to no network and can retry when network is up.

$ cat /etc/lsb-release 
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"

$ swift --version
Swift version 4.0 (swift-4.0-RELEASE)
Target: x86_64-unknown-linux-gnu

$ cat Package.swift 
import PackageDescription

let package = Package(
    name: "testSwift",
    products: [
        .executable(name: "testSwift", targets: ["testSwift"])
    ],
    dependencies: [
	.package(url: "https://github.com/FabrizioBrancati/Queuer.git", .upToNextMajor(from: "1.0.0"))
    ],
    targets: [
        .target(
            name: "testSwift", dependencies: ["BFKit"]),
    ]
)

$ swift build
error: product dependency 'BFKit' not found

What I am doing incorrect?

The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.4.99.

I really love simplicity of this framework and the way it is heading. However, I'm not entirely sure I like the semantics of the new func finish(_ hasFailed: Bool) call of version 2.0 of Queuer.

At the call side a successful finish of an operation now looks like this:

operation.finish(false)

Since the parameter name is not exposed, my mind reads "operation not finished". If I'm the only person seeing a potential pitfall here, please close the issue and let's forget about it. Otherwise, I suggest to either exposed the parameter name to make obvious what is happening:

operation.finish(hasFailed: false)

Or, what I think would be a more natural approach, change the semantics to func finish(success: Bool):

operation.finish(success: true)

Or maybe event to func finish(success: Bool = true) :

operation.finish()

I think the last option could have some benefits:

• The most common task of just finishing an operation is the simplest option: operation.finish()
• If a user needs a more fine grained behavior, she can add details: operation.finish(success: false)
• A user new to the framework needs not to know, that a retry-logic event exists
• This approach is compatible to the previous version of the framework

Hello,

I am discovering this project which looks super interesting. However, I have a question about the Queuer class and the addChainedOperations method. Is it possible for the queued operations to pass the result of their process to the next one?

For example:
Operation1 -> Copies a file in a temporary directory and returns an URL.
Operation2 -> Takes an URL as input and uploads the corresponding file on a server.

Is it possible for Operation2 to get the input from Operation1 if they are queued with addChainedOperations?

Best regards,
Nicolas

Hi

I have been experimenting with this library for a tool I am porting from macOS to Linux and I seem to have a strange problem that I am unsure if is in this library or underlying in dispatch.

I am trying to add work to a queue on Linux to parallelise it, but it looks like the queue is never longer than one item and therefore not doing anything in parallel.

A minimum example:

import Queuer
import Foundation
import Dispatch


let queue = Queuer(
        name: "write", maxConcurrentOperationCount: Int.max, qualityOfService: .background)

for i in 1 ..< 10 {
        let op = ConcurrentOperation { _ in
                Thread.sleep(forTimeInterval: 0.2)
                print(i)
        }
        // queue.addOperation(op)
        op.addToQueue(queue)
        print("Queue length: ", queue.operationCount)
}

print("Queue length: ", queue.operationCount)
queue.waitUntilAllOperationsAreFinished()
print("Queue length: ", queue.operationCount)

Resulting in (where everything always print in order, one at the time):

Queue length:  1
Queue length:  1
Queue length:  1
Queue length:  1
Queue length:  1
Queue length:  1
Queue length:  1
Queue length:  1
Queue length:  1
Queue length:  1
1
2
3
4
5
6
7
8
9
Queue length:  0

I might be doing something silly, but I am struggling to see something obvious.

EDIT:

Essential information I forgot:

I have tested this with Queuer 2.1.1 and Swift 5.2.4 on Ubuntu 20.04 and 20.10 Beta. (and macOS, but that works as intended)

The call of interface A returns the result and interface B is called, interface B finishes calling C, and finally synthesizes and renders. This kind of blocking doesn't seem to work.

I can't open documentation. Can you please fix the link?

Is it work in NSURLUploadTask in background/suspended state of app.

I want to upload task execute in synchronize manner.

Let's say 10 task in queue.
It should execute in queue one by one like... 1, 2,3..etc

Need to upload thousands of images in background.

Please advise and suggestions are greatly appreciated.

Steps to reproduce

1. Add some ConcurrentOperations to a queue
2. Add a completion handler to the same queue.

Expected behavior:
Completion handler gets called after the last operation in queue calls finish().

Actual behavior:
Completion handler gets called regardless if the queue operations are still running (finish() hasn't been called yet)

When uploading an iOS / watchOS app bundle via fastlane to iTunes Connect I get the following error message from iTunes Connect:

[17:30:23]: ERROR ITMS-90081: "This bundle is invalid. Applications built for more than one architecture require an iOS Deployment Target of 3.0 or later."
Return status of iTunes Transporter was 1: ERROR ITMS-90081: "This bundle is invalid. Applications built for more than one architecture require an iOS Deployment Target of 3.0 or later."
The call to the iTMSTransporter completed with a non-zero exit status: 1. This indicates a failure.

Changing the WATCHOS_DEPLOYMENT_TARGET of the watch target of the Queuer framework from 2.0 to 3.0 solves this issue.

I have to run task A, B, C and D.
Task B needs A.
Tasks C and D need B.

I would like to run a queue in this order

1. Task A
2. Task B (needs A)
3. Task C and D in parallel (both need B)

What would be the easiest way to achieve it with Queuer?