Friday
10Oct2008
Exposure 1.1 post-mortem
Friday, October 10, 2008 at 06:49AM
[Preamble: if you don't have Exposure, here are App Store links to Exposure (free) and Exposure Premium ($9.99)]
Exposure 1.1 is now available on the App Store. This is the first serious feature update for Exposure, and it includes a ton of work under the hood which is succinctly summarised in the release notes as:
Exposure started life as a prototype desktop application (hereinafter referred to as "the desktop app") . I restarted the iPhone development from scratch and didn't use any code from the desktop app for 1.0. In Exposure 1.0, I was worried about falling foul of Apple's instruction that iPhone apps should not be "bandwidth hogs", so I took a very conservative approach to network traffic: one request at a time and no preloading.
With some more experience under my belt, I realised that the crushing problem with wireless networking (whether EDGE or 3G) was latency, not bandwidth per se. Doing "one request at a time", particularly for small objects like Flickr's 75px thumbnails, means that you pay the high time-cost of latency once for every object you load.
In Exposure 1.1, I ported the image downloading code from the desktop app to the phone. This code provides multiple queues, a priority scheduler and highly parallel downloading. Exposure 1.1 now runs 15 thumbnail requests in parallel, so you pay the latency cost once and then start to see several images load.
Caching
Exposure 1.1 caches thumbnails in an SQLite database on the phone. I originally wrote a filesystem-based image cache which worked, but had a few pathological code paths. The worst offender was the time it took to calculate the current size of the cache, for which I had to walk the file hierarchy and sum the size of each file. After hearing Dr. Richard Hipp's talk on SQLite at C4 it was clear what I had to do. I ripped out the filesystem cache and, with some help and code from Ian Baird, I had a faster and more elegant cache in far fewer lines of code in just a couple of days.
Near Me
Near Me now has a lot more control over the results of the search. In Exposure 1.0, the results were taken from a five mile radius and sorted by ascending distance from your location. This was usually OK, but produced some bad results in situations where a lot of uninteresting pictures were taken near your location. The canonical example is if you were in a restaurant or pub district of a city. In such an area, you would find a lot of photos of people you didn't know at parties appearing at the top of the search and pushing more interesting photos down the list.
In Exposure 1.1, you firstly have control over the search radius, from 1 mile up to 20 miles. This helps in situations where you're in a place that's either very densely-tagged (where you might want to narrow the radius) or sparsely-tagged (where a radius wider than 5 miles might get you something). Exposure 1.1 also lets you use distance, interestingness or date as the field to sort on. For interestingness and date, you can choose ascending or descending sort. The Flickr API only returns ascending distance, so sort direction is ignored if you're sorting on distance.
My favourite arrangement is a search radius of 2-3 miles, sorted by descending interestingess (i.e. most interesting first). In areas that you frequent a lot, you might want to choose descending-date sorting to show you the newest photos near your house. Lots of good options.
Finally, I should say that distances are now localised to the unit of measurement in use in your locale. I will further apologise to my fellow Brits that iPhone OS thinks we use metres and kilometres for distance. Distances are currently only displayed in the row view and not the thumbnail view.
Interface
There were a number of changes to the interface in Exposure 1.1. Most obvious amongst them is that Exposure now shows thumbnails in a 4-column grid instead of the single-image rows that 1.0 had. The 1.0 interface is still there, and can be selected in the new Settings view. It's not obvious but, if you double tap a thumbnail, you'll go to the info view instead of the full-screen view.
Onwards!
Not every feature made it into Exposure 1.1. In particular, uploading isn't there yet. I decided to play it safe with this release and just do two or three highly disruptive code changes instead of four or five. I also didn't want to delay getting the new downloader and cache into the hands of users. Performance is a feature, and I think that this new version makes using Exposure a significantly more pleasant experience.
Exposure 1.1 is now available on the App Store. This is the first serious feature update for Exposure, and it includes a ton of work under the hood which is succinctly summarised in the release notes as:
Thumbnails now load much faster.
Exposure started life as a prototype desktop application (hereinafter referred to as "the desktop app") . I restarted the iPhone development from scratch and didn't use any code from the desktop app for 1.0. In Exposure 1.0, I was worried about falling foul of Apple's instruction that iPhone apps should not be "bandwidth hogs", so I took a very conservative approach to network traffic: one request at a time and no preloading.
With some more experience under my belt, I realised that the crushing problem with wireless networking (whether EDGE or 3G) was latency, not bandwidth per se. Doing "one request at a time", particularly for small objects like Flickr's 75px thumbnails, means that you pay the high time-cost of latency once for every object you load.
In Exposure 1.1, I ported the image downloading code from the desktop app to the phone. This code provides multiple queues, a priority scheduler and highly parallel downloading. Exposure 1.1 now runs 15 thumbnail requests in parallel, so you pay the latency cost once and then start to see several images load.
Caching
Exposure 1.1 caches thumbnails in an SQLite database on the phone. I originally wrote a filesystem-based image cache which worked, but had a few pathological code paths. The worst offender was the time it took to calculate the current size of the cache, for which I had to walk the file hierarchy and sum the size of each file. After hearing Dr. Richard Hipp's talk on SQLite at C4 it was clear what I had to do. I ripped out the filesystem cache and, with some help and code from Ian Baird, I had a faster and more elegant cache in far fewer lines of code in just a couple of days.
Near Me
Near Me now has a lot more control over the results of the search. In Exposure 1.0, the results were taken from a five mile radius and sorted by ascending distance from your location. This was usually OK, but produced some bad results in situations where a lot of uninteresting pictures were taken near your location. The canonical example is if you were in a restaurant or pub district of a city. In such an area, you would find a lot of photos of people you didn't know at parties appearing at the top of the search and pushing more interesting photos down the list.
In Exposure 1.1, you firstly have control over the search radius, from 1 mile up to 20 miles. This helps in situations where you're in a place that's either very densely-tagged (where you might want to narrow the radius) or sparsely-tagged (where a radius wider than 5 miles might get you something). Exposure 1.1 also lets you use distance, interestingness or date as the field to sort on. For interestingness and date, you can choose ascending or descending sort. The Flickr API only returns ascending distance, so sort direction is ignored if you're sorting on distance.
My favourite arrangement is a search radius of 2-3 miles, sorted by descending interestingess (i.e. most interesting first). In areas that you frequent a lot, you might want to choose descending-date sorting to show you the newest photos near your house. Lots of good options.
Finally, I should say that distances are now localised to the unit of measurement in use in your locale. I will further apologise to my fellow Brits that iPhone OS thinks we use metres and kilometres for distance. Distances are currently only displayed in the row view and not the thumbnail view.
Interface
There were a number of changes to the interface in Exposure 1.1. Most obvious amongst them is that Exposure now shows thumbnails in a 4-column grid instead of the single-image rows that 1.0 had. The 1.0 interface is still there, and can be selected in the new Settings view. It's not obvious but, if you double tap a thumbnail, you'll go to the info view instead of the full-screen view.
Onwards!
Not every feature made it into Exposure 1.1. In particular, uploading isn't there yet. I decided to play it safe with this release and just do two or three highly disruptive code changes instead of four or five. I also didn't want to delay getting the new downloader and cache into the hands of users. Performance is a feature, and I think that this new version makes using Exposure a significantly more pleasant experience.
Reader Comments (10)
Fair enough. Thanks for the update!
Is there any way to display groups that you're a part of? I've never looked at Flickr's API, so I don't know if that's even possible, but that's one feature that would really make it for me!
When we developed the Style.com app we first built a complex NSURLConnection loading queue for thumbnails and such, since as you say, we wanted to be careful not to overwhelm the iPhone with thumbnail requests. It was slow, and we noticed that it was making a new HTTP request to the server for each thumbnail instead of using keepalive.
So we mulled around for a bit and thought, you know, Apple probably designed the loading system expecting the average programmer to just lazily make requests without a second thought instead of making a complex queuing system, since this is a very common situation.
So we rewrote it to just make ALL the (visible) thumbnail requests simultaneously - i.e. creating dozens of NSURLConnections and letting them work their magic. Turns out the system queues them and executes them in parallel to the tune of about 4 (IIRC) at a time. And lo, the loading was much much faster.
Really fantastic improvements; I really shied away from using 1.0 because I'm not regularly on WiFi and it just took too long. The preloading and SQLite caching definitely fixes that right up!
I am curious – would you be able to implement a Commenting system similar to the new Facebook 2.0? I just went through and tried out adding a comment to a contact's photo – it worked fine, but it seems like there's perhaps an additional step or two that you could eliminate. I love how Facebook's item comments are basically a click away, and the "text bubble" idea just feels so natural for it too.
Thanks for all your work, Fraser!
Are you achieving parallel downloads by spinning off new threads for NSURLConnection? I was under the impression that multiple NSURLConnections could load data in parallel. Is that not true? I'm trying to solve a similar problem.
@Nick Thanks for the insights.
@Steven Peterson I'm starting the NSURLConnections on the main thread and relying on NSURLConnection's asynchronous mode to parallelize them for me. I'm not spawning one thread per connection (at least not by hand).
I really like the improvements you've made with 1.1.
One additional feature I'd like to see is the ability to load more photos for Contacts, Featured and Near Me. Is there a reason it's there for My Photos, but not for the others?
@Bret No technical reason that I can remember right now, just a matter of priorities.
This reminds me of a classic networking rant from Stuart Cheshire: "It's the Latency, Stupid"
http://rescomp.stanford.edu/~cheshire/rants/Latency.html
One thing that annoys me about Mobile Fotos is that when you upload a photo and tell it to include your current location, it's actually where you are at the point of /upload/, not where the photo itself was taken. If you're in a moving vehicle, the difference between where the photo was taken and where you are at that point can be very large!
If/when you add photo uploading, if it's possible to just include the geotagging data from the photo itself rather than the "Current location", that would be excellent. :)