-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add queue support and keypath support to ObserverSet #21
base: develop
Are you sure you want to change the base?
Conversation
self.entries = self.entries.filter{ $0.observer !== observer } | ||
} | ||
} | ||
private class ObserverSetEntryImpl<ObserverType: AnyObject, Parameters>: ObserverSetEntry<Parameters> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was going to name with ObserverSetEntry and have the above class called AnyObserverSetEntry, but naming it this way is more backwards compatible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we name this something like DefaultObserverSetEntry
instead? Impl
doesn't read very well in my opinion
|
||
- returns: An entry in the list of observers, which should be used later to remove the observer. | ||
*/ | ||
open func add(queue: DispatchQueue? = nil, _ callBack: @escaping (Parameters) -> Void) -> ObserverSetEntry<Parameters> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure about this but it makes sense that this shouldn't be @discardableResult to prompt the user to remember to remove the observer at some point. If they really want it to be always added then they can do _ = observerSet.add(...)
which I've had to do in some places in the Tesco App where we set up observers on app launch.
- returns: An entry in the list of observers, which can be used later to remove the observer. | ||
*/ | ||
@discardableResult | ||
open func add<ObserverType: AnyObject>(queue: DispatchQueue? = nil, _ lifeCycleObserver: ObserverType, _ callBack: @escaping (Parameters) -> Void) -> ObserverSetEntry<Parameters> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added this function for convenience when you want to use a closure but want to tie to the lifecycle of an object.
One use case is instead of this:
let someObserverSet = ObserverSet<Int>()
let someObserverSet = ObserverSet<String>()
class Foo {
private let observer1: Any
private let observer2: Any
init() {
// Use closures to ignore the parameters that are different
observer1 = someObserverSet.add { [weak self] _ in self?.update() }
observer2 = anotherObserverSet.add { [weak self] _ in self?.update() }
}
func update() {
}
deinit {
someObserverSet.remove(observer1)
someObserverSet.remove(observer2)
}
}
Just do this:
class Foo {
init() {
// Use closures to ignore the parameters that are different
someObserverSet.add(self) { [weak self] _ in self?.update() }
anotherObserverSet.add(self) { [weak self] _ in self?.update() }
}
func update() {
}
}
An alternative would be to allow observers that have no parameters for any ObserverSet that has a non void Parameters type, but that would remove some of the type safety.
class Foo {
init() {
// Use closures to ignore the parameters that are different
someObserverSet.add(self, Foo.update)
anotherObserverSet.add(self, Foo.update) // oops I meant to do Foo.bar which takes the parameter but there is no error because any () -> Void function can be used as a callback for any ObserverSet
}
func update() {
}
func bar(_: String) { }
}
*/ | ||
open func removeObserver<ObserverType: AnyObject>(_ observer: ObserverType) { | ||
synchronized { | ||
self.entries.removeAll(where: { ($0 as? ObserverSetEntryImpl<ObserverType, Parameters>)?.observer === observer }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I switched to removeAll(where:)
instead of filter because it reads better
- returns: An entry in the list of observers, which can be used later to remove the observer. | ||
*/ | ||
@discardableResult | ||
func add<ObserverType: AnyObject>(queue: DispatchQueue? = nil, _ observer: ObserverType, _ callBack: @escaping (ObserverType) -> () -> Void) -> ObserverSetEntry<Parameters> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't needed for the other adds as Swift seems to realise () -> Void
and (Void) -> Void
are the same thing
/** | ||
Removes an observer from the list. | ||
fileprivate func call(_ parameters: Parameters) { | ||
// overridden |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think its worth putting an assertionFailure
in here to indicate that it should be subclassed and overridden?
assertionFailure("Function should be overridden before being called")
if let observer = observer { | ||
let callBack = self.callBack(observer) | ||
if let queue = queue { | ||
queue.async { | ||
callBack(parameters) | ||
} | ||
} else { | ||
callBack(parameters) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very minor. But might be cleaner to guard around observer rather than have these nester if let
statements.
if let observer = observer { | |
let callBack = self.callBack(observer) | |
if let queue = queue { | |
queue.async { | |
callBack(parameters) | |
} | |
} else { | |
callBack(parameters) | |
} | |
} | |
guard let observer = observer else { return } | |
let callBack = self.callBack(observer) | |
if let queue = queue { | |
queue.async { | |
callBack(parameters) | |
} | |
} else { | |
callBack(parameters) | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Jon889. Sorry it's taken so long for someone to review this. It looks good from my perspective, just a couple of minor suggestions. Ive asked a couple of others to review as well before we merge.
} | ||
} | ||
|
||
fileprivate var isExpired: Bool { false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current swift version for this repo is 4.0 so these one line implicit returns wont work yet.
fileprivate var isExpired: Bool { false } | |
fileprivate var isExpired: Bool { return false } |
private let callBack: ObserverCallback | ||
private let queue: DispatchQueue? | ||
|
||
override var isExpired: Bool { observer == nil } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above
override var isExpired: Bool { observer == nil } | |
override var isExpired: Bool { return observer == nil } |
Hi @Jon889 , Your PR looks great. is there a chance to get the Unit Testing fixed? To fix the issue with Xcode 12, I updated the initializers of TestObserver with the code below that and this should resolve the issue. It might also help to migrate to Swift 5 in future. init(observee: TestObservee) {
observee.voidObservers.add(self, voidSent)
observee.stringObservers.add(self, stringChanged)
observee.twoStringObservers.add(self, twoStringChanged)
observee.intObservers.add(self, intChanged)
observee.intAndStringObservers.add(self, intAndStringChanged)
} |
We currently have some extension methods that add support for specifying the queue that callback is called, this integrates it more nicely and makes some other changes.
Also I changed the indentation to use tabs instead of spaces as it's more accessible.
I'll update the Example app if this is acceptable. We use it extensively in the Tesco App and after these changes all our Unit tests pass.