Best way to Cache JSON from API in SWIFT?

AruLNadhaN picture AruLNadhaN · Aug 27, 2015 · Viewed 22.5k times · Source

I need to cache json data from API in swift. So I researched a Lot & get to this Post.

I tried to implement the Option 1 in my App. But the Custom manager always returned nil. I don't know why?

After that I got AwesomeCache. It says that it an do Awesome API Caching. But I don't know how to implement this? I referred this Issue. Still I can't figure it Out.

This is how my Current implementation Looks without Cache:

Alamofire.request(.GET, "http://api.androidhive.info/volley/person_array.json")

    .responseJSON { (_, _, data, _) in
        let json = JSON(data!)
        let catCount = json.count
        for index in 0...catCount-1 {
            let name = json[index]["name"].string
            println(name)
         }

Please suggest me the Best way to Cache JSON from API ?

Thanks in Advance!

UPDATE

These are my requirements

  1. Fetch the JSON from the API & Parse the JSON data. These can be done with the help of Alamofire & SwiftyJSON

  2. I will populate the parsed data in the Table View. It works when the user is in Online.

But I want to show the data in the Table when the user is in offline too.

So I need to save the Parsed data or the JSON data in my cache & I need to refresh or expire the cache within a week or days.

I don't prefer to store the JSON in my disk because it will be updated.

Please suggest me the Best way to achieve this...

Answer

cnoon picture cnoon · Aug 27, 2015

You have many tools already at your disposal.

NSURLCache

All your requests are already stored in the NSURLCache in the NSURLSessionConfiguration on the NSURLSession stored inside the sharedInstance of the Alamofire Manager. Those stored requests already follow all the caching policy rules provided by the servers you are hitting. You can control the caching behavior by setting the requestCachePolicy on your own custom NSURLSessionConfiguration. I'd also suggest you read through this awesome NSHipster article that walks you through the ins and outs of NSURLCache and how to control it.

Creating custom Manager objects is covered in the current Alamofire docs.

Downloading JSON to Disk

You can also download the JSON directly to disk using Alamofire.download instead of using Alamofire.request. This will download the payload to a fileURL that you provide in the destination closure. This would give you full control over the caching of the file after that point. You would need to create your own caching policy around these files afterwards if you wanted to follow the caching header rules provided by the server.

Populating Table View

Once you have your data downloaded to disk, you need to load it into an NSData blob and parse it into JSON to populate your table view. This should be pretty straight forward. You need the destination NSURL that you specified to Alamofire when you started your download. Then load the file data into an NSData blob. Finally, use NSJSONSerialization to convert the NSData object into a JSON AnyObject which can be parsed into model objects to populate your table view.

Obviously you don't "have" to parse the JSON into model objects, but this helps protect your table view from malformed JSON data.

Storing JSON for Offline Usage

If you stick with this approach, you'll need to track your cache expiration dates in something like CoreData or SQLite. You can do this by either caching the paths to the JSON files on disk, or store the model objects directly in CoreData or SQLite. This could get fairly complicated and I would not recommend this approach unless you absolutely don't want to cache your model objects.

Offline Usage

Generally, if you need to cache data for offline usage, you want to store your model objects in something like CoreData. You would use the Alamofire request method coupled with a responseJSON serializer to parse the data into JSON. Then you would convert the JSON into model objects. From there, you'd save your model objects in CoreData, then finally populate your table view with the model objects.

The nice thing about this approach is that you have all your model objects cached in the case that your table view is accessed when the device is offline. Coupling this design with queries to your NSURLCache to see if your request is cached let's you avoid unnecessary server calls and parsing logic when you already have your model objects generated.

Given the updates to your original question, I would recommend this approach.