Tableview with Searchcontroller - Deinit Not Called

TableView with SearchController - DEINIT not called

Deleted my old answer, found the problem.

Remove:

definesPresentationContext = true // Remove this line...

Read about it here:

https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIViewController_Class/#//apple_ref/occ/instp/UIViewController/definesPresentationContext


There must a bug in UISearchController. Some Apple code must be retaining your controller.

Maybe the transition view (animation) is not completed when the controller is unlinked (it has special toView and fromView etc, that we can not reach), and this prevents the controller from being deallocated.

I think you should file this as a bug with Apple.


Also I would recommend changing your deinit to:

deinit {
print("TBVC Dealloc")
if let superView = searchController.view.superview
{
superView.removeFromSuperview()
}
}

This will ensure the search controller is never trying to present stuff when getting deallocated, as this creates warnings and potential unexpected behavior.

Swift iOS SearchController not Being Called in ViewDidLoad

Try to move these two lines to the end of viewDidLoad. Your table view is coming from the storyboard as IBOutlet, meaning they are ready before viewDidLoad, calling the method tableFooterView on tableview triggers the method tableView:cellForRowAtIndexPath. Since your self.searchController is not setup at this point yet, you will get nil and crash. Moving these two lines at the end ensures that operation for table view starts after your data source is available (in this case, it's the searchController).

let backgroundColor = UIView(frame: CGRectZero)
self.tableView.tableFooterView = backgroundColor

Alternatively, you can check for nil in self.searchController.searchBar.selectedScopeButtonIndex, return 0 in numberOfRowsInSection if true, this will avoid the crash. When you call self.tableView.reloadData() it will trigger numberOfRowsInSection again, and this time self.searchController.searchBar.selectedScopeButtonIndex should be ready, not nil.

explanation for deinit not called

The usual reason for failure to trigger deinit when expected is that you have a retain cycle that prevents your view controller from going out of existence.

(Sometimes the reason is that your expectation that the view controller would be destroyed under the circumstances is incorrect. But assuming it is correct, a retain cycle is the reason.)

You mentioned removing all observers. What kind of observers? If we're talking about NSNotification, that is often how you get a retain cycle. The notification center retains the observer until you unregister it. You thus cannot get deinit until after the observer has been removed. Therefore, you cannot remove the observer in deinit.

Strange scrolling behaviour of tableView with searchController

Maybe a couple things to try:

  • I remember setting the layout constraints to the Superview instead of the Safe Area help with my tableView's scrolling when the ViewController was embedded in a Navigation Controller.

  • Also adding this property to the ViewController might help if the first doesn't:

    extendedLayoutIncludesOpaqueBars = true

Should deinit be called in UITableViewCell?

Since tableview cells are reused, they tend to be only deinited if the tableview itself is deinited. Because even if they are not used right now, the tableview would keep them alive in case they are needed for reuse.

UISearchController search bar appears but not working/triggering

Finally i was able to solve this problem with some change in view hierarchy thanks to @Tj3n , but not sure if this is the correct solution but right now its working ..
I also had to remove this line and add few more codes for other purpose

self.definesPresentationContext = YES; //removed...

also answer of that questions was helpful

UISwitch deinit never called

This is (finally) fixed in iOS 10.2



Related Topics



Leave a reply



Submit