Most mobile applications today require interaction with data that is no longer local to the device. Applications access data from Facebook, Twitter, and any other number of disparate remote sources. Because of this, working with remote data is unavoidable and something that most developers encounter when creating mobile applications. Some of the challenges that arise when dealing with remote data are: How will you query the data? How will you update the data? How will you deal with complex relationships and cascading updates?
Almost all developers have experience working with local data. Databases, XML, and even flat text files have been used for years to store local data. Countless libraries exist to access and interact with these local data stores. So how do most developers access remote data stores? Web services. Because of the need to interact with web services many libraries have been written to assist mobile application developers. iOS developers specifically have quite a few libraries to choose from. ASIHTTPRequest, while no longer actively developed, provides support for interacting with REST-based web services that is greatly documented. AFNetworking is an open source library that is very light weight and is actively being developed. Also, many commercial backend storage providers like StackMob, Parse, and Cocoafish provide their own libraries for accessing your data through the web services that they expose. But what is it that all of these libraries have in common? Very little really other than the fact that they are all built on top of NSURLConnection. They also all provide little or no support for performing complex queries or complex updates to your data. So what if iOS developers had a way to access remote data with the same functionality that they use to access local data, like say, Core Data?
Core Data has become the standard way of interacting with local data stores in iOS for several years now. According to Apple, Core Data “provides generalized and automated solutions to common tasks associated with object-life cycle and object graph management, including persistence.” Previously Core Data in iOS was limited to the use of SQLite for the persistence of data. But in iOS 5 a little known abstract class named NSIncrementalStore was added to allow developers the ability to create their own persistent stores for use with Core Data.
What is great about an NSIncrementalStore implementation is that it allows for interaction of a persistent store remotely. This means that instead of an NSFetchRequest accessing a local SQLite database, it can run a method that does whatever you wish like making a web service request. This also means that while working with remote data and an NSIncrementalStore you also have access to all the same functionality you have become accustomed to using with Core Data. Predicates, undo management, cascading updates, data modeling with the designer, and thread confinement with concurrency are all supported. This is where the power of the NSIncrementalStore is actually seen. You can use the same API to access and manipulate remote data that you use with local data.
What is not so great about an NSIncrementalStore implementation is that it is not easy to develop. Even though iOS is in version 6 there is still very little information how to implement an NSIncrementalStore correctly. While there are only five required methods you must subclass, it is the logic and code performed in those five methods that make an implementation difficult. Your implementation will still have to probably query against web services to access remote data and your web server will still have to know how to handle requests appropriately.
Having said all this, developing your own NSIncrementalStore is probably overkill for most iOS applications. The time it would take to design, develop and test your implementation is probably much longer than the time it would take to develop your own data access layer using a simple library like AFNetworking. But one popular backend storage provider, StackMob, has already developed their own NSIncrementalStore implementation that is in production today with their web services. Having used StackMob I know that using Core Data with an NSIncrementalStore is a viable approach for interacting with remote data. With the Apple developer community that exists I don’t believe that it will be too long before this approach is more understood and common.
