CombineLatest operator is not emitting when inners publishers use subscribe(on:) - ios

I'm observing an unexpected behavior regarding CombineLatest, if the inner publishers has subscribe(on:), the CombineLatest stream is not emitting any value.
Notes:
With Zip operator is working
Moving the subscribe(on:) / receive(on:) to the combineLatest stream also work. But in this particular use case, the inner publishers is defining their subscribe/receive
because are (re)used in other places.
Adding subscribe(on:)/receive(on:) to only one of the inner publishers also work, so the problem is just when both have it.
func makePublisher() -> AnyPublisher<Int, Never> {
Deferred {
Future { promise in
DispatchQueue.global(qos: .background).asyncAfter(deadline: .now() + 3) {
promise(.success(Int.random(in: 0...3)))
}
}
}
.subscribe(on: DispatchQueue.global())
.receive(on: DispatchQueue.main)
.eraseToAnyPublisher()
}
var cancellables = Set<AnyCancellable>()
Publishers.CombineLatest(
makePublisher(),
makePublisher()
)
.sink { completion in
print(completion)
} receiveValue: { (a, b) in
print(a, b)
}.store(in: &cancellables)
Is this a combine bug or expected behavior? Do you have any idea of how can be setup this kind of stream where the inners can define its own subscribe scheduler?

Yes, it's a bug. We can simplify the test case to this:
import Combine
import Dispatch
let pub = Just("x")
.subscribe(on: DispatchQueue.main)
let ticket = pub.combineLatest(pub)
.sink(
receiveCompletion: { print($0) },
receiveValue: { print($0) })
This never prints anything. But if you comment out the subscribe(on:) operator, it prints what's expected. If you leave subscribe(on:) in, but insert some print() operators, you'll see that the CombineLatest operator never sends any demand upstream.
I suggest you copy the CombineX reimplementation of CombineLatest and the utilities it needs to compile (the CombineX implementations of Lock and LockedAtomic, I think). I don't know that the CombineX version works either, but if it's buggy, at least you have the source and can try to fix it.

Related

Why a Combine publisher can still emit values after it emits completion

Theoretically, in my opinion, a publisher will not emit values once it emits a completion event. It is true when I use publishers such as PassthroughSubject .
However, as the sample code below, I use a publisher like Just or [1, 2, 3].publisher and the first subscriber already receives a completion. But the second subscriber can still receive the value emitted and a completion event.
Am I misunderstanding something?
var subscriptions = Set<AnyCancellable>()
let publisher = Just(1) // or [1, 2, 3].publisher
publisher.sink {
print($0)
} receiveValue: {
print($0)
}
.store(in: &subscriptions)
publisher.sink {
print($0)
} receiveValue: {
print($0)
}
.store(in: &subscriptions)
The output in the console is:
1
finished
1
finished
You are subscribing twice and each subscriber is getting the value and a completion.

iOS Combine Start new request only if previous has finished

I have network request that triggers every last cell in switui appearas. Sometimes if user scrolls fast enough down -> up -> request will trigger before first one finishes. Without combine or reactive approach I have completion block and bool value to handle this:
public func load() {
guard !isLoadingPosts else { return }
isLoadingPosts = true
postsDataProvider.loadMorePosts { _ in
self.isLoadingPosts = false
}
}
I was wondering if with combine this can be resolved more elegantly, without the need to use bool value. For example execute request only if previous has finished?
It looks like you want to skip making the call if it's already in progress.
Since you didn't share any of the Combine code you might have, I'll assume that you have a publisher-returning function like this:
func loadMorePosts() -> AnyPublisher<[Post], Error> {
//...
}
Then you can use a subject to initiate a load call, a flatMap(maxPublishers:_:) downstream, with a number of publishers limited to 1:
let loadSubject = PassthroughSubject<Void, Never>()
loadSubject
.flatMap(maxPublishers: .max(1)) {
loadMorePosts()
}
.sink(
receiveCompletion: { _ in },
receiveValue: { posts in
// update posts
})
.store(in: &cancellables)
The above pipeline subscribes to the subject, but if another value arrives before flatMap is ready to receive it, it would simply be dropped.
Then the load function becomes:
func load() {
loadSubject.send(())
}

Swift Combine - Merging multiple Futures

I'm trying to merge multiple Futures with combine and I'm out of luck so far. I'm trying using Publishers.MergeMany similar to this.
let f = Future<Void, Error> { promise in
promise(.success(Void()))
}
let g = Future<Void, Error> { promise in
promise(.success(Void()))
}
var subscriptions = Set<AnyCancellable>()
Publishers.MergeMany([f,g]).collect()
.sink { _ in
print("merge")
} receiveValue: { value in
print("done")
}.store(in: &subscriptions)
For some reason on my real case scenario, only the first publisher finish but the other one get stuck in oblivion.
If a call each Future one by one sequentially, all works fine.
Does anybody had an issue like this before?

How to restart dataTaskPublisher after failure?

I have some code that makes a request to the net when the count value changes
#Published var count: Float = 0
init(data: SomeData) {
///
$count
.debounce(for: .seconds(1), scheduler: RunLoop.main)
.filter { return $0 != self.product.quantity }
.setFailureType(to: APIProviderError.self)
.flatMap { val -> AnyPublisher<Cart, APIProviderError> in
return self.cartService.update(item: params)
}
}
.sink { result in
print(result)
} receiveValue: { cart in
print(cart)
}
.store(in: &cancellable)
///
}
The cartService.update return dataTaskPublisher.
When any error is returned, the flatmap is never called again.
Can I restart it?
Can I restart it?
No. In the Combine framework, when a pipeline fails, the whole pipeline is cancelled and the publisher is done.
However, inside your flatMap you can build a mini-pipeline that does a catch and prevents the failure from escaping into the outer pipeline. You would then be able to keep using the outer pipeline if desired.
Also, if you think it will do any good, you can prevent the error from promulgating with a retry, which will try the fetch again. A data task publisher only fetches once, unless a retry makes it try again.

Convert URLSession.DataTaskPublisher to Future publisher

How to convert URLSession.DataTaskPublisher to Future in Combine framework.
In my opinion, the Future publisher is more appropriate here because the call can emit only one response and fails eventually.
In RxSwift there is helper method like asSingle.
I have achieved this transformation using the following approach but have no idea if this is the best method.
return Future<ResponseType, Error>.init { (observer) in
self.urlSession.dataTaskPublisher(for: urlRequest)
.tryMap { (object) -> Data in
//......
}
.receive(on: RunLoop.main)
.sink(receiveCompletion: { (completion) in
if case let .failure(error) = completion {
observer(.failure(error))
}
}) { (response) in
observer(.success(response))
}.store(in: &self.cancellable)
}
}
Is there any easy way to do this?
As I understand it, the reason to use .asSingle in RxSwift is that, when you subscribe, your subscriber receives a SingleEvent which is either a .success(value) or a .error(error). So your subscriber doesn't have to worry about receiving a .completion type of event, because there isn't one.
There is no equivalent to that in Combine. In Combine, from the subscriber's point of view, Future is just another sort of Publisher which can emit output values and a .finished or a .failure(error). The type system doesn't enforce the fact that a Future never emits a .finished.
Because of this, there's no programmatic reason to return a Future specifically. You could argue that returning a Future documents your intent to always return either exactly one output, or a failure. But it doesn't change the way you write your subscriber.
Furthermore, because of Combine's heavy use of generics, as soon as you want to apply any operator to a Future, you don't have a future anymore. If you apply map to some Future<V, E>, you get a Map<Future<V, E>, V2>, and similar for every other operator. The types quickly get out of hand and obscure the fact that there's a Future at the bottom.
If you really want to, you can implement your own operator to convert any Publisher to a Future. But you'll have to decide what to do if the upstream emits .finished, since a Future cannot emit .finished.
extension Publisher {
func asFuture() -> Future<Output, Failure> {
return Future { promise in
var ticket: AnyCancellable? = nil
ticket = self.sink(
receiveCompletion: {
ticket?.cancel()
ticket = nil
switch $0 {
case .failure(let error):
promise(.failure(error))
case .finished:
// WHAT DO WE DO HERE???
fatalError()
}
},
receiveValue: {
ticket?.cancel()
ticket = nil
promise(.success($0))
})
}
}
}
Instead of converting a data task publisher into a Future, convert a data task into a Future. Just wrap a Future around a call to a URLSession's dataTask(...){...}.resume() and the problem is solved. This is exactly what a future is for: to turn any asynchronous operation into a publisher.
How to return a future from a function
Instead of trying to return a 'future' from a function you need to convert your existing publisher to a AnyPublisher<Value, Error>. You do this by using the .eraseToAnyPublisher() operator.
func getUser() -> AnyPublisher<User, Error> {
URLSession.shared.dataTaskPublisher(for: request)
.tryMap { output -> Data in
// handle response
return output.data
}
.decode(type: User.self, decoder: JSONDecoder())
.mapError { error in
// handle error
return error
}
.eraseToAnyPublisher()
}

Resources