Check the GitHub project for this article.
A notification is sent by prepareForReuse method of the custom cell(JKCallbacksTableViewCell class) to the table(RootViewController class) which is observed by the tableViewCellIsPreparingForReuse method. This method resets the association key and the imageview of the cell.
So, why does author preferred to send it through a notification instead of resetting them after getting a non-nil cell from dequeueReusableCellWithIdentifier method of the table?
According to the documentation of UITableViewCell, prepareForReuse is called just before dequeueReusableCellWithIdentifier.
If a UITableViewCell object is reusable—that is, it has a reuse identifier—this method is invoked just before the object is returned from the UITableView method dequeueReusableCellWithIdentifier:.
I have tested it that when dequeueReusableCellWithIdentifier returns a non-nill value it’s coupled with a call to prepareForReuse.
Author commented in the JKCallbacksTableViewCell.h about application logic separation but i think that is a kind of overkill; optimizing performance with async dispatch but sending those slow notifications to reset some properties… Or am i missing something about GCD?
Most programming problems have a near-infinite number of solutions. I didn’t have any particular reason to choose notifications other than the fact that they’re loosely coupled.
Regarding your comment about the speed of the notification: the thing that makes the app slow is loading the images, so we’re trying to optimize that. Notifications aren’t slow enough to make a difference in the use of the app otherwise, so to use something else for pure performance reasons is unwarranted here.
That said, it’s in GitHub, so feel free to send a pull request that doesn’t use notifications. If I like it better, I’ll use it.