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?

blareweyrΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

49 εμφανίσεις

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, w
orking 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 re
lationships 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 da
ta 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 libra
ries to choose from. ASIHTTPRequest
,
while no longer actively developed,

provides support
for interacting with REST
-
based web services
that
is greatly documented
.
AF
Networking

is an open source library that is very light weight and is
actively
being deve
loped.
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 lit
tle 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 th
e same functionality tha
t 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 sol
utions 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 know
n

abstract
class named NSInc
rementalStore 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 do
es

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 a
ll the
same functionality you have become accustomed to using with Core Data
.

P
redicates, 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 ver
sion 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
,

d
eveloping your own NSIncrementalStore is probably ove
rkill 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 ba
ckend storage provider, StackMob, has already developed their own
NSIncrementalStore implementation that is in production today with their web services.
Having
used
StackMob
I know t
hat using Core Data with an NSIncrementalStore is a viable approach for
i
nteracting

with remote data. W
ith the
Apple
developer community that exists I don’t believe that it will be t
oo
long before this approach is

more

understood and common.