What is… Nuke?

This article gives a quick overview of Nuke, an open source Swift framework for loading, processing, caching, displaying, and preheating images. By Rui Peres.

Leave a rating/review
Save for later
Share
You are currently viewing page 2 of 2 of this article. Click here to view the first page.

6) Preheat Images

The most exciting feature in Nuke is probably the ability to preheat images.

If you’re an expert at preheating food but don’t know how to preheat images, here’s what it means: you make the image request at some time well before you need to display the image, download it and store it in the application’s network cache.

Preheat

Later when you need to display the image, the response to your request will come back from the cache instead of the network, which is much faster and more reliable than making a network request and hoping it will succeed and download in enough time before your user notices the delay.

Imagine you have have a screen that displays an article with an image at the bottom; you know there’s a good chance the user will eventually scroll down to see the image. With Nuke, you can preheat the image as soon as the user opens the article; as soon as she scrolls down the image will load so quickly as to give the impression it was there all along.

Here’s how you preheat an image with Nuke:

let articleImagesRequests = article.imagesRequests() // get the article's images requests
Nuke.startPreheatingImages(articleImagesRequests)    // start the oven

Stopping the operation is just as easy:

Nuke.stopPreheatingImages(articleImagesRequests)

The great thing about this approach is that explicit image requests are of a higher priority than preheating requests. Grebenyuk wrote a comprehensive explanation of this feature in the Nuke repo’s wiki.

Preheating and UICollectionView

Nuke also extends its preheating functionality to work seamlessly with UICollectionViews by way of ImagePreheatingControllerForCollectionView and the ImagePreheatingControllerDelegate protocol, which defines a single method:

func preheatingController(controller: ImagePreheatingController,
    didUpdateWithAddedIndexPaths addedIndexPaths: [NSIndexPath],
    removedIndexPaths: [NSIndexPath])

This delegate method passes in two important index path arrays:

  • addedIndexPaths: The index paths to preheat.
  • removedIndexPaths: The index paths to remove from preheating.

How does ImagePreheatingControllerForCollectionView know which index paths to start and stop preheating? Basically, it observes the UICollectionView‘s UIScrollView contentOffSet and figures out which cells are coming in and out of the view port, taking into consideration the scrolling direction and the device orientation.

If you want to use this feature with UITableView, you can use ImagePreheatingControllerForCollectionView‘s superclass ImagePreheatingController. This class observes UIScrollView directly, which UITableView subclasses. However, a little bird told me that full support for UITableView is coming soon! :]

To see a small demo of preheating in action, check out the example in Nuke’s repository here and the PreheatingDemoViewController.swift class.

not_bad

When Should You Use Nuke?

You should always ask the following two questions before you adopt a third party library:

  • Is it being maintained?
  • Does it do what it’s supposed to do?

You can answer the first question by checking the frequency of commits and if open issues are being dealt with in a timely fashion. In this case, I think Grebenyuk is doing an excellent job on both fronts! You can check the commit history and the issues list of the repo to see for yourself.

The second question isn’t trivial to answer; determining whether it’s true or false depends on your project. The easiest way is to start using the library see if it does exactly what it says on the tin. You can do this using Instruments and see how it behaves in different scenarios. In this case, Allocations, Time Profiler and Leaks would be your best bets. Once you’ve checked that it behaves as expected in your particular use case, you’re good to go.

In my day to day experience with Nuke, it’s worked as promised; as a standard image fetcher and cacher, Nuke does a flawless job.

Alternatives to Nuke

There are other interesting libraries out there that are comparable to Nuke; one of them is Kingfisher. Although Kingfisher is a perfectly valid option, the preheating feature offered by Nuke was something I really needed, so having it work out of the box made it an easy decision to use Nuke.

On the other hand, if you’re already using something like Alamofire, you could probably just use its companion library AlamofireImage for image handling. It’s difficult to justify the use of Nuke in this case, just for the sake of preheated images.

Why is this useful? If you’re already using Alamofire in your project and decide to leverage Nuke as well, this plugin passes the network tasks of image loading to Alamofire, while preserving Nuke’s caching, processing and decoding abilities. It’s the best of both worlds!

Note: Nuke does come with an optional plugin that provides Alamofire integration. This makes Alamofire.Manager comply with Nuke’s ImageDataLoading protocol; this means you can use either Nuke’s default image loader, or the Alamofire loader if you choose.

If you need more powerful image processing than Nuke can provide, you could make a combo with Alamofire and Path’s popular FastImageCache to solve your particular problem.

Where to Go From Here?

All in all, Nuke is a great library. Its advanced features and constant updates make it an easy choice for many projects. For more information check out the official Nuke Github repository.

If you have any questions or comments on Nuke, feel free to join the discussion below!

Note: Please let us know if you’d like to see more of these “WTF is…” articles in the future – this one is an experiment to see if you guys and gals like it.
Rui Peres

Contributors

Rui Peres

Author

Over 300 content creators. Join our team.