Currently, Mugshot automatically downloads at least two sizes for every single photo that a user try to view: a thumbnail, and a square version. I say “at least”, because although it does not currently download any larger sizes by default, it soon will. (I’m adding some features - that you can disable if you want - that will require larger sizes.) Because of the way Mugshot caches these image sizes to disk, attempting to download anything besides just Thumbnail and Square will bring your internet connection to a halt.

The current caching implementation in Mugshot is what I call the “shotgun approach”. When you click on an item, Mugshot asks Flickr for a list of photos in that collection - whether you click on a contact (”get me a list of all the photos in that contact’s photostream”), a photoset (”get me a list of all the photos in that set”), a group (”get me a list of all the photos in that group’s pool”), etc. Once Mugshot has that list of photos, it converts that photo data into CoreData objects. For every single “Photo” object in CoreData, if Mugshot doesn’t see cached files on disk, it creates a special handler and tells it to cache files for that photo in a new thread. Mugshot hands off control to that other thread, and then effectively forgets about it. While this is happening, Mugshot will show you the “Loading…” graphic for each photo. Here are the problems with this approach:

• Mugshot kicks off these threads one at a time, without really caring or tracking how many it has kicked off. Although this has the benefit of requiring very little code, it also makes it difficult for Mugshot to provide status information - how many photos have been downloaded? How many left to go?
• Thread storm! Although having multiple threads keeps things responsive, remember that Mugshot will kick off a thread for every photo. So if you click on your photostream, and you have 800 photos, Mugshot will eventually have 600 or 700 threads - all trying to download several small images. Although the main app remains responsive, trying to load thumbnails for this many photos is counterproductive - and in extreme cases, the downloads time out, resulting in empty files, which Mugshot isn’t smart enough to deal with.
• Let’s say that you clicked on a photoset, took a quick look, realized the photo you want is in another set, so you click on another. Mugshot can’t stop the original 100 threads from loading, so it doesn’t - it just kicks off more in order to show you the new thumbnails. Although Mugshot is technically still responsive (i.e. no spinning beach ball), it will take a long time to start showing you the new thumbnails because the original set are still tying up your internet connection.
• The bigger the files, the worse all of these problems become. For example, I am adding features that will require caching the “Small” and possibly the “Medium” photo sizes from Flickr. Each of these is, on average, about twice the size of the next smallest image. (i.e. “Medium” is, on average, twice as large as a “Small”, which is about twice the size of a “Thumbnail”). The code that caches these files plays a few tricks to try and load these larger sizes later - trying to make sure that thumbnails get loaded ASAP so the user can see them. But, given the other drawbacks above, these tricks fall apart pretty quickly.

So what does this all mean? Well, first it means that the simple, “shotgun approach” code made it easy for me to get Mugshot up and running quickly. It also means that under small loads and fast internet connections (less than 300 photos in a set, and using a cable modem), Mugshot usually responds very well - I could put off writing a better caching system until another day. It also means that “another day” is here.

Based on some of the drawbacks above, and based on how I’m seeing people use Mugshot, I started designing the new caching system by writing down the rules and guidelines it should follow:

1. Mugshot should always know - and be able to tell the user - exactly how many photos it has cached from the current view, and how many photos it still has left to go. As a corollary, it should attempt to cache photos that are directly in view (as opposed to outside the scroll area) first.
2. Mugshot should always try to show users thumbnail and square versions first. These are the first images used in the UI and are most critical to a smooth, responsive look and feel.
3. When the user navigates to another set of photos before the current set has been cached, the new set should take priority. Again, following the above rule that Thumbnails and Squares are the most important sizes.
4. Larger sizes are always lowest priority. (Which larger sizes to download is controlled by other features in Mugshot and whether they’re in use - this will continue to be the case.)
5. The new system should never start caching a lower priority photo (determined by the above rules) if a higher priority item exists. (i.e. Mugshot should never start caching a thumbnail for a photo the user isn’t currently viewing while a thumbnail needs to be downloaded for a photo that’s currently in view).

The theme of all these rules is that Mugshot should put responsiveness and usability FIRST. I’ve spent most of today re-designing the caching system to follow these rules. It uses NSURLDownload and preferences control how many concurrent downloads it will attempt. I use this same code for caching and downloading in several areas of the app, so these updates should provide a lot of useful speedups. Also, using NSURLDownload means I can probably have a more responsive system without creating (and trying to coordinate) multiple threads.

What do you think? Are the “rules” reasonable? Have you tried Mugshot? Is there something I’m missing?