Fixer of explicitly unwrapped optionals

Filtering by Tag: Combine

SwiftUI.List selection is not working as expected in Beta 5

Added on by Paul Wood.

So a List can have selected items in it in SwiftUI. However Zoe Smith found an issue with them if you need to have the list preselected and provided to the SwiftUI framework via a BindableObject. The following Script is mostly working, but after some really simple changes the selection no longer works.

At first Glance I thought everything was fine, A the item I selected because it was first, selected all fine. I thought that was that.


Zoe changed the Selected Item from A to C and no longer saw a selection on first load


Tap A though and you got both items visible


I tried to go above and beyond to model something that I consider to be most normal in an Application, and ObservableObject holding @Published arrays and sets to Reference Types. However nothing worked as expected in this setup, not even the editing mode!


So if you are using List selection in SwiftUI in the Beta, I hope this is a warning to what is currently possible and if this bothers you please file a Feedback to Apple about it, I already have, and Zoe will too!

SwiftUI.FetchRequest is lacking dynamic input

Added on by Paul Wood.

Given the new property Wrappers for core Data and the environment variable for managedObjectContext I would expect that the properties would be dynamic in some way to respond to @State, or @ObjectBinding changed that are related to the fetch request the view is managing. currently there is no way to pass something as simple as a NSManagedObjectID to a FetchRequest to populate a new view dynamically based on use section. Nor is it possible to change the attributes of a request (Sorting or Predicate) dynamically based on user input an extremely common use case for Core Data and NSFetchRequest in general.

For example given a List of Int I could have a state that changes them to ascending and descending order

The only way to do this at the moment is an if statement around two FetchRequest that are both built at the view’s startup. Those request would then need to be for the life of that View.

Next I can image a complex query that is built using a user interface with text fields that would build a NSPredicate built on state. Each input could be handled by a SwiftUI view, and have a binding to the output expected. As these outputs change the Fetch request also could change dynamically or only change when the user presses a button.

In short here is the possibility I wish I had:

I’m confident this work is technically possible without first party support using the FetchResults struct and new @Environment(\.managedObjectContext) API

Also my fleeting thought on Twitter and Plea to Luca for future reference :)

I think the ability to support this feature is contingent on the future direction of Property Wrappers out lined here on Swift Evolution

Below is a Gist of my research into the possibility with the current API, using a container view to update a Child view that actually have the list. Each revision compiles, looks correct from the programmers perspective but does NOT render an updated sort order using SwiftUI List view. I hope this misuse of the API (I think I must be a misuse) should be documented in some way before release of SwiftUI. The painful intellectual part is that the binding renders correctly as well as a debug statement that performs the fetchRequest. the fetched results printed from that statement ARE reordered correctly it just does not update the SwiftUI view. So I feel like I’m close but SwiftUI prevents me from displaying the new fetched results for some reason. This code is part of a research project on SwiftUI, Combine with back pressure and CoreData

Lastly I doubt I’ll be alone in trying to have dynamic results with this new API. The framework could give feedback that I am incorrectly using the FetchResults struct.

Combine needs back pressure documentation

Added on by Paul Wood.

For context to this post, Heres some of us talking about it on Twitter:

This lack of documentation will quickly lead to performance issues being the default for many new to the concept of Reactive programming. An overview of back-pressure in Combine should be written and linked to from this page covering Combine in General:

Demand isn’t even mentioned on this page of Documentation about Subject.

Demand and how it works could be better explained on this page on Subscribers are the source of truth for demand:

The returned value for demand should be documented on these pages:

CurrentValueSubject and PassthroughSubject are implemented with demand unlimited. I assume this is because they must conform to both a publisher as well as a subscriber. This really should be explained in their documentation to prevent people from using them to implement back pressure and sharing the results to other subscribers using .share()

Need some inspiration on how to start documenting the overall subject? Please look at my personal mental model on back pressure here. With many more links of inspiration, for example RxJava’s documentation, are in the post.

Apple's Combine and reactive programming with Back pressure

Added on by Paul Wood.

When Apple released Combine in June 2019 those of use using RxSwift already felt justified if not vindicated that we had been making the right architectural decisions. This new framework, built into the foundation of the platform is going to increase the number of developers using reactive methods to solve problems exponentially and help the developer community as a whole solve problems in a consistent manner with less code.

I don’t want to give a rundown of what Combine and Reactive programming are. Nor do I want to compare and contrast Combine with RxSwift, which was my chosen flavor of Reactive Programming on Apple’s platforms before Combine. Please check out Casey Liss’s article for an overview of Combine. And if you are more an auditory learner check out Casey and John Sundell on the Swift by Sundell podcast.

I wanted to deep dive into something Combine has and RxSwift does not, Back pressure. This is a feature of Combine that allows a communication flow both up and down a reactive chain. That data flow is best considered, Elements move down the stream and Demand is returned up the stream to signify if more work can be done.

Everything is mental models when learning a new concept. After playing with the new API’s a little mental model for the different moving parts of Combine that deal with back pressure came to me, Marbles in a Funnel

At this point if you haven’t been to you are doing yourself a disservice, go check that site out first. Marbles are a great mental model for elements of a stream. They flow and roll place to place but they are also one unit and concrete unlike a stream of water. Mental models using liquids don’t stick for me when thinking about back pressure because there is not a single “unit” of water. A more humorous mental model for elements combining the two could be a lazy river or rafting ride with lots of people in inner-tubes flowing through turbulent water features.

Marble, Element - an element published by a Publisher

Marble, Element - an element published by a Publisher

Funnel, Publisher - represents work that can be done but a publisher, such as reading a line from a CSV file

Funnel, Publisher - represents work that can be done but a publisher, such as reading a line from a CSV file

Tube, Buffer - a tube that stacks up elements

Tube, Buffer - a tube that stacks up elements

Gate, Subscriber - the number of elements that a subscriber can handle. How many marbles would come out each time I opened it? The value returned by the subscriber for Demand can be thought of as the width of this gate creating back pressure so the marbles stay in the buffer

Gate, Subscriber - the number of elements that a subscriber can handle. How many marbles would come out each time I opened it? The value returned by the subscriber for Demand can be thought of as the width of this gate creating back pressure so the marbles stay in the buffer

Bringing it all together

I wrote up an example project that I hope will help others experiment with back pressure with a real world use case. You can find it on Github as PaulWoodiii/Combine-Backpressure-Research-CSV.

In the example project the “marbles” are rows in a Comma Separated Value file. each new row is sent down a reactive chain to a subscriber that does some work. As part of the published values a simple mapping from an array of Strings to a value type “NameType” helps us see how data can be transformed from a raw text file to a usable data structure that can be rendered in a User interface, or saved to a database.

I’ve added a simulation of back pressure by creating my own Subscriber based on Sink called SlowSink that sleeps the thread for some time. This creates back pressure and using breakpoints a developer can see when work is done. I’ve shared a few breakpoints in the project file to get readers started.

I hope this helps other developers get started learning how back pressure in reactive steams can be used, debugged and tested. However I know it is not complete and would recommend anyone who wants to really dive into the deep end to read documentation on back pressure written for RxJava.

I can assume that Apple has been working on Combine for client side development for ease of use when it comes to developing asynchronous code. RxSwift got along very well without back pressure for client side development though. My suspicion is that the inclusion of back pressure hints that Apple is aware of its utility for server side development. With back pressure developers can read massive files, while keeping a low memory footprint.