F-Stop version 5.0 introduces several changes. In this post I’m going to explain reasons and technical details behind some of these changes.
OSX 10.11 El Capitan requirement
This requirement wasn’t planned at the beginning of version 5.0 brainstorming but, during WWDC 2015, Apple announced something I was waiting since 3 years: a lot of improvements in NSCollectionView. With these improvements, NSCollectionView is able to display images in a more flexible way than the traditional IKImageBrowserView used by F-Stop since version 1. Unfortunately Apple has decided to do not back-port these improvements to NSCollectionView running on Yosemite and this is only reason why F-Stop version 5 requires OSX 10.11 El Capitan.
New graphical interface for Image Browser
IKImageBrowserView, a venerable component developed by Apple a lot of years ago, was the foundation of F-Stop image browser. At the time I started writing F-Stop, I had to do a choice between 2 components available: IKImageBrowserView and NSCollectionView. I went for IKImageBrowserView for 2 main reasons:
- Performance. IKImageBrowserView uses layers and it’s very fast in displaying a lot of images with beautiful animations
- Ability to display multiple groups of images
NSCollectionView was lacking support for multiple groups of images and I found it slower than IKImageBrowserView. But during these years I found a lot of limitations in IKImageBrowserView too:
- Customization: IKImageBrowserView is cell based. There is no way for IKImageBrowserView to use subviews to render images. Every image displayed has a fixed layout and there is a limited degree of customization in cell layout too.
- No custom layouts: IKImageBrowserView is able to display images in a grid and only in a grid.
- Bugs/Weird behaviours. Although IKImageBrowserView is layer based, I haven’t been able to draw additional layers consistently. I have tried for several months to add a video playback layer to a cell without any luck.
- No improvements for years: Apple has forgotten this component since its inception. No new methods, nor improvements to its deficiencies in years.
During the same years, thanks to its iOS counterpart (UICollectionView), NSCollectionView has gained a lot of focus. This year, during WWDC 2015, Apple announced some important improvements: Ability to display different groups of images within the same NSCollectionView and the possibility to use custom layouts. Time to ditch IKImageBrowserView…
Implementation of a new layout engine to emulate Flickr explore page hasn’t been easy and I have to credit this guy and its blog post for pointing me in the right direction. In addition, refactoring all F-Stop to use NSCollectionView was harder than I expected. Anyway… I did it and this is how F-Stop looks like now:
Is NSCollectionView perfect? Not yet. I have found some limitations such as a more complex way to deal with selections (keyboard and drag&drop). And I’m still looking for a way to solve some crashes when images are added using insertItemsAtIndexPaths: method. To avoid these crashes, F-Stop reloads images every time but animations are ugly. But I’m confident that Apple will solve these defects in the future because NSCollectionsView is (loud and clear today) the way to go.
There is another subtle graphical change I have introduced. Windows have a full size content view. In simpler words, F-Stop title bar appearance is like the one seen in Safari when colored content is scrolled (blurred behind the title bar).
Improved performance of Photo Downloader. Downloads are executed concurrently with a progress bar for each download
There are some improvements to Photo Downloader too. The main one is that photo downloads are now executed concurrently: this increase download performance for broadband users. For each download there is also a progress bar to monitor the process.
Another improvement is related to failed downloads: Photo Downloader used to silently discard failed downloads of photos. This is not anymore: now F-Stop adds an error to its error window (describing problem occurred) and the download can be restarted once the problem is fixed.
Improved upload performance with concurrent uploads
During last year, I have received several complains regarding upload speed. Some broadband users were reporting slow uploads. Having a slow internet connection, I had hard times to understand the issues. What I found is that Flickr upload api performs some post-processing operations before returning a photo identifier (another way to say: “upload completed”). These operations include photo validation and resizing and (probably) metadata synchronization in the cluster and takes something around 10-15 seconds per upload.
For broadband users, a 10 to 15 seconds delay represents a huge increase of upload time. For example, for a 2MB file that takes 2 seconds to upload, entire upload takes (in the worst case) 17 seconds. That is 8.5 times!! So I have decided to allow for concurrent uploads. Users can tune this value in F-Stop preferences from a minimum value of 1 (serialized uploads good for slow internet connections) to 10 concurrent uploads (fast internet connections).
It’s important to note that concurrent uploads may not respect upload ordering defined in F-Stop upload sidebar. This could also affect photostream ordering in Flickr because Flickr orders photos using their upload time (except for Camera roll).
Improved editing of tags when Photos View is displaying a selection
Metadata Editor in Photos View gives users the ability to change tags of a photo or a selection of photos. F-Stop versions before 5.0 managed the latter case in the wrong way: all tags of a selection were replaced with the new set of tags specified in metadata editor. Imagine the following scenario
Selection of 3 photos:
Photo A – Tags: A,B,C
Photo B – Tags: D,E,F
Photo C – Tags: G,H,I
Setting tags X,Y,Z in metadata editor lead to the following result:
Photo A – Tags: X,Y,Z
Photo B – Tags: X,Y,Z
Photo C – Tags: X,Y,Z
Now in F-Stop version 5, tags field of Metadata Editor displays (for the selection above) the following tags: A,B,C,D,E,F,G,H,I. User can add new tags and/or remove them. Adding X,Y,Z and removing E produces the following result:
Photo A – Tags: A,B,C,X,Y,Z
Photo B – Tags: D,F,X,Y,Z
Photo C – Tags: G,H,I,X,Y,Z
Removed support for Google Maps
Removed all deprecated methods of old releases of OSX including NSURLConnection
Every year Apple introduces so many changes to its platform that new deprecated methods are a fact life when an application is recompiled using the latest and the greatest developer tools. Compiler embedded in Xcode 7 emitted more that fifty deprecated methods warnings with F-Stop version 4.x… time for a definitive cleanup. Generally speaking, replacement of a deprecated method is easy: there is a new method to call. Nothing more, nothing less. But with OSX 10.11 El Capitan NSURLConnection is going to be deprecated and this is huge. Its replacement, named NSURLSession, is more efficient, more elegant, more sophisticated and in the most of cases very easy to be introduced as replacement for NSURLConnection. In most of cases apart one: synchronous connections. NSURLSession has no synchronous mode of operation: everything is managed asynchronously.
Unfortunately is not always easy to deal with an asynchronously logic. Especially if you have spent your last 5 years to use NSOperationQueue with synchronous operations to perform all your background tasks. A lot of people out of there argues that synchronous logic is evil. I disagree. Synchronous is the perfect fit for sequential operations if you can perform them in background. Synchronous sequential operations are easier to understand, easier to debug and, if there is a real reason to have them sequentially executed, performance difference is negligible in comparison to asynchronous operations.
In any case F-Stop uses now NSURLSession everywhere but it costed me a lot of headaches. I hope Apple will reintroduce Synchronous methods to NSURLSession.