Mike Ash had a great post on Swift back in June – Friday Q&A 2014-06-20: Interesting Swift Features. It’s worth a read. Really helped me wrap my head around some new (to me) concepts in Swift like Optionals and Generics. While your there be sure to check out the rest of his site. All of his Friday Q&A’s are great.
Over the past week or two I’ve found myself thinking about blogging but not actually taking the time to write anything. It’s not that I don’t care, but that I don’t care enough to get it through the blogjam of a system I currently have. If I want to post anything I currently have to do so from my Mac.
The process goes something like this:
- Copy an old post
- Edit the post (usually in TextMate)
- Check my use of markdown (I’m still a novice when it comes to markdown syntax, but I do like it)
- Save and Commit
- Ask myself why I don’t have a better solution
It’s not that this is really bad, but it takes time, thought and care. I have to be at my Mac for one thing. That’s a huge barrier considering most of the time I think about writing is when I’m away from my Mac. When I’m at my Mac I’d rather be programming. I’ve tried a few GitHub iPhone apps but most either are broken (won’t sync correctly) or lack simple text editing features. What I really want is a simple markdown editor with spell checking that will sync with GitHub and that has Mac, iPad, and iPhone versions. If I find that great, but I’m increasingly starting to think I might have to build it myself.
Many Cocoa developers haven’t worked a lot with web services. But these days if your working on an iPhone app it’s highly likely you’re touching a network, either to access a full API or maybe just fetch some images to populate a table view. When fetching data from a web service one of the first thoughts early on is (or at least should be) about performance. Caching is a great way to get big performance gains, not only in speed but also in reduced battery consumption and decreased network usage. So, naturally you might think you should some form of cache controller class maybe using NSCache for in memory and perhaps a SQL database for persistent storage. But don’t be to quick to chisel that wheel out of the stone.
Luckily if your using NSURLSession (and you really should be) you’re likely getting this for free and you don’t even realize it. NSURLSession by default uses a shared NSURLCache (each app gets it’s own) to cache responses. This means when you make a request for something like some JSON or an image the response is cached (in memory and / or to disk). So the cache will be used for any requests you make to the same URL later. Well, technically the cache may be used. It depends on the http cache control headers set in the response. So it’s important to understand what cache control headers are set for your end point and how they can affect when / how long your cache is valid for. See HTTP Header Field Definitions for more info on this.
On a final note. You should validate you’re cache. I don’t mean in some kind of checksum sense. I mean just verifying that it’s actually performing as expected. The NSURLCache uses a SQL database that lives in /Library/Caches/. You should take a look at that cache and verify that your intended responses are being cached. Depending on your response sizes and how much data you want to cache you may need to setup a larger cache than the default shared cache.
MacTech was my favorite magazine back in the 90’s. In the dark ages before the web we had to use paper books, magazines, and stone tablets to learn things. Every time I opened a new issue of MacTech I got a chance to learn a little more about Mac development. Turns out MacTech has an awesome article archive! Take a trip down memory lane and enjoy some great Mac development articles of yesteryear.