How to fix cell reusability issue using MVVM pattern? - ios

Question

I am trying to implement MVVM pattern without 3-d party libraries for data binding.
I have a UICollectionView with a StoriesViewModel.
StoriesViewModel is a class which holds an array of models.
To each cell I assign a respective ViewModel which I create in a cellForItemAt method, like this:
func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
let cell = collectionView.dequeueReusableCell(withReuseIdentifier: Constants.storiesCollectionViewCell, for: indexPath) as! StoriesCollectionViewCell
let story = viewModel.getStory(for: indexPath)
let storiesCellViewModel = StoriesCellViewModel(story: story)
cell.viewModel = storiesCellViewModel
cell.setup()
return cell
}
Cells are dequeueReusable and images are being reused, which I can't fix with simple line imageView.image = nil at the start of cellForItemAt method, which worked for me previously when I used MVC. I guess it's something with assigning viewModels to cells.
Cell code (without views and constraints):
class StoriesCollectionViewCell: UICollectionViewCell {
//
var viewModel: StoriesCellViewModel?
override init(frame: CGRect) {
super.init(frame: frame)
commonInit()
}
required init?(coder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
private func commonInit() {
//
setupViews()
}
private func setupViews() {
//
}
func setup() {
storyImageView.image = nil
viewModel?.fetchImageData(completion: { (imageData) in
DispatchQueue.main.async {
self.storyImageView.image = UIImage(data: imageData)
}
})
titleLabel.text = viewModel?.title
authorLabel.text = viewModel?.author
brandNameLabel.text = viewModel?.brandName
}
}
I also tried viewModel = nil in prepareForReuse method, and it didn't work. Is that a common problem in approaching MVVM pattern and what is the way to fix it? Thanks in advance.

Answer 1

What I suspect is going on is that by the time the image is loaded to be displayed in your cell, the cell itself might have already been dequeued to be reused for another row of the collection view.
This is a common issue that can occur when you're using reusable cells.
One way to solve this might be to add a check when the image data is finally loaded, to make sure you're still dealing with the same cell as before (i.e.: still configured with the same view model that initiated the image load).
Maybe you can use an unique identifier for each view model to do this:
viewModel?.fetchImageData(completion: { (imageData) in
DispatchQueue.main.async {
// Check here if it still makes sense to attribute this image to this cell
self.storyImageView.image = UIImage(data: imageData)
}
})

Answer 2

In general you shouldn't store specific image in a non-specific cell, i.e.; a reusable cell.
Because by the time your async fetch returns, that cell may already be reused to display another image.
The usual approach is to create a separate cache, which is updated by async fetch, followed by a table view reload in which indexPath.row is used as array index to access the cache.
This is pretty straight-forward in Apple MVC.
So the problem now is how to implement it in MVVM.
I'd say there's no benefit to using view model for reusable cells. You are just making things difficult for yourself.
But no one dares to challenge MVVM these days, it seems. Devs always blame themselves for not fully grasping the power of MVVM. No, challenge it. MVVM does not magically solve everything.
That being said, I'll attempt answering your question.
self.storyImageView.image = UIImage(data: imageData)
You store a specific image in a non-specific reusable (variable) cell.
If you call fetch in cell view model, then it needs a callback to pass that image to view controller which then triggers a table view reload. You should avoid capturing cell references and make run-time condition checks. The safest bet is to prepare data and trigger SDK to do the rest.
In fact, I would argue that view model is about updating view whenever model changes. But this requires proper binding, which is lacking in UIKit. So all these efforts are just so that you can do networking which produces side effects in callback and indirectly trigger a view update.
You may verify this by not calling fetch in cell view model. Then your view model becomes useless. MVVM becomes MVC with extra steps. There's no point passing a view model to setup cell properties when those properties are public and meant to be setup in cellForRow: by SDK design.