3:39 a.m.
Hi Summers,
thanks for writing this up.
Had a dive on ContentProvider and SyncAdapter trying to understand the concepts and how
they work together. As you mentioned, ContentProvider helps on CRUD which can be backed
up by an SQLStore[1] (and can be extended to REST endpoint[2]) , which in turn provides
automatically notification for every interesting client (UI support for ContentProvider)
upon store updates. Further helps with caching, since records are served by the local
store if network is unavailable. I think this abstraction its very interesting.
Same goes with SyncAdapter where the user provides onPerformSync() and the system
automatically (or manually) can be scheduled to call it up. It doesn’t provide sync per
se, but a hook to user to plug in his algorithm. And works beautifully with
ContentProvider. And that’s clever.
In iOS, AFAIK these two abstractions do not exist, but I can imagine building them with a
combination of Core Data (backed by SQLStore) and an IncrementalStore[3] abstraction that
kicks in to fetch from remote REST endpoints and update local store. The system, as in
Android provides build-in support for UI components update when the underlying store
changes (using an NSFetchedResultsController).
For SyncAdapter, a combination of Local Notification, Background Fetch and Remote
Notification can be used to provide this functionality.
For ContentProvider if you rely on Core Data, I would say somehow ‘similar’ but need the
user to build upon existing techs.
For SyncAdapter, I imagine the end-result is calling sync() which again needs to be build
upon existing techs. The ‘sophistication’ of SyncAdapter when calling sync() (which relies
on network availability, app usage patterns), I imagine is encompassed on the effective
usage of techs mentioned earlier.
Short answer, not out of the box as in Android but can be build upon existing iOS
technologies.
Thanks,
Christos
[1]
https://github.com/bmeike/ProgrammingAndroid2Examples/blob/master/FinchVi...
[2]
https://github.com/bmeike/ProgrammingAndroid2Examples/blob/master/FinchFr...
[3]
https://developer.apple.com/library/ios/documentation/DataManagement/Conc...
On Mar 3, 2014, at 5:17 PM, Summers Pittman <supittma(a)redhat.com> wrote:
For the DevNexus Android app[1] I used Android native sync APIs[2] +
the
sync strawman[3] I put out back in December. It worked surprisingly
well with a few caveats.
First a background on how Android sync works.
Android sync is handled by three components: a SyncAdapter, a
ContentProvider, and a Authenticator.
The Sync Adapter performs as sync and returns a status object. The
SyncAdapter is called from, managed by, etc the Android platform. It
provides an onPerformSync that the developer implements. In the
application the developer sends signals to Android which control
scheduling sync (periodic, immediate, event based etc). Also Android
will put in the "Account" settings page a control for the SyncAdapter.
In this case the SQLSynchronizer I proposed was used to implement this
method.
The ContentProvider is responsible for CRUD operations on your data,
exposing your data to other apps on the device, and notifying the system
if data changes. This is managed by Android as well. In this case the
CP was backed by a SQLStore.
Finally the Android Authenticator is responsible for establishing and
maintaining authentication with remote services. If the user is not
signed in, or if fetching an auth token fails, the Authenticator will be
called by Android to provide a Activity which can be used to refresh the
users account. In this case I used two custom AuthenticationModules.
One handled SSO with Google and the other handled keeping the cookie up
to date. Both communicated with the DevNexus server to keep all of the
tokens fresh.
Overall, Android provides a very VERY slick (but very very complicated)
way of managing sync AND keeping the sync state visible to the user. If
you use Androids APIs then the OS handles things like Authentication
errors, intermittent connectivity, etc while providing configuration for
a variety of sync use cases (UI event based, polling, data listening, etc).
I tried looking up what options are available in JS land but the closest
I came to was a FFOS blurb about it is a TODO item and isn't a W3C
proposal or anything yet.
I tried looking at iOS but the docs made my eyes cross.
So what does the PLATFORM support look like in these environments?
----
[1]https://github.com/secondsun/devnexusAndroid
[2]http://developer.android.com/training/sync-adapters/index.html
[3]https://github.com/secondsun/aerogear-android/tree/sync_strawman/src/or...
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev