In Combine framework there's a concept of a demand, which allows signalling backpressure to publishers.
Suppose I have a simple publisher:
let numbers = Publishers.Sequence<ClosedRange<Int>, Error>(sequence: 0...100)
I would like to download certain URLs that use these numbers as arguments. I also would like a next download to start only after a previous download has finished.
A naive approach then would look like this:
let subscription = numbers.sink(receiveCompletion: { _ in }, receiveValue: {
let url = URL(string: "https://httpbin.org/get?value=\($0)")!
URLSession.shared.dataTask(with: url) {
$0.map { print(String(data: $0, encoding: .utf8)!) }
}.resume()
})
Unfortunately, this wouldn't satisfy the requirement of waiting for a previous download to complete before starting the next one. As far as I know, sink function would return a value of type AnyCancellable, not of type Subscription. If the latter was the case, we could call the request function on the subscription with a specific demand after an upload completes.
What would be the best way to control demand of a subscription provided by sink or any other standard Combine Subscriber?
Turns out, flatMap operator takes an additional maxPublishers argument that takes a Subscribers.Demand value. In combination with the Future publisher, this allows the numbers publisher to wait until the future is able to process a given value before sending a next one.
Applying this to the original code, downloading values one after another would look like this:
enum DownloadError: Error {
case noData
}
let subscription = numbers.flatMap(maxPublishers: .max(1)) { number in
Future { promise in
let url = URL(string: "https://httpbin.org/get?value=\(number)")!
URLSession.shared.dataTask(with: url) {
switch ($0, $2) {
case let (data?, nil):
promise(.success(data))
case let (nil, error?):
promise(.failure(error))
default:
promise(.failure(DownloadError.noData))
}
}.resume()
}
}.sink(
receiveCompletion: { _ in print("errors should be handled here") },
receiveValue: { print(String(data: $0, encoding: .utf8)!) }
)
Related
I'm trying to make a fairly simple API call in Swift but, for some reason, my dataTask code is not running. I've made sure that the .resume() is there. This code has worked in the past but, something has changed recently and I don't know what it is. The only thing I can think of is the url. I've changed the ingredients but, when putting the url into a browser, it returns JSON data normally. When running this function, I get two "Outside URLSession.shared.dataTask....." messages in a row with nothing in between, indicating that the URLSession block of code isn't running. I'm a little new to APIs so, any help would be greatly appreciated. Please let me know if there's any more information I can provide. Also, I'm on an older MacBook and am using Swift5 if that makes a difference. Thanks!
let url: URL! = URL(string: "https://api.spoonacular.com/recipes/findByIngredients?ingredients=" + ingredientString + "&apiKey=aaabbbccc111222333")
print("URL: " + url.absoluteString)
let request = URLRequest(url: url)
// Make the API call
print("Outide URLSession.shared.dataTask.....")
let session = URLSession.shared.dataTask(with: request) { data, response, error in
print("Inside URLSession.shared.dataTask.....")
DispatchQueue.main.async {
print("Inside DispatchQueue.main.async....")
if data == nil {
print("No data recieved.")
}
print("data != nil.... Moving on to JSONDecoder....")
self.model = try! JSONDecoder().decode([RecipeSearchElement].self, from: data!)
}
}
session.resume()
print("Outside URLSession.shared.dataTask.....")
Unrelated to your immediate question at hand (which I answered elsewhere), I would advise a few changes to the routine:
One should not build a URL through string interpolation. Use URLComponents. If, for example, the query parameter included a space or other character not permitted in a URL, URLComponents will percent-encode it for you. If do not percent-encode it properly, the building of the URL will fail.
I would avoid try!, which will crash the app if the server response was not what you expected. One should use try within a do-catch block, so it handles errors gracefully and will tell you what is wrong if it failed.
I would recommend renaming the URLSessionDataTask to be task, or something like that, to avoid conflating “sessions” with the “tasks” running on that session.
I would not advise updating the model from the background queue of the URLSession. Fetch and parse the response in the background queue and update the model on the main queue.
Thus:
var components = URLComponents(string: "https://api.spoonacular.com/recipes/findByIngredients")
components?.queryItems = [
URLQueryItem(name: "ingredients", value: ingredientString),
URLQueryItem(name: "apiKey", value: "aaabbbccc111222333")
]
guard let url = components?.url else {
print("Unable to build URL")
return
}
// Make the API call
let task = URLSession.shared.dataTask(with: url) { data, _, error in
DispatchQueue.main.async {
guard error == nil, let data = data else {
print("No data received:", error ?? URLError(.badServerResponse))
return
}
do {
let model = try JSONDecoder().decode([RecipeSearchElement].self, from: data)
DispatchQueue.main.async {
self.model = model
}
} catch let parseError {
print("Parsing error:", parseError, String(describing: String(data: data, encoding: .utf8)))
}
}
}
task.resume()
In a more advanced observation, I would never have a network call update the model directly. I would leave that to the caller. For example, you could use a completion handler pattern:
#discardableResult
func fetchIngredients(
_ ingredientString: String,
completion: #escaping (Result<[RecipeSearchElement], Error>) -> Void
) -> URLSessionTask? {
var components = URLComponents(string: "https://api.spoonacular.com/recipes/findByIngredients")
components?.queryItems = [
URLQueryItem(name: "ingredients", value: ingredientString),
URLQueryItem(name: "apiKey", value: "aaabbbccc111222333")
]
guard let url = components?.url else {
completion(.failure(URLError(.badURL)))
return nil
}
// Make the API call
let task = URLSession.shared.dataTask(with: url) { data, _, error in
print("Inside URLSession.shared.dataTask.....")
DispatchQueue.main.async {
guard error == nil, let data = data else {
DispatchQueue.main.async {
completion(.failure(error ?? URLError(.badServerResponse)))
}
return
}
do {
let model = try JSONDecoder().decode([RecipeSearchElement].self, from: data)
DispatchQueue.main.async {
completion(.success(model))
}
} catch let parseError {
DispatchQueue.main.async {
completion(.failure(parseError))
}
}
}
}
task.resume()
return task
}
And then the caller could do:
fetchIngredients(ingredientString) { [weak self] result in
switch result {
case .failure(let error): print(error)
case .success(let elements): self?.model = elements
}
}
This has two benefits:
The caller now knows when the model is updated, so you can update your UI at the appropriate point in time (if you want).
It maintains a better separation of responsibilities, architecturally avoiding the tight coupling of the network layer with that of the view or view model (or presenter or controller) layers.
Note, I am also returning the URLSessionTask object in case the caller would like to cancel it at a later time, but I made it an #discardableResult so that you do not have to worry about that if you are not tackling cancelation at this point.
If you (a) are reaching the “outside” message, but not seeing the “inside” message; and (b) are absolutely positive that you are reaching the resume statement, it is one of a few possibilities:
The app may be terminating before the asynchronous request has time to finish. This can happen, for example, if this is a command-line app and you are allowing the app to quit before the asynchronous request has a chance to finish. If you want a command-line app to wait for a network request to finish, you might run a RunLoop that does not exit until the network request is done.
It can also happen if you use a playground and neglect to set needsIndefiniteExecution:
import PlaygroundSupport
PlaygroundPage.current.needsIndefiniteExecution = true
For the sake of completeness, there are a few other, less common, possibilities:
You have some other network request whose completion handler is blocked/deadlocked, thereby preventing anything else from running on the URLSession dedicated, serial, queue.
You have thread explosion somewhere else in your code, exhausting the limited pool of worker threads, preventing other tasks/operations from being able to get an available worker thread.
I wonder if it is possible to access values in a combine-operator-chain that are used further up in the chain.
For example, if you have an array of strings, and you download a resource with each string, is it possible to access the string itself?
Maybe a pseudo-code example will help understand better:
let strings = ["a", "b", "c"]
strings.publisher
.compactMap{ str in
URL(string: "https://someresource/\(str)")
}
.flatMap { url in
URLSession.shared.dataTaskPublisher(for: url)
}
.map { $0.data}
.map { data in
// here I would need the "str" string from above
}
Help is much appreciated
Thx, Gregor
The answer that Jake wrote and deleted is correct. I don't know why he deleted it; maybe he felt he couldn't support it with example code. But the answer is exactly right. If you need the initial str value later in the pipeline, it is up to you to keep passing it down through every step. You typically do that by passing a tuple of values at each stage, so that the string makes it far enough down the chain to be retrieved. This is a very common strategy in Combine programming.
For a simple example, take a look at the Combine code in the central section of this article:
https://www.biteinteractive.com/swift-5-5-asynchronous-looping-with-async-await/
As I say in the article:
You’ll observe that, as opposed to GCD where local variables just magically “fall through” to nested completion handlers at a lower level of scope, every step in a Combine pipeline must explicitly pass down all information that may be needed by a later step. This can result in some rather ungainly values working their way down the pipeline, often in the form of a tuple, as I’ve illustrated here.
But I don’t regard that as a problem. On the contrary, being explicit about what’s passing down the pipeline seems to me to be a gain in clarity.
To illustrate further, here's a rewrite of your pseudo-code; this is real code, you can run it and try it out:
class ViewController: UIViewController {
var storage = Set<AnyCancellable>()
override func viewDidLoad() {
super.viewDidLoad()
let strings = ["a", "b", "c"]
let pipeline = strings.publisher
.map { str -> (String, URL) in
let url = URL(string: "https://www.apeth.com/pep/manny.jpg")!
return (str, url)
}
.flatMap { (str, url) -> AnyPublisher<(String, (data: Data, response: URLResponse)), URLError> in
let sess = URLSession.shared.dataTaskPublisher(for: url)
.eraseToAnyPublisher()
let just = Just(str).setFailureType(to: URLError.self)
.eraseToAnyPublisher()
let zip = just.zip(sess).eraseToAnyPublisher()
return zip
}
.map { (str, result) -> (String, Data) in
(str, result.data)
}
.sink { comp in print(comp) } receiveValue: { (str, data) in print (str, data) }
pipeline.store(in: &storage)
}
}
That's not the only way to express the pipeline, but it does work, and it should give you a starting point.
I'm coming from JS and learning Swift to build an iOS native version of an app.
In JS, I use the following pattern all the time:
...
async function doAyncFunction(item) {
try {
// do async call to fetch data using item
return Promise.resolve(data);
} catch (error) {
return Promise.reject(error);
}
}
const promises = items.map((item) => doAyncFunction(item));
const results = await Promise.all(promises);
...
I've started looking at PromiseKit, but I'm wondering what's are the Swift ways of doing this?
Thanks.
The forthcoming Swift 5.5 in Xcode 13 (still in beta at this point in time) uses a very similar async-await pattern. See The Swift Programming Language: Concurrency.
In the interim, there are a unfortunately dizzying number of alternatives. For example, there are a variety of third-party promise/future frameworks. Or there is the declarative Combine framework, which was launched a few years agar with the advent of the non-imperative patterns of SwiftUI.
All of that having been said, the most common pattern you’ll see in Swift code is the use of escaping “closures” which are effectively units of code that are passed as a parameter to a function, and which the function invokes when the asynchronous task completes. In that pattern you don’t await, but rather just specify what you want to do when the asynchronous task finishes. For example, in this function, it has a parameter called completion which is a closure that is called when the asynchronous task completes:
func fetch(using value: Int, completion: #escaping (Result<Foo, Error>) -> Void) {
let url = …
let task = URLSession.shared.dataTask(with: url) { data, response, error in
// handle errors, if any, e.g.:
if let error == error else {
completion(.failure(error))
return
}
// parse data into `Foo` here, and when done, call the `completion closure:
…
completion(.success(foo))
}
task.resume()
}
And then you would call it like so:
fetch(using: 42, completion: { result in
// this is called when the fetch finishes
switch result {
case .failure(let error): // do something with `error`
case .success(let foo): // do something with `foo`
}
})
// note, execution will continue here, and the above closure will
// be called later, so do not try to use `foo` here
Or, using a more concise “trailing closure” syntax:
fetch(using: 42) { result in
// this is called when the fetch finishes
switch result {
case .failure(let error): // do something with `error`
case .success(let foo): // do something with `foo`
}
}
// note, execution will continue here, and the above closure will
// be called later, so do not try to use `foo` here
And if you wanted to be notified when a series of calls was done, you could use a DispatchGroup, e.g.
let group = DispatchGroup()
for value in values {
group.enter()
fetch(using: value) { result in
// do something with result
group.leave()
}
}
group.notify(queue: .main) {
// this is called when every `enter` call is matched up with a `leave` Call
}
It is up to you whether you stick to the beta version of Swift 5.5 with a very familiar async-await pattern, use a third-party future/promise library, use Combine, or use the traditional closure-based pattern, shown above.
At the very least, I would suggest familiarizing yourself with this latter pattern as it is the predominant technique in Swift right now. But rest assured that the familiar async-await pattern is coming soon, so if you are willing to wait for it to finish going through the beta process (or join that beta process), then check that out.
Using the aforementioned builtin Combine framework, you have several options. The one that you probably want is Publishers.Merge:
let publishers = ... // multiple functions that implement the Publisher protocol
let combined = Publishers.MergeMany(publishers)
Alternatives to MergeMany are Merge, Merge3, Merge4 up to Merge8 when the amount of publishers is set. If the number of outputs is variable, use MergeMany.
Other options include merge on the publishers themselves:
let publisher1 = ...
let publisher2 = ...
publisher1.merge(publisher2)
CombineLatest or, in the case of a publisher that immediately completes, Zip can be used to receive a tuple when everything is done:
let publisher1 = ...
let publisher2 = ...
Publishers.CombineLatest(publisher1, publisher2)
For the moment there is a great framework that is closest to async/await, it's SwiftCoroutine https://github.com/belozierov/SwiftCoroutine (much better than promiseKit, I tested the 2..)
Swift coroutine with your example:
func doFutureFunction() -> CoFuture<Int> {
CoFuture { promise in
myRequest { error, data in
if let error = error {
promise(.failure(error))
} else {
promise(.success(data))
}
}
}
}
let futures = items.map { item in doFutureFunction(item) } // [CoFuture<Int>]
DispatchQueue.main.startCoroutine {
let results = promises.compactMap { try? $0.await() } // [Int]
}
The equivalent of
consts value = await future.value
consts value1 = await future.value
consts value2 = await future.value
console.log("Value " + value + ", value1 " + value1 + ", value2 " + value2)
is
DispatchQueue.main.startCoroutine {
do {
let value = try future.await()
let value1 = try future.await()
let value2 = try future.await()
print("Value \(value), value1 \(value1), value2 \(value2)")
} catch {
print(error.localizedDescription)
}
}
While waiting for swift 5.5 and official async / await from Apple
You can look at PromiseQ it's javascript style promises for Swift. It implements all javascript's Promise features: resolve/reject, then, finally, fetch etc. and appends some additional ones: suspend/resume, cancel, retry, timeout etc.
It also supports all, race, any e.g.:
// Fetch avatars of first 30 GitHub users.
struct User : Codable {
let login: String
let avatar_url: String
}
async {
let response = try fetch("https://api.github.com/users").await()
guard response.ok else {
throw response.statusCodeDescription
}
guard let data = response.data else {
throw "No data"
}
let users = try JSONDecoder().decode([User].self, from: data)
let images =
try Promise.all(
users
.map { $0.avatar_url }
.map { fetch($0) }
).await()
.compactMap { $0.data }
.compactMap { UIImage(data: $0) }
async(.main) {
print(images.count)
}
}
.catch { error in
print(error.localizedDescription)
}
Swift's concurrency such as Dispatch queues, Combine and the newest async\await (Swift 5.5) are different from javascript Promises and you can not find many convenient approaches that you used before.
I'm answering myself here with a solution, using PromiseKit, in case it might help someone.
The below is obviously not a full implementation, but it shows how the pattern can be implemented.
func doManyAsyncRequests(userIds: [String], accessToken: String) -> Promise<Void> {
Promise { seal in
let promises = spotifyUserIds.map {
doSingleAsyncRequest(userId: $0.id, accessToken: accessToken) // this function returns a promise
}
when(fulfilled: promises).done { results in
print("Results: \(results)")
// process results
}.catch { error in
print("\(error)")
// handle error
}
}
}
How can I use the dispatchQueue or something like "await" in Javascript to return a value in self.arrayData (because the end of my loop is ran before the previous content). I am used to R and Python where the code runs line by line, What is the best behavior to adopt in Swift ?
Here is the function :
func fetch2(){
var i:Int = 0
repeat {
AF.request(itemLookUp[i]).validate().responseJSON { response in
switch response.result {
case .failure(let error):
print("\(error) in fetch2")
case .success(let value):
let json = JSON(value)
//Extract the Matiere for ML Extraction
self.matiereInput = json["ResultSet"]["0"]["Result"]["0"]["SpAdditional"].string ?? "none"
let energyCheck:Bool = self.matiereInput.contains("エネルギー") //energy-kcal
if energyCheck==true && self.arrayData[0]==0.0{
//regular expression
var patEnergy = #"(エネルギー)(([^\d]+)(\d+)(\.)(\d+)|([^\d]+)(\d+))"# //avoid the repetition of the pattern within the same matiereinput
let patEnergy2 = self.matches(for: patEnergy, in: self.matiereInput)
patEnergy = patEnergy2.joined(separator:"")
let valueEnergy = self.matches(for: self.regex2, in: patEnergy)
self.arrayData[0] = Double(valueEnergy.joined(separator: "")) ?? 0.0
}
}
}
i = i+1
print(self.arrayData[0])
} while i <= (self.returned-1)
}
Thank you in advance !
The standard pattern is notify with a DispatchGroup, and then use a completion handler to asynchronously notify the caller of the result:
func fetchAll(completion: #escaping (Result<[Double], Error>) -> Void) {
let group = DispatchGroup()
var results: [Double] = []
var errors: [Error] = []
for item in lookupItems {
group.enter() // enter before request
AF.request(item).validate().responseJSON { response in
defer { group.leave() } // leave when this closure is done
switch response.result {
case .failure(let error):
errors.append(error)
case .success(let value):
let result = ...
results.append(result)
}
}
}
group.notify(queue: .main) {
if let error = errors.first { // I don’t know what you want to do if there were multiple errors, so for now I’ll just grab the first one
completion(.failure(error))
} else {
completion(.success(results))
}
}
}
And then you’d use it like so:
fetchAll { result in
switch result {
case .failure(let error):
print(error)
case .success(let values):
print(values)
}
}
Now, I wasn’t able to reverse engineer what you were trying to do (you appear to be updating self.arrayData[0] in every iteration!), so I just returned an array of Double. But you can obviously change the type of results and the parameter of the completion closure to match whatever is relevant in your case.
But don’t get lost in the details of the above example, but rather just focus on a few key observations:
Supply completion handler closure to call when all the requests are done.
Use DispatchGroup to keep track of when all the requests are done.
Supply a notify closure to your DispatchGroup which will be called when all the group.enter() calls are offset by their respective group.leave() calls.
A more subtle observation is that you should refrain from updating properties from within the responseJSON block. Within your asynchronous code, you really want to limit your interaction to local variables if at all possible. Pass the result back in the completion closure (and the caller can update the model and the UI as it sees fit).
I'm relatively new to the Functional Reactive programming world, and still trying to wrap my head around the concepts. I'm utilizing an SDK to make some network requests - specifically to query a remote database. The SDK returns a publisher, and I have a working pipeline that transforms that result into model objects. Here's that working pipeline:
let existingClaimQuery = "SELECT Id, Subject, CaseNumber FROM Case WHERE Status != 'Closed' ORDER BY CaseNumber DESC"
let requestForOpenCases = RestClient.shared.request(forQuery: existingClaimQuery, apiVersion: RestClient.apiVersion)
caseCancellable = RestClient.shared
.publisher(for: requestForOpenCases)
.receive(on: RunLoop.main)
.tryMap({restresponse -> [String:Any] in
let json = try restresponse.asJson() as? [String:Any]
return json ?? RestClient.JSONKeyValuePairs()
})
.map({json -> [[String:Any]] in
let records = json["records"] as? [[String:Any]]
return records ?? [[:]]
})
.map({
$0.map{(item) -> Claim in
return Claim(
id: item["Id"] as? String ?? "None Listed",
subject: item["Subject"] as? String ?? "None Listed",
caseNumber: item["CaseNumber"] as? String ?? "0"
)
}
})
.mapError{error -> Error in
print(error)
return error
}
.catch{ error in
return Just([])
}
.assign(to: \.claims, on: self)
I went to work on another section of the code, and realized I often need to do this same process - write a query, create a request for that query, and process it through a pipeline that ultimately returns a [[String:Any]].
So here's the million dollar question. What's the right way to encapsulate this pipeline such that I can re-use it without having to copy/pasta the entire pipeline all over the code base? This is my ... attempt at it, but it feels ...wrong?
class QueryStream: ObservableObject {
var query: String = ""
private var queryCancellable: AnyCancellable?
#Published var records: [[String:Any]] = [[String:Any]]()
func execute(){
let queryRequest = RestClient.shared.request(forQuery: query, apiVersion: RestClient.apiVersion)
queryCancellable = RestClient.shared.publisher(for: queryRequest)
.receive(on: RunLoop.main)
.tryMap({restresponse -> [String:Any] in
let json = try restresponse.asJson() as? [String:Any]
return json ?? [String:Any]()
})
.map({json -> [[String:Any]] in
let records = json["records"] as? [[String:Any]]
return records ?? [[:]]
})
.mapError{error -> Error in
print(error)
return error
}
.catch{ error in
return Just([])
}
.assign(to: \.records, on: self)
}
}
This still requires a pipeline to be written for each use. I feel like there should be some way to have a one off promise like pipeline that would allow for
let SomeRecords = QueryStream("Query here").execute()
Am I too n00b? overthinking it? What's the stack's wisdom?
Entire pipelines are not reusable. Publishers are reusable. When I say "publisher" I mean an initial publisher plus operators attached to it. (Remember, an operator is itself a publisher.) A publisher can exist as a property of something, so you can subscribe to it, or it can be generated for a particular case (like a particular query request) by a function.
To illustrate, here's a one-off pipeline:
let s = "https://photojournal.jpl.nasa.gov/tiff/PIA23172.tif"
let url = URL(string:s)!
let eph = URLSessionConfiguration.ephemeral
let session = URLSession(configuration: eph)
session.dataTaskPublisher(for: url)
.map {$0.data}
.replaceError(with: Data())
.compactMap { UIImage(data:$0) }
.receive(on: DispatchQueue.main)
.assign(to: \.image, on: self.iv)
.store(in:&self.storage)
That pipeline tries to download the data from a URL, tests to see whether it's image data, and if it is, turns the image data into an image and displays it in an image view in the interface.
Let's say I want to do this for various different remote images. Obviously it would be ridiculous to repeat the whole pipeline everywhere. What differs up front is the URL, so let's encapsulate the first part of the pipeline as a publisher that can be generated on demand based on the URL:
func image(fromURL url:URL) -> AnyPublisher<UIImage,Never> {
let eph = URLSessionConfiguration.ephemeral
let session = URLSession(configuration: eph)
return session.dataTaskPublisher(for: url)
.map {$0.data}
.replaceError(with: Data())
.compactMap { UIImage(data:$0) }
.receive(on: DispatchQueue.main)
.eraseToAnyPublisher()
}
Now the only thing that needs to be repeated in various places in our code is the subscriber to that publisher:
let s = "https://photojournal.jpl.nasa.gov/tiff/PIA23172.tif"
let url = URL(string:s)!
image(fromURL:url)
.map{Optional($0)}
.assign(to: \.image, on: self.iv)
.store(in:&self.storage)
You see? Elsewhere, we might have a different URL, and we might do something different with the UIImage that comes popping out of the call to image(fromURL:), and that's just fine; the bulk of the pipeline has been encapsulated and doesn't need to be repeated.
Your example pipeline's publisher is susceptible of that same sort of encapsulation and reuse.
Let me first note that I think you are dispatching to main to early in your pipeline. As far as I can tell, all of your map transforms are pure functions (no side effects or references to mutable state), so they can just as well run on the background thread and thus not block the UI.
Second, as Matt said, a Publisher is generally reusable. Your pipeline builds up a big complex Publisher, and then subscribes to it, which produces an AnyCancellable. So factor out the big complex Publisher but not the subscribing.
You can factor it out into an extension method on your RestClient for convenience:
extension RestClient {
func records<Record>(
forQuery query: String,
makeRecord: #escaping ([String: Any]) throws -> Record)
-> AnyPublisher<[Record], Never>
{
let request = self.request(forQuery: query, apiVersion: RestClient.apiVersion)
return self.publisher(for: request)
.tryMap { try $0.asJson() as? [String: Any] ?? [:] }
.map { $0["records"] as? [[String: Any]] ?? [] }
.tryMap { try $0.map { try makeRecord($0) } }
.mapError { dump($0) } // dump is a Swift standard function
.replaceError(with: []) // simpler than .catch
.eraseToAnyPublisher()
}
}
Then you can use it like this:
struct Claim {
var id: String
var subject: String
var caseNumber: String
}
extension Claim {
static func from(json: [String: Any]) -> Claim {
return .init(
id: json["Id"] as? String ?? "None Listed",
subject: json["Subject"] as? String ?? "None Listed",
caseNumber: json["CaseNumber"] as? String ?? "0")
}
}
class MyController {
var claims: [Claim] = []
var caseCancellable: AnyCancellable?
func run() {
let existingClaimQuery = "SELECT Id, Subject, CaseNumber FROM Case WHERE Status != 'Closed' ORDER BY CaseNumber DESC"
caseCancellable = RestClient.shared.records(forQuery: existingClaimQuery, makeRecord: Claim.from(json:))
.receive(on: RunLoop.main)
.assign(to: \.claims, on: self)
}
}
Note that I've put the receive(on: RunLoop.main) operator in the method that subscribes to the publisher, rather than building it in to the publisher. This makes it easy to add additional operators that run on a background scheduler before dispatching to the main thread.
UPDATE
From your comment:
In promise syntax, i could say execute run() as defined above, and .then(doSomethingWithThatData()) knowing that the doSomethingWithThatData wouldn't run until the intial work had completed successfully. I'm trying to develop a setup where I need to use this records(fromQuery:) method runs, and then (and only then) do soemthing with that data. I'm struggling with how to bolt that on to the end.
I don't know what promise implementation you're using, so it's difficult to know what your .then(doSomethingWithThatData()) does. What you've written doesn't really make much sense in Swift. Perhaps you meant:
.then { data in doSomething(with: data) }
In which case, the doSomething(with:) method cannot possibly be called until the data is available, because doSomething(with:) takes the data as an argument!