I'm toying around with a small Swift application. In it the user can create as many MainWindow instances as he wants by clicking on "New" in the application's menu.
The application delegate holds an array typed to MainWindowController. The windows are watched for the NSWindowWillCloseNotification in order to remove the controller from the MainWindowController array.
The question now is, if the removal of the observer is done correctly – I fear there might be a cyclic reference to observer, but I don't know how to test for that:
class ApplicationDelegate: NSObject, NSApplicationDelegate {
private let notificationCenter = NSNotificationCenter.defaultCenter()
private var mainWindowControllers = [MainWindowController]()
func newWindow() {
let mainWindowController = MainWindowController()
let window = mainWindowController.window
var observer: AnyObject?
observer = notificationCenter.addObserverForName(NSWindowWillCloseNotification,
object: window,
queue: nil) { (_) in
// remove the controller from self.mainWindowControllers
self.mainWindowControllers = self.mainWindowControllers.filter() {
$0 !== mainWindowController
}
// remove the observer for this mainWindowController.window
self.notificationCenter.removeObserver(observer!)
}
mainWindowControllers.append(mainWindowController)
}
}
In general you should always specify that self is unowned in blocks registered with NSNotificationCenter. This will keep the block from having a strong reference to self. You would do this with a capture list in front of the parameter list of your closure:
{ [unowned self] (_) in
// Block content
}
Related
I am building an iOS app using the new language Swift. Now it is an HTML5 app, that displays HTML content using the UIWebView. The app has local notifications, and what i want to do is trigger a specific javascript method in the UIWebView when the app enters foreground by clicking (touching) the local notification.
I have had a look at this question, but it does not seem to solve my problem. I have also come across this question which tells me about using UIApplicationState, which is good as that would help me know the the app enters foreground from a notification. But when the app resumes and how do i invoke a method in the viewController of the view that gets displayed when the app resumes?
What i would like to do is get an instance of my ViewController and set a property in it to true. Something as follows
class FirstViewController: UIViewController,UIWebViewDelegate {
var execute:Bool = false;
#IBOutlet var tasksView: UIWebView!
}
And in my AppDelegate i have the method
func applicationWillEnterForeground(application: UIApplication!) {
let viewController = self.window!.rootViewController;
let mainStoryboard: UIStoryboard = UIStoryboard(name: "Main", bundle: nil)
var setViewController = mainStoryboard.instantiateViewControllerWithIdentifier("FirstView") as FirstViewController
setViewController.execute = true;
}
so what i would like to do is when the app enters foreground again, i want to look at the execute variable and run the method as follows,
if execute{
tasksView.stringByEvaluatingJavaScriptFromString("document.getElementById('sample').click()");
}
Where should i put the code for the logic to trigger the javascript from the webview? would it be on viewDidLoad method, or one of the webView delegate methods? i have tried to put that code in the viewDidLoad method but the value of the boolean execute is set to its initial value and not the value set in the delegate when the app enters foreground.
If I want a view controller to be notified when the app is brought back to the foreground, I might just register for the UIApplication.willEnterForegroundNotification notification (bypassing the app delegate method entirely):
class ViewController: UIViewController {
private var observer: NSObjectProtocol?
override func viewDidLoad() {
super.viewDidLoad()
observer = NotificationCenter.default.addObserver(forName: UIApplication.willEnterForegroundNotification, object: nil, queue: .main) { [unowned self] notification in
// do whatever you want when the app is brought back to the foreground
}
}
deinit {
if let observer = observer {
NotificationCenter.default.removeObserver(observer)
}
}
}
Note, in the completion closure, I include [unowned self] to avoid strong reference cycle that prevents the view controller from being deallocated if you happen to reference self inside the block (which you presumably will need to do if you're going to be updating a class variable or do practically anything interesting).
Also note that I remove the observer even though a casual reading of the removeObserver documentation might lead one to conclude is unnecessary:
If your app targets iOS 9.0 and later or macOS 10.11 and later, you don't need to unregister an observer in its dealloc method.
But, when using this block-based rendition, you really do need to remove the notification center observer. As the documentation for addObserver(forName:object:queue:using:) says:
To unregister observations, you pass the object returned by this method to removeObserver(_:). You must invoke removeObserver(_:) or removeObserver(_:name:object:) before any object specified by addObserver(forName:object:queue:using:) is deallocated.
I like to use the Publisher initializer of NotificationCenter. Using that you can subscribe to any NSNotification using Combine.
import UIKit
import Combine
class MyFunkyViewController: UIViewController {
/// The cancel bag containing all the subscriptions.
private var cancelBag: Set<AnyCancellable> = []
override func viewDidLoad() {
super.viewDidLoad()
addSubscribers()
}
/// Adds all the subscribers.
private func addSubscribers() {
NotificationCenter
.Publisher(center: .default,
name: UIApplication.willEnterForegroundNotification)
.sink { [weak self] _ in
self?.doSomething()
}
.store(in: &cancelBag)
}
/// Called when entering foreground.
private func doSomething() {
print("Hello foreground!")
}
}
Add Below Code in ViewController
override func viewDidLoad() {
super.viewDidLoad()
let notificationCenter = NotificationCenter.default
notificationCenter.addObserver(self, selector:#selector(appMovedToForeground), name: UIApplication.willEnterForegroundNotification, object: nil)
}
#objc func appMovedToForeground() {
print("App moved to foreground!")
}
In Swift 3, it replaces and generates the following.
override func viewDidLoad() {
super.viewDidLoad()
foregroundNotification = NotificationCenter.default.addObserver(forName:
NSNotification.Name.UIApplicationWillEnterForeground, object: nil, queue: OperationQueue.main) {
[unowned self] notification in
// do whatever you want when the app is brought back to the foreground
}
I came across a tutorial from raywenderlich were the author gave some good tips on handling threading issues in singleton. But when using closures from within the singleton class he is using 'weak' reference cycle. Is it really required so since the class is a singleton, it should have a single instance always right?
final class PhotoManager {
private init() {}
static let shared = PhotoManager()
private var unsafePhotos: [Photo] = []
let concurrentPhotoQueue = DispatchQueue(label: "com.jeesson.googlypuff.photoQueue", attributes: .concurrent)
var photos: [Photo] {
var photoCopy:[Photo]!
concurrentPhotoQueue.sync {
photoCopy = self.unsafePhotos
}
return photoCopy
}
func addPhoto(_ photo: Photo) {
// Do we need 'weak self here.. and why?
concurrentPhotoQueue.async(flags: .barrier) {[weak self] in
// 1
guard let self = self else {
return
}
self.unsafePhotos.append(photo)
DispatchQueue.main.async { [weak self] in
//self?.postContentAddedNotification()
}
}
}
}
The tutorial
In case of DispatchQueue closures don't add any capture list at all, nowhere.
DispatchQueue closures don't cause retain cycles because self doesn't own them.
Basically capture lists inside a singleton object are not needed as the singleton is never going to be deallocated.
Some singleton's lifecycle is tied to App lifecycle. Some singleton's lifecycle is tied to login/logout.
So what if the singleton is to be deallocated upon logout? I think that's a valid case where using [weak self] can be useful, even for a singleton.
Otherwise just as vadian said, DispatchQueue closures don't cause retain cycles because self doesn't own them. For more see here
I have a class :
class myVC:UIViewController {
let myButton = MyButton()
func viewDidLoad()
{
view.addSubview(myButton)
myButton.addTarget(myMethodClosure) // ***
}
func myMethodClosure() // I guess this method captures self strongly when im using it as a closure, tell me if im wrong
{
self.doingStuffs()
}
}
My Button Class :
class MyButton:UIView {
var cbk:(()->Void)?
init()
{
// ...
addTapGestureRecognizer(#selector(onPress))
}
func addTarget(_ cbk:()->Void))
{
self.cbk = cbk
}
func onPress() {
// execute animation of the button
// ... and after it :
self.cbk?()
}
}
When I present myVC and then dismiss it after, the VC is not deallocated. I guess this is because myMethodClosure, taken like a closure (not a method) on line *** holds a strong reference on self (that is : myVC).
So it gets like :
rootview -> myVC -> myButton -> myMethodClosure(held in variable cbk)
^ |
| |
--------------------------
So as myVC has 2 references it does not get deallocated when rootview release its reference to it with rootview.dismiss()
My question is : when I pass the method as a closure line //***, how to say "I want to pass it like a closure, but holding a weak reference to self"
I tried this : myButton.addTarget([weak self] myMethodClosure) of course it didn't work...
As usual, it's simplest to see what's going on here by eliminating all the unnecessary dross. Here's a reduced version of what you're doing:
class MyVC:UIViewController {
let myButton = MyButton()
override func viewDidLoad() {
view.addSubview(myButton)
myButton.cbk = myMethodClosure
}
func myMethodClosure() {
print(self)
}
deinit {
print("deinit")
}
}
class MyButton:UIView {
var cbk:(()->Void)?
}
We can test that by saying
let what = MyVC()
what.loadViewIfNeeded()
At that point, what goes out of existence, but "deinit" is not printed. We've got a retain cycle. The MyVC instance has a strong reference to the MyButton instance thru myButton, but the MyButton instance has a strong reference to its cbk function which has a strong reference to the MyVC instance (because the function refers to self).
There are various ways to break the cycle, but if you want to do it at the level of the function, you need to express the function as an anonymous function so that you can take advantage of [weak self]:
myButton.cbk = { [weak self] in self?.myMethodClosure() }
There probably really isn't any really good reason why a function with a name (i.e. defined by func) can't have a capture list, but currently Swift has no provision for doing that.
What I have:
a NSManagedObject that sets a dynamic property to true when it's deleted from CoreData
override func prepareForDeletion() {
super.prepareForDeletion()
hasBeenDeleted = true
}
And within a view, I observe this NSManagedObject with the new Observe pattern of Swift 4
// I added this to observe the OBSERVED deletion to avoid a crash similar to:
// "User was deallocated while key value observers were still registered with it."
private var userDeletionObserver: NSKeyValueObservation?
private func observeUserDeletion() {
userDeletionObserver = user?.observe(\.hasBeenDeleted, changeHandler: { [weak self] (currentUser, _) in
if currentUser.hasBeenDeleted {
self?.removeUserObservers()
}
})
}
private func removeUserObservers() {
userDeletionObserver = nil
userObserver = nil
}
private var userObserver: NSKeyValueObservation?
private var user: CurrentUser? {
willSet {
// I remove all observers in willSet to also cover the case where we try to set user=nil, I think it's safer this way.
removeUserObservers()
}
didSet {
guard let user = user else { return }
// I start observing the NSManagedObject for Deletion
observeUserDeletion()
// I finally start observing the object property
userObserver = user.observe(\.settings, changeHandler: { [weak self] (currentUser, _) in
guard !currentUser.hasBeenDeleted else { return }
self?.updateUI()
})
}
}
So now, here come one observation and the question:
Observation: Even if I don't do the observeUserDeletion thing, the app seems to work and seems to be stable so maybe it's not necessary but as I had another crash related to the observe() pattern I try to be over careful.
Question details: Do I really need to care about the OBSERVED object becoming nil at any time while being observed or is the new Swift 4 observe pattern automatically removes the observers when the OBSERVED object is 'nilled'?
I have implemented KVO for the first time and in certain conditions, it is working and the observeValue is getting called correctly. However, I'm getting a crash when trying to remove the observer in deinit:
Cannot remove an observer
for
the key path "downloadInProgress" from
because it is not registered as an observer.
...although I did register the object in viewDidLoad.
// At the top of my file
dynamic var downloadInProgress: Bool = false
override func viewDidLoad() {
super.viewDidLoad()
self.addObserver(self, forKeyPath: #keyPath(downloadInProgress), options: [.old,.new], context: nil)
}
deinit {
// It crashes here
removeObserver(self, forKeyPath: #keyPath(downloadInProgress))
}
Basically if downloadInProgress = false, it crashes. What am I doing wrong? Thanks.
You wrote
// At the top of my file
dynamic var downloadInProgress: Bool = false
So it isn't part of an object? If so that might be the problem. KeyValueObserving is a technic from ObjectiveC. In Swift there are some limitations for it. One limitation is that it only works at classes that derive from NSObject. If it's a global var as I expect this isn't fulfilled.
Apple documentation:
You can use key-value observing with a Swift class, as long as the class inherits from the NSObject class
It should work if you have an object with kvo like that:
final class MyObject: NSObject {
dynamic var downloadInProgress: Bool = false
}
self.addObserver(self, forKeyPath: #keyPath(myobjectinstance.downloadInProgress), options: [.old,.new], context: nil)
Hint: Try to avoid KVO in future, because it's uncommon in swift.