I have BehaviourSubject and I want to refresh items with last emitted value. I can do it example below,
func refreshCurrent() {
do {
let items = try currentMatchList.value()
if !(items.first?.items ?? []).isEmpty {
refreshItems(sportId: try currentSport.value())
}
} catch {
LOG.error(error.localizedDescription)
return
}
}
But I was wondering is there any built in RxSwift functionality I might use for same task?
I've found there was a Variable() type once upon a time but now it's gone and it's recommended to use BehaviourSubject it seems.
Thanks in advance.
After searching all the issues in the official github repo I've found long discussion about same problem here and it's closed.
BUT good news is as freak4pc states we can use RxCocoa class BehaviourRelay and it has a direct value access method
example("BehaviorRelay") {
let disposeBag = DisposeBag()
let subject = BehaviorRelay<String>(value: "šØ")
print(subject.value)
subject.addObserver("1").disposed(by: disposeBag)
subject.accept("š¶")
subject.accept("š±")
print(subject.value)
}
Don't know if I get you correctly, but it seems like you want to store your value within a BehaviourSubject.
let foo = BehaviourSubject<[Something]>(value: [])
print(foo.value) //Empty Array
foo.accept([Something(), Something()])
print(foo.value) //Array of two somethings
Related
I have an object which I want to send throughout multiple listeners/subscribers, so I was checking out Combine and I saw 2 different kind of publishers, namely NotificationCenter.Publisher and PassThroughSubject. I am confused why anyone would use a NotificationCenter.Publisher over PassThroughSubject.
I came up with the code below, demonstrating both ways. To summarize:
NotificationCenter.Publisher needs to have a Notification.Name static property
Isn't really that typesafe (since I can post a different kind of object for the same Notification.Name/different publisher for the same Notification.Name)
Posting a new value needs to be done on NotificationCenter.default (not the publisher itself)
An explicit downcast to the used type in the map closure
In what scenarios someone will use NotificationCenter.Publisher over PassThroughSubject?
import UIKit
import Combine
let passThroughSubjectPublisher = PassthroughSubject<String, Never>()
let notificationCenterPublisher = NotificationCenter.default.publisher(for: .name).map { $0.object as! String }
extension Notification.Name {
static let name = Notification.Name(rawValue: "someName")
}
class PassThroughSubjectPublisherSubscriber {
init() {
passThroughSubjectPublisher.sink { (_) in
// Process
}
}
}
class NotificationCenterPublisherSubscriber {
init() {
notificationCenterPublisher.sink { (_) in
// Process
}
}
}
class PassThroughSubjectPublisherSinker {
init() {
passThroughSubjectPublisher.send("Henlo!")
}
}
class NotificationCenterPublisherSinker {
init() {
NotificationCenter.default.post(name: .name, object: "Henlo!")
}
}
If you have to use a 3rd party framework that uses NotificationCenter.
NotificationCenter can be thought of as a first generation message passing system, while Combine is second generation. It has runtime overhead and requires casting the objects you can store in Notifications. Personally I would never use NotificationCenter when building an iOS 13 framework, but you do need to use it to access a lot of iOS notifications that are only published there. Basically in my personal projects Iām going to treat it as read only unless absolutely necessary.
Swift 5, the "Exclusive Access to Memory" enforcement is now on by default for release builds as mentioned in this Swift.org blog post:
Swift 5 Exclusivity Enforcement
I understand the reasoning behind this feature, but with the new Combine framework I feel as if some very normal design patterns are now going to break and I'm curious how best to work around them.
With Combine it's natural for parts of your code to react to changes in a model such that they might need to read from the very property that the model has just changed. But they can no longer do that because it will trigger a memory exception as you attempt to read a value that is currently being set.
Consider the following example:
struct PasswordProposal {
let passwordPublisher = CurrentValueSubject<String, Never>("1234")
let confirmPasswordPublisher = CurrentValueSubject<String, Never>("1234")
var password:String {
get { passwordPublisher.value }
set { passwordPublisher.value = newValue }
}
var confirmPassword:String {
get { confirmPasswordPublisher.value }
set { confirmPasswordPublisher.value = newValue }
}
var isPasswordValid:Bool {
password == confirmPassword && !password.isEmpty
}
}
class Coordinator {
var proposal:PasswordProposal
var subscription:Cancellable?
init() {
self.proposal = PasswordProposal()
self.subscription = self.proposal.passwordPublisher.sink { [weak self] _ in
print(self?.proposal.isPasswordValid ?? "")
}
}
// Simulate changing the password to trigger the publisher.
func changePassword() {
proposal.password = "7890"
}
}
// --------------------------------
var vc = Coordinator()
vc.changePassword()
As soon as changePassword() is called, the mutual exclusivity enforcement will throw an exception because the property password will attempt to be read from while it's currently being written to.
Note that if you change this example to use a separate backing storage property instead of the CurrentValueSubject it causes the same exception.
However, if you change PasswordProposal from being a struct to a class, then the exception is no longer thrown.
When I consider how I might use Combine in an existing codebase, as well as in SwiftUI, I see this type of pattern coming up in a lot of places. In the old delegate model, it's quite common for a delegate to query the sending object from within a delegate callback. In Swift 5, I now have to be very careful that none of those callbacks potentially read from the property that initiated the notification.
Have others come across this and, if so, how have you addressed it? Apple has routinely suggested that we should be using structs where it makes sense but perhaps an object that has published properties is one of those areas where it doesn't?
The password property is not the problem. It's actually the proposal property. If you add a didSet property observer to proposal, you'll see it's getting reset when you set password, then you access self?.proposal from within your sink while it's being mutated.
I doubt this is the behavior that you want, so it seems to me like the correct solution is to make PasswordProposal a class.
I'm writing a small macOS app, where I want to be able to watch a folder for changes. It doesn't need to watch subfolder, I only want to receive a notification if a file is added to the folder or removed.
It looks like NSFileCoordinator and/or NSFilePresenter could be used to achieve this, but I was not able to understand how to use them to achieve this.
Ideally this can be solved without having to include a third party framework.
You can do this using NSFilePresenter.
The observing class must conform to NSFilePresenter as shown below.
The presentedItemURL would point to the folder you want to observe.
If there is a change in the folder presentedSubitemDidChangeAtURL get called. The code snipped below could give you an idea how it can work.
class ObservingClass: NSObject, NSFilePresenter {
lazy var presentedItemOperationQueue = NSOperationQueue.mainQueue()
var presentedItemURL:NSURL?
func presentedSubitemDidChangeAtURL(url: NSURL) {
let pathExtension = url.pathExtension
if pathExtension == "png"{
refreshImages()
}
}
func refreshImages(){
let path = snapshotPath
var isDirectory: ObjCBool = ObjCBool(false)
if NSFileManager.defaultManager().fileExistsAtPath(path!, isDirectory: &isDirectory){
if isDirectory{
do {
let list = try NSFileManager.defaultManager().contentsOfDirectoryAtPath(path!) as Array<String>
for filePath in list {
if filePath.hasSuffix(".png"){
if let snapshot = snapshotAtPath(path! + "/" + filePath){
newSnapshotArray += [snapshot]
}
}
}
} catch {
// error handling
}
}
}
}
}
Best wishes.
Marc T's answer still works and seems to be the easiest solution for this.
To make it work I needed to add the following line (could be at the init() of ObservingClass):
NSFileCoordinator.addFilePresenter(self)
I've inherited some Swift 3 code which uses RxSwift to manage a store. The basic layout of the class is:
class UserActivityStore {
fileprivate lazy var internalDataCache: Variable<Set<NSUserActivity>?> = Variable(nil)
func addAction(_ actionToAdd: NSUserActivity) {
var content = internalDataCache.value ?? Set<NSUserActivity>()
content.insert(actionToAdd)
internalDataCache.value = content
}
func resolveAction(_ action: NSUserActivity) {
var content = internalDataCache.value
_ = content?.remove(action)
internalDataCache.value = content
}
func expectActions(_ filter: #escaping ((NSUserActivity) -> Bool)) -> Observable<NSUserActivity> {
let observable = Observable<NSUserActivity>.create { (observer) -> Disposable in
return self.internalDataCache.asObservable().subscribeNext { (newActions) in
guard let newActions = newActions else { return }
for eachAction in newActions where filter(eachAction) {
observer.onNext(eachAction)
self.resolveAction(eachAction)
}
}
}
return observable
}
}
When an action is added to this, it adds the item to the set correctly. However, the observer (in expectActions) catches that change and resolves it. Since this is all in a single thread, the error "Warning: Recursive call or synchronization error!" is triggered.
I think this is a perfectly legitimate error and that RxSwift is probably correct in its handling. However, I can't help thinking that this is a bad model. The code is essentially handling a queue of NSUserActivity objects itself.
Is this genuinely a modelling error / abuse of RxSwift or is my limited understanding of RxSwift misunderstanding this? As a hacky solution, I've tried replacing the resolveAction function with a single line internalDataCache.value?.remove(action) but that still triggers the observable and hence the bug.
Changing the observable to use a different queue (Serial or Concurrent dispatch) fixes the problem but I'm not convinced its the correct fix.
I came across this problem when testing my View:
In my ViewModel I call to an asynchronous operation and when the response arrives, I use a PublishSubject to produce a change in my View. In my View, I call DispatchQueue.main.async in order to hide or show a button.
ViewModel
let refreshButtons = PublishSubject<Bool>(true)
refreshButtons.onNext(true)
View
model.refreshButtons.asObservable()
.subscribe(onNext: {
[unowned self] success in
self.updateButtons(success)
})
.addDisposableTo(disposable)
private func updateButtons(_ show:Bool) {
DispatchQueue.main.async{
button.isHidden = !show
}
}
Now I don't know how to unit test that refreshButtons.onNext(true) will hide or show my button.
The solutions I can think of are:
Overriding the method and having an async expectation, but for that I need to make the method public, what I don't want, or
Dispatching the main queue in my ViewModel and not in the view, what it sounds odd to me, but might me ok.
How can I solve this?
Thank you in advance.
You could use an async expectation based on a predicate in your unit test to wait an see if the button is not hidden anymore.
func testButtonIsHidden() {
// Setup your objects
let view = ...
let viewModel = ...
// Define an NSPredicate to test your expectation
let predicate = NSPredicate(block: { input, _ in
guard let _view = input as? MyView else { return false }
return _view.button.isHidden == true
})
// Create an expectation that will periodically evaluate the predicate
// to decided whether it's fulfilled or not
_ = expectation(for: predicate, evaluatedWith: view, handler: .none)
// Call the method that should generate the behaviour you are expecting.
viewModel.methodThatShouldResultInButtonBeingHidden()
// Wait for the
waitForExpectationsWithTimeout(1) { error in
if let error = error {
XCTFail("waitForExpectationsWithTimeout errored: \(error)")
}
}
}
Something worth noting is that the value you pass to the NSPredicate should be a class. That is because classes are passed by reference, so value inside the predicate block will be the same as the one touched by your view model. If you were to pass a struct or enum though, which are passed by copy, the predicate block would receive a copy of the value as it is at the time of running the setup code, and it will always fail.
If instead you prefer to use UI tests as suggested by #Randall Wang in his answer, then this post might be useful for you: "How to test UI changes in Xcode 7". Full disclosure, I wrote that post.
First of all, You don't need test private method
If you want to test if the button is hidden or not,try UI testing
here is the WWDC of UI testing.
https://developer.apple.com/videos/play/wwdc2015/406/