3

When data is updated in database, I post a notification to NotificationCenter from client with new data. A ViewController will be observing this notification so UI can be updated accordingly.
Will the app crash if view controller observes a new notification and tries to update UI, while its not the present View Controller on screen?
or will the function that observes notification wait until view controller is presented to execute?

XsiSecOfficial
  • 954
  • 8
  • 20

3 Answers3

5

If your notifications are only meaningful when your view controller is on-screen then you should listen in viewWillAppear and stop listening in viewWillDisappear.

The alternative is to listen for notifications in viewDidLoad and stop listening in dealloc (Objective-C) or deinit (Swift). If you do that your view controller will receive the specified notifications the whole time it's alive, regardless of whether it's visible on screen or not.

If you continue listening to notifications when your view controller is not front-most then you won't crash, but you will probably make updates that aren't visible, possibly making your app less responsive.

Alternately, you can use the notifications to update your view controller's model (data store) and make the code smart enough to track when the view controller is visible, and only do UI updates when it is visible.

EDIT:

Note that if you register for a notification in viewDidLoad, and your app runs in iOS >= 9, you don't need to unregister for the notification in deinit/ dealloc. The OS now handles unregistering an object for notifications when it gets deallocated.

Community
  • 1
  • 1
Duncan C
  • 128,072
  • 22
  • 173
  • 272
  • since you mentioned it yourself, how is it with that cleaning up observers in `deinit`? I already tried to ask about it https://stackoverflow.com/questions/47741859/is-cleaning-up-strong-references-in-deinit-a-correct-pattern – Milan Nosáľ Jan 17 '18 at 23:03
0

Usually you add obeservers in viewDidLoad/viewWillAppear and remove them in viewDidDisappear / deinit to avoid carshes such as listening to keyboard notifications

Also try to refresh any viewController's content in viewDidAppear

Note: the app will crash if a view Controller observes and deallocated before removing the observes either in viewDidDisappear or deinit methods

---- no wait will happen either there is an observer or not

Shehata Gamal
  • 98,760
  • 8
  • 65
  • 87
0

New ‘swifty’ way to setup observers is to use completion blocks instead of selectors ‘addObserver(forName:object:queue:using:)’, so you can save observation token to optional var, array or dictinary, when you had to observe notification and nullify (remove from collection) latter to stop observation. In this case ‘obsrever’ will automatically stop observetion while deallocating, and it safer to not subscribe multiple time for same notification.

MichaelV
  • 1,231
  • 8
  • 10
  • Actually, you're conflating 2 different things. As you say, there is a new method `addObserver(forName:object:queue:using:)` that takes a queue and a closure, and returns a reference to the resulting object. I just tested it, and you DO still need to remove such an observer when the object that creates it gets deallocated. The selector-based way for adding observers, `addObserver(_:selector:name:object:)`, you don't have to remove the selector in iOS >= 9.0 when your object gets deallocated. – Duncan C Jan 18 '18 at 00:45
  • Observer depends on returned object. Destruction of this token is actually removing observer. No closure will be called if **token** dealocated. Another *benefit* - there is no limitation to support obj-c, declare obj-c selector etc. – MichaelV Jan 18 '18 at 12:26
  • "Destruction of this token is actually removing observer." That is not correct. You can add an observer with ‘addObserver(forName:object:queue:using:)’ and ignore the returned token and the observer persists. That method requires that you explicitly call `removeObserver()` or the observer persists indefinitely (until app termination.) – Duncan C Jan 18 '18 at 16:47