search

mutualmobile / VIPER-TODO

Example project architected using VIPER
MIT License
70 stars 15 forks source link

Lazy Loading Images Strategy #3

Open mathewaj opened 9 years ago

mathewaj commented 9 years ago

I'd be interested to hear how lazy loading images in a tableview would be approached in this architecture? I noticed cellForRowAtIndexPath is placed in the view class, does this mean one should:

  1. Keep a reference to the image URL or ID in the view model (violation of the rules?) This could then be passed back to the presenter, who could pass it to the interactor, who could pass it to the data manager, along with a completion block to display the image in the cell once it has been loaded?
  2. Keep an array of NSManagedObjects (presumably in the datastore) and pass back the indexPath.row, with a similar completion block as above?

Would be great to hear any thoughts.

sebastianwr commented 9 years ago

Honestly, I'd simple use the UIImageView category from https://github.com/AFNetworking/AFNetworking. This is clearly a violation of layer boundaries but it is nicely abstracted and if you really don't need any custom logic in between view and image endpoint, I'd say this one-liner is an efficient and appropriate solution.

Plus, it will only trigger when the image view is actually displayed which may not be the case for every image view in a 100 row table view. Why load all 100 images when some of them might not even be visible?

But to do it manually I'd suggest the following:

  1. Cell will be rendered with view model
  2. View asks presenter to put the image for URL xyz into some image view
  3. Presenter asks Interactor with completion block to get the image
  4. Interactor does whatever necessary (perform a networking operation, load it from cache ...)
  5. Presenter receives image data from interactor and fills image view with it. Voilà!

Nothing official, just my 2 cents.

P.S. You don't get around to keeping a reference to the data model within the view model if you want to edit or reuse it (e.g. in a master-detail view). Lots of information is getting lost from the database to the view, so you have to know where the data comes from. Either you have a view model for more than one screen as a compromise (which sucks IMHO) or you keep an ID reference which is a slight layer violation but still quite elegant.