Improve TableView Scroll by Moving code to willDisplayHeaderView - ios

Question

My tableview is not scrolling smoothly. I have seen this comment from apple.
But very important thing is still there: tableView:cellForRowAtIndexPath: method, which should be implemented in the dataSource of UITableView, called for each cell and should work fast. So you must return reused cell instance as quickly as possible.
Don’t perform data binding at this point, because there’s no cell on
screen yet. For this you can use
tableView:willDisplayCell:forRowAtIndexPath: method which can be
implemented in the delegate of UITableView. The method called exactly
before showing cell in UITableView’s bounds.
From Perfect smooth scrolling
So I am trying to implement all my code in viewForHeaderInSection to willDisplayHeaderView (Note, I am using sections rather than rows for this specific example because I have custom sections). However, I am getting a "fatal error: unexpectedly found nil while unwrapping an Optional value" error at
let cell = tableView.headerViewForSection(section) as! TableSectionHeader
Below are my original and attempted code that crashed
Original (Note, this code works fine with some minor scrolling lagging problem that I am trying to improve)
func tableView(tableView: UITableView, viewForHeaderInSection section: Int) -> UIView? {
if let cell = tableView.dequeueReusableHeaderFooterViewWithIdentifier("TableSectionHeader") as? TableSectionHeader {
// Cancel request of current cell if there is a request going on to prevent requesnt info from background from previous use of same cell
cell.AlamoFireRequest?.cancel()
var image: UIImage?
if let url = post.imageUrl {
image = DiscoverVC.imageCache.objectForKey(url) as? UIImage
}
cell.configureCell(post) // This is data binding part
cell.delegate = self
return cell
} else {
return TableSectionHeader()
}
}
func tableView(tableView: UITableView, willDisplayHeaderView view: UIView, forSection section: Int) {
}
Attempt
func tableView(tableView: UITableView, viewForHeaderInSection section: Int) -> UIView? {
if let cell = tableView.dequeueReusableHeaderFooterViewWithIdentifier("TableSectionHeader") as? TableSectionHeader {
return cell
} else {
return TableSectionHeader()
}
}
func tableView(tableView: UITableView, willDisplayHeaderView view: UIView, forSection section: Int) {
let cell = tableView.headerViewForSection(section) as! TableSectionHeader
// Cancel request of current cell if there is a request going on to prevent requesnt info from background from previous use of same cell
cell.AlamoFireRequest?.cancel()
var image: UIImage?
if let url = post.imageUrl {
image = DiscoverVC.imageCache.objectForKey(url) as? UIImage
}
cell.configureCell(post) // This is data binding part
cell.delegate = self
}
-----Update to address Michael's answer------
As there are word limits on replies, here is a response to the Answer from Michael
You are correct, I have updated where I got the snippet from in my questions. My mistake
I agree that problem could very well be lying else where, however this is something that I am going through at the moment. My tableview scrolls OK but sometimes when there is image it slows down a little. So I am going through some steps to ellimate any potential cause.
The reason that I specifically didnt use if let here is that becuase I was expecting the cell to be displayed will be TableSectionHeader. I tried to add it in just then and I ALWAYS gets a failed cast.
The reason that I subclass UITableViewHeaderFooterView is because my headerview is a Xib file where I have func configureCell() so I could call cell.configureCell. (And many other functions)
My header includes a few items like
labels to display title, date, time downloaded from firebase
image that can be optional
image description
like btn, commentbtn, more, btn
All of theses function are addressed in my TableSectionHeader.swift which inherits from UITableViewHeaderFooterView
Could you please explain what you mean by "It's looking suspiciously like you're trying to store state in the header - you should store state outside the tableView."?
Reason that I am cancelling Alamofire request here is because the cell gets dequeued. So if the user scrolls really fast, the cell would get many alamofire request. So I cancelled it first and re-open a download request (inside cell.configureCell) if I dont have anything in my cache
I am not sure how printing sections would help identify. I am thinking it is something foundamentally wrong that I am doing here putting everything in willDisplayHeaderView code (As most place you would put it in viewForHeaderInSection instead). Or maybe it is just the syntax

Answer 1

You're given the header view in the method, you just need to cast it. Try this:
func tableView(tableView: UITableView, willDisplayHeaderView view: UIView, forSection section: Int) {
guard let cell = view as? TableSectionHeader else { return }
cell.AlamoFireRequest?.cancel()
...
}

Answer 2

I don't think that comment comes from Apple, and I think your problem probably lies elsewhere (eg. blocking the main queue with a task that should run in the background). If you post the contents of TableSectionHeader, this may become clearer.
Pressing on regardless, you are getting a nil value exception in the following line:
let cell = tableView.headerViewForSection(section) as! TableSectionHeader
This is because you're forcing the cast as TableSectionHeader, and it undoubtedly isn't one. If you change it to an if let or guard let, you will see a different code path.
Since you obviously expect it to always be of that type (after all, that is what you're creating in viewForHeaderInSection), something is happening that you don't realise (why are you subclassing UITableViewHeaderFooterView anyway?). I'd be inclined to print the section number and view in both sections so you know what is really happening. It's looking suspiciously like you're trying to store state in the header - you should store state outside the tableView.
Also, there should be no need to cancel the Alamofire request, as this is not the cause of a performance problem - retrieving an image should just fire off another request. Otherwise while a user scrolls around, no images will be displayed because the requests will keep getting cancelled. They would have to leave the screen alone and wait for those images to load before scrolling elsewhere.