Oftentimes we request JSON data from the server, deserialise it into network model objects and then wonder where we can keep ahold of this data. We wish to put it somewhere handy in our architecture so that we don’t have to repeat the effort of hitting the server again for the same data in the future.

It’s not always obvious where we can put these objects to make them available between unrelated screens - they can’t necessarily be neatly passed around. There are many approaches to solving this architectural problem, and we could go as far as rolling our own data store (BlahDataManager), or even cramming what we get back from the network into Core Data - occasionally the correct call but usually a vast over-complication.

Whatever we choose, we’ll likely arrive at the following solution, with two separate APIs to query for each set of data that we might need:

Step 1: query our local data store (whatever it is) to see if we already have the data we need, or

Step 2: hit the network to retrieve the data.

This could be wrapped in a single public interface to hide this fiddliness, but what I wanted to show is that - for GET queries at least - there is already a Foundation API for doing this rather neatly: URLCache.

Background

In a client app I worked on recently, there was a situation where the server-side data we needed was scattered over many endpoints (there was an existing API, designed originally for a website, and it wasn’t adjustable for our purposes), and data had to be pieced together from different places, and at different times. Unfortunately the response times from the server were also rather lengthy, and the need to make multiple requests each time we needed certain data was resulting in a poor user experience.

It became pragmatic for the responses to be cached somewhere, but we wanted - for most endpoints, and in the MVP at least - to avoid the extra complexity of maintaining our own local model store representation of the server data, as this would need to be kept in sync across subsequent updates.

What would be nice is if we could skip that and just blithely make all queries for data to our Transport layer every time we needed it, without worrying about how frequently we do this, whether that query has already been fetched before, or how many requests are being made. The idea is that if we could cache at the network layer instead, we could get the benefit of using a single API, still have very quick data accesses, and not have to worry about having to store the result.

This use-case would not apply equally well to all apps out there, but for this app it was particularly suitable, as it was just a bunch of screens displaying fairly static data that only changed predictably and infrequently, yet which each an outsized number of calls to be made.

(NS)URLCache

Using URLCache allowed us to make our network requests efficiently repeatable and, for our simple use-cases, allowed us to completely sidestep the responsibility of implementing our own data storage in the Application layer.

It works like this:

If the data has never been retrieved before, the request will hit the server as normal & retrieve the data, and then asynchronously return the response.

If the data has previously been retrieved (and is still cached), it will be immediately (asynchronously) returned to us.

As the caller of this API, we don’t actually care about which path is executed - and the data is returned to us in the same way each time. This made it pretty fast to repeatedly traverse the various endpoints over which user and application data was scattered, without actually hitting the network more than necessary.

Configuration

URLCache is simply a component of the networking stack in Foundation which we can configure to suit this usage. We used URLCache with in-memory storage only (as disk storage is persisted across app launches, which we didn’t want). This should ideally be configured on app startup:

That’s it! All that’s needed now is to configure your URLRequest with the appropriate cache policy. useProtocolCachePolicy is the default (which is the most respectful of the cache-related HTTP headers), but returnCacheDataElseLoad is what we will want to use for all our appropriate endpoints, as described below.

Note: Somewhat unintuitively, despite providing your cache policy as returnCacheDataElseLoad, URLRequest remains free to disregard your caching preference if the response contains HTTP headers indicating that stuff should not be cached (Cache-Control: no-cache). In our case, this was arbitrarily turned on for every single request (even for completely static shared data), and we wanted to work around it - I’ll write about how to do this in a follow-up post.

To clear a response from the cache (for example, because a user has triggered a UIRefreshControl), you just provide an appropriate request that matches up to (i.e. has the same characteristics - it doesn’t need to be exactly the same object) the response you wish to clear:

URLCache.shared.removeCachedResponse(for: fetchRequest)

Limitations

Naturally this approach has its limitations:

we must manually clear the cache (per-endpoint) if we wish to receive newer data.

if we fire the same request simultaneously (e.g. from two different parts of the code), two network requests for the same data will still be made (due to the race condition of neither having completed yet - i.e. there’s no cache hit).

the cache sits prior to deserialisation, so on each access there is some wasted effort deserialising the same JSON over and over again. In practise I have found this not to be a noticeable issue - the usual advice of not prematurely optimising applies here, but it’s something to be aware of.

the lack of a sophisticated persistence layer (such as Realm or Core Data) means that clearing the cache and refreshing the data does not automatically propagate this change across the app (to other screens, for example). Clearing the cache means that subsequent refreshes will now receive the latest response, but this is not automatically pushed across the app.

In summary, this approach is not suitable for every use case, but for many simple screens that are just showing basic data this can be a nice idea to keep in mind.

Prior to adopting this, when I was using only MVVM, there was always the question of who was responsible for navigating between the screens - who makes the overarching decisions regarding what to do next? The implementation of which would float awkwardly somewhere between the ViewController (VC) having the presentation of the next screen hard-coded (which hurt reusability), or the ViewModel (VM) somehow nudging the VC and whispering "now go to the success screen" or whatever into it's ear. This really polluted the concept of "single responsibility" for both of these components.

It was also never super clear who should create the VM to be injected in to the VC either. The way I had been doing it, the ViewModel of the previous screen would create and configure a "Child View Model" to be injected into the ViewController that was being presented.. which was a bit messy, and unfortunately coupled the two screens together.

Enter stage: Coordinator 🎺

What the Coordinator pattern adds to this mix is the role of an overseeing "Coordinator" object (duh), responsible for a particular flow of your app, e.g. The Signup Flow.

It owns a canvas (a NavigationController, for example) onto which it can present ViewControllers as it wishes and, like a puppet master, sits high and mighty above the VC+VM layer pushing and pulling and popping screens into place, and responding to the output to decide what to do next. It is therefore the Coordinator's job to create both the VC and the VM, and to configure them as necessary.

Peeling away this responsibility from both the VC and the ViewModel really helps towards reaching the aims of the "Single Responsibility" principle.

 In my opinion, the key benefits of MVVM boil down to the following: - Separating the view model from the user interface makes it easier to test presentation logic.- Separating the view controller from the presentation logic makes it easier to test the user interface.

Separating the VM and the VC from the responsiblity of managing navigation makes their actual roles in the architecture clearer and more specific. The implementation becomes dumber and reusability improves. Awareness of flow between screens (i.e. how you got to this screen and where to go next) is completly delegated upwards to the Coordinator - making everything simpler.

--

One last thing to add is that if you allow the VC to communicate with Blah VM only through a BlahViewModelType protocol, you are then free to inject the VC with different implementations of the BlahViewModelType for different purposes, making the VC still further reusable. For example, the MapViewController in Tacks is currently used in three different situations (once full-screen and twice as a child VC on other screens), simply by changing the underlying ViewModel to adjust what is shown.

Note that the closure we to reduce is called once for every value of the array.

The zero that we pass in as a parameter is called the accumulator, that is: the starting value upon which successive calls of reduce function will be applied, effectively accumulating our final result. Actually, given that we're using value types and 0 is immutable, we will not be mutating the zero - we're really passing the return value from the first call (i.e. 0 + 1 = 1 - a new value) back in as the starting value (accumulator) of the next call.

We will see at the end that we can also use a mutable object as the accumulator and literally build up our object with each successive pass - which is sometimes useful for working with Cocoa.

Creating An Array from an Array:

The output of reduce can really be anything - even another Array. As a second example, let's use reduce to create a handy deduplication function which we can add as an extension on Array type.

The first thing to decide is what our starting value for this shall be. Our algorithm will be as follows: "start with an empty array and append each item, so long as that item isn't already present in the array". By this logic we shall finish with an array of distinct unique values.

Thus, we should start with an empty array of type <Element> (the Generic placeholder for the type of value the array can hold): [Element]():

Whoa whoa, slow down:

extension Array where Element: Equatable - we should constrain this extension to be available only when the Array holds values that are equatable. Otherwise, how could we identify duplicates?

func deduplicate() -> [Element]{ - we're returning an Array of the elements of the same type that the starting array holds.

reduce([Element]()) { (accumulation: [Element], find: Element) -> [Element] in - [Element]() is what we start with - an empty array. This is the Accumulator that we'll be using. The signature of the closure we're passing to reduce has the accumulation that we're building up accumulation: [Element], and find: Element, the current element that we want to find.

guard accumulation.indexOf(find) == nil else {return accumulation} - if the element we wish to find is already in the accumulation, then exit early from this iteration, returning an unchanged accumulation value. This is the escense of deduplication.

We can, naturally, use a reduce function to acheive this. However, the API for building up NSAttributedStrings, is quite suited to using an NSMutableAttributedString and applying successive attributes and String values on it.

It's easy to tweak our reduce function to, instead of returning a new value each time, instead return a mutated version of the passed in accumulator, so this same object will be passed into each iteration and then will be the result by the end:

This post gives some good relief - you just pipe a script straight from the 'net straight to sh (🙃) - , allowing Xcode to now recognise all my plugins properly (which were actually working in the Xcode app, but apparently not at the command line) but it revealed that one plugin was broken, the excellent FuzzyAutocomplete:

I'll be honest - I did have real problems getting back to grips with ReactiveCocoa 3.0 since their API overhaul (despite being reasonably familiar with v2 - I even gave a talk on it). I'm getting there now (tacks.cc is written extensively with ReactiveCocoa 3.0 RC), and I'll try to update this post with tidbits from what I've learned because, to-date - even though the RAC codebase is well documented, function to function - there's not enough examples out there for how you actually use this stuff as a whole. Most of the example code that exists is still in Objective-C and generally relates to previous versions of RAC. There are some great blog posts (linked at the bottom), which really helped me figure it out.

Creating a signal

We can create a "pipe" which returns a Tuple pair: the Signal itself, and an 'observer' which we can use to manually send events, - events which pop out of the created signal. They go together.

The Swift 2.0 compiler (Xcode 7 b6, at least) now makes a different decision about what we're trying to do. Due to the fact that we're passing a single block parameter, it now seems to assume that we want to call the start(sink: Event<T, E>.Sink) method instead. This is our clue that something's not right, as we start seeing that our blocks are being passed variables of type Event<YourType, NoError> rather than the expected type.

The solution is easy: either just be clearer about what you're calling by reinstating the next: parameter name:

producer.start(next: {value in ...})`

.. or provide more type information in your closure, to help the poor compiler out:

producer.start { (displayableAnnotations: YourType) in ... }

.Put

We no longer use .put(x) to set the value on a MutableProperty type - .value is now settable, so we just get and set .value directly. This is probably good, though I liked the separation before - it made it more obvious that MutableProperty also dealt in events. But like I say, it's probably simpler now.

Which would really mean (I assume because next was the last parameter?):

producer.start(next: {value in ...})

The Swift 2.0 compiler (Xcode 7 b6, at least) makes a different decision about what we're trying to do. Due to the fact that we're passing a single block parameter, it now assumes that we want to call the start(sink: Event<T, E>.Sink) method instead. This is our clue that something's not right, as we start seeing that our blocks are being passed variables of type Event<YourType, NoError> rather than the expected type.

The solution is easy: either just be clearer about what you're calling by reinstating the next: parameter name:

producer.start(next: {value in ...})`

.. or provide more type information in your closure, to help the poor compiler out:

producer.start { (displayableAnnotations: YourType) in ... }

.Put()

We no longer use .put(x) to set the value on a MutableProperty type - .value is now settable, so we just get and set .value directly. This is probably good, though I liked the separation before - it made it more obvious that MutableProperty also dealt in events. But like I say, it's probably simpler now.

Edit: Extra!

Don't forget to remove the Box dependancy as well, because it's no longer needed with Swift 2.0

I have GitHub repo and am talking to myself publicly via GitHub issues, the primary purpose is an exercise in what an "ideal project" for me would feel like (when I'm running the show), as well as being able to demonstrate what my work style (and coding prowess 😛) is like to anyone and everyone who might be interested (I am a freelance developer, after all). Perhaps someone else might want to join the project too.

Ok so I got this far without too many issues, so now to go back to my old favourite (or should that be nemesis?) ReactiveCocoa.

I abortively tried to begin learning Swift 2.0 with ReactiveCocoa 3.beta8 together from the get-go (because if it worked, that would be awesome right?): it didn't work because my Swift experience was too patchy, ReactiveCocoa 3 wasn't even finished and, particularly, wasn't ported to Swift 2 yet. (also I was still trying to get used to Xcode after three happy years using AppCode - which unfortunately is still lacking mature Swift support).

Now that the tears of frustration have dried, this time I'll go back somewhat less ambitiously (retreating to Swift 1.2 for my own sanity) and try ReactiveCocoa 3 again, it now being at RC1.

I've developed my ListViewController already with a ViewModel pattern, using callbacks (didChangeContent, didChangeSection etc) to notify the VC of FetchedResultsController changes. This is a perfect point to start and using Signals (or are they called SignalProducers now..?) instead.

And it wasn't too bad! I had a real mind-block on how on earth I might write tests for RAC, but inspiration actually came from reading how RAC itself is tested - they're very readable, I recommend taking a look.

I'm taking some time off to rearrange my 4+ years of Obj-C knowledge into a Swift-shaped skillset instead. Retooling. There's some other things I want to try too (CloudKit, rspec-style testing with Quick), so this is a good chance to check them out.

Before I take on my next project, I want to have built a canonical POC Swift app which contains many of the usual features of an app and utilises the following implementation features:

showing basic data (e.g. a List) in a TableView

data is persisted in Core Data

data is shown with a FetchedResultsController

data is editable

UITableViewCell containing a textField

MVVM used

Unit tests written with Quick & Nimble

Convert to Swift 2.0

Once it's converted to Swift 2, then:

Xcode 7 User Interface tests written (Swift 2)

The app will be my "best practise" reference going forward, and should basically stay up to date with my own experience.

Firstly, the version of LlamaKit that cocoapods installed wasn't compatible with Swift 1.2 (which RAC3.0 is currently targetted at).

I tried the manual install next, but it seems like there's a step missing. If you get some issues like "No such module Result" or "No such module Box", the solution is here - you have to add more than just ReactiveCocoa.xcodeproj. I filed an issue and the Readme is updated to explain this now.

Whilst reading @AshFurrow's excellent book on Functional Reactive Programming (do read it, it's an refreshingly different way of going about writing Obj-C), I was finding that I was required to copy/paste a lot of code snippets from the e-book into AppCode.

This is not a nice process: if you're reading it via the PDF, Preview.app doesn't correctly OCR the line spaces and what you paste into your IDE is a horribly mangled form of the code which won't compile and has to be tediously repaired. (it also unnecessarily copies the line numbers).

If you're reading via the Kindle app, that flat-out prevents you from copying any text at all from the book (fuck you, Amazon).

So that leaves the iBooks for OS X app, which does a great job at copying the text, but encases it in a citation block like so:

"let’s note that every Obj-C method is actually a C function with two additional parameters. The first one is self which is a pointer to the object being receiver of the method call. The second one is _cmd which represents the current selector."

Even as a fairly experienced Obj-c developer I did not realise this, (though had often wondered where _cmd came from in a method's scope - I assumed magic).
This was a good read, and something a bit different, too (though I didn't understand much when it dipped down into assembly).

I should paste this short script that I've written for converting an unordered list of films into a list ordered by the IMDB score (and also tagged with the genres). It worked great for tidying up the 350+ list of "you must see this" films that people have recommended to me through the years..

It will take an unordered list (with optional bracketted year to improve matching accuracy), e.g.:

The East (2013)
Shutter island
Stephen Fry: The Secret Life of the Manic Depressive
The Departed
Alan Partridge: Alpha Papa
Only God Forgives
You've got mail
Withnail & I
The Draughtsman's Contract
The Deal
Winter's Bone
A World Apart (1988)
We need to talk about Kevin

There's really not much sample code knocking around for iOS 7 custom transitions yet (or else Google is broken..): I guess that NDA is still only freshly lifted.

I've put together a simple example of how to present a new UIModalPresentationCustom-style Modal UIViewController with a UIViewControllerTransitioningDelegate managing the show. Have a play with this, it's simple enough to be self explanatory and useful for experimenting with - I hope it helps.