I recently attended CocoaConf Atlanta 2013. It was an great conference with lots of great sessions and talks by really great and admirable people. If you're interested in looking through the slides from the sessions, they can be found here, CocoaConf Atlanta 2013 Slides.
There were, as I said before, a lot of really great sessions but there were two that really intrigued me as they introduced me to new concepts that I had not seen before. The sessions I'm referring to were "Exploring MVC-N" by Marcus Zarra and "Mobile APIs: More than just object.to_json" by Stuart Gleadow.
In Marcus' sessions on MVC-N he spoke about the idea of have a NetworkController class which is solely responsible for communicating with a remote API, parsing response data, and strong the response in CoreData (or the persistent store of your preference). Then, in your ViewController's, or anywhere else you'd need to pull data from the API you would instead just ask CoreData for the response data. Here is a visual representation of of how the MVC-N pattern works.
There are a couple reasons I find this concept intriguing. First of all I really like the idea of keeping all networking code out of your ViewController's. Yes, some would say, "They are controllers, so it's fine", but I disagree. I've always followed a similar patter to that of MVC-N where I would have a NetworkManager class that would be responsible for all communications with the API, parsing response data, and caching responses but I would still have to make calls into the NetworkManager from my ViewController's. With MVC-N, this is not necessary. My ViewControllers would only need to ask CoreData for the response data it's needs. I feel this is a far cleaner approach and promotes decoupling of your networking and ViewController classes.
In Stuarts session on mobile API's he talked about how, for the most part, companies/developers who expose a public API have tens or even hundreds of separate API calls that are all highly coupled. They work by having to pass around user keys or some other type of uniquely identifiable information so the API knows what to do for each user. They can also be very difficult to learn due to poor documentation. Take Twitter for example. Twitter has a massive API with many different access points. See for yourself here, https://dev.twitter.com/docs/api. This makes trying to learn this API extremely difficult. Also, considering the fact that API endpoints can change, having a client that has hardcoded API endpoints is cause for disaster. This is where Stuart introduced the concept of using a standardized JSON formatting, such as HAL-JSON, can be a life saver.
HAL-JSON is a some what new concept on JSON Hyperlinking in which returns a set of "_links" in every API response that can be used by the client to very quickly and easily determine what access points are available and should be used given their current state. Here is an image representing a HAL-JSON response with the "_links" object that has been returned in the response which tells the client where to go from here.
Both of these concepts have really great potential. I am very excited to have discovered them and I'm really looking forward to exploring them more in the future. I'll be sure to report my findings.
Overall CocoaConf was a great experience. I met some really great people and learned a lot. I'd highly recommend it to any/all developers, especially those looking to get into the mobile scene or have already started developing for mobile. I look forward to attending next year.
