Thank goodness for #Apple #iOS silence unknown callers.
I don’t know what is happening, but my phone is suddenly blowing up with #UnknownCallers. Must be some push in politics or something.
An improvement on this feature would be to have those notifications go straight to #NotificationCenter only.
#Swift #CoreData #Combine #Concurrency #AsyncSequence #NotificationCenter
Can anyone more familiar with above topics help me understand what’s going on here?
I thought that NotificationCenter Combine-based and AsyncSequence-based API-s behave exactly the same. Now I hit a case where they don’t. Their behavior differs based on whether I give it the sending object or not.
Why?
#Swift #SwiftUI #Concurrency #StateObject #NotificationCenter
Just ran into a question on how to implement NotificationCenter long-running listeners with modern AsyncSequence API, and have them torn down correctly. This seems to work.
https://forums.swift.org/t/deinit-not-called-in-certain-scenarios-with-for-await-loop/64198/19
I just ran into this, and wanted to share a recipe that works for me. I have a SwiftUI View with the associated ViewModel that’s owned by the view as a StateObject. I want the viewModel to be able to react to a bunch of notifications with the modern async API and long-running AsyncSequences, and for everything to be deallocated correctly when the view ends. I don’t want to code anything by hand and want things to happen automatically with the highest-level code possible. Here’s what I came up w...
blhue (has moved)
Jaanus Kase
Alain Wohlfarth
iDownloadBlog 