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&gt; 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

For JS, there isn't really anything except for maybe leveraging indexedDB upgrades, but IndexedDB isn't supported everywhere. Once Object.observe comes in, then we are closer to comparing objects super easy JS is very much DIY at this point On Mar 3, 2014, at 10:17 AM, Summers Pittman <supittma(a)redhat.com&gt; 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev