Contacts sync framework

[GoogleCodeExporter]

I propose we have a basic framework for a sync manager. An interface can be
made so that we can create sync managers for whatever services people want
to write. Google is obvious as they have a nice API with source code all
ready to go. Yahoo, Facebook, Myspace, whatever. If we do this right, we
should be able to have all of them available. 

For the first version it will be a "pick one" setup. Multi-source sync is a
whole project by itself. 

Original issue reported on code.google.com by ttab...@gmail.com on 26 Sep 2009 at 3:21

[GoogleCodeExporter]

Original comment by ttab...@gmail.com on 26 Sep 2009 at 3:25

• Added labels: Milestone-Release1.0, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

You very much want to be talking to the folks at funambol: 

https://android-client.forge.funambol.org/

Open source contacts sync using an open protocol.

Original comment by jes...@gmail.com on 26 Sep 2009 at 8:22

[GoogleCodeExporter]

Funambol development doesn't seem very active to me. It might be a good syncML
platform but so far it seems it syncs only contacts, nothing else. It's a 
starting
point but only if it can guarantee that features will be implemented in time, 
or it
could drag behind the AOA initiative. 

My own expectations for a proper, even more powerful open-source SyncML app 
would be:
* plugin API for two-way syncing with any type of online service (Yahoo 
Contacts,
ZoHo Contacts, Firefox Weave (for bookmarks) etc.)
* local backuping on SD, fail-proof online backuping (mail, FTP, etc.)

Original comment by rayner...@gmail.com on 29 Sep 2009 at 2:57

[GoogleCodeExporter]

I've been looking into getting an app made for this. We're working on porting 
Android
and as such there are ION, Hero and Tattoo ROMs floating about. I've already 
mapped a
large portion of Hero's databases regarding contacts and sign on details. I'm 
not
great at Java but am learning. Tell me what you need..

Original comment by enate...@gmail.com on 29 Sep 2009 at 11:54

[GoogleCodeExporter]

I'd go with jessev's comment to use Funambol.  The calendar, tasks and notes 
syncing
support can be added as all one would need is to find out where and how the
respective applications write and read the data.

Original comment by nolanhay...@gmail.com on 30 Sep 2009 at 1:40

[GoogleCodeExporter]

It would be nice to integrate something like WiSync timed APN-activation with 
the sync framework.
I explain: a backgrdound-daemon should deactivate APNs (and WiFi) most of the 
time (when the display is locked 
or turned off), and activate it at customized timeouts (5, 10, 15, 30, 60, 120 
minutes) for a customized time 
frame (1, 2, 3, 5, 10,15 minutes).
As soon as the connection is active, the sync should be started for all 
registered services.

A client (say: mail client, facebook client, twitter client, etc.) registers 
with the sync framework, and get notified 
(through intents, for example) or updated automatically when the connection is 
activated.

This saves a lot of battery, as all clients get updated when the connection is 
up, and don't try to connect at any 
time, draining battery.

Naturally, when the screen is turned on (and phone unlocked) the connection 
should be active.

I think this should be integrated in the sync daemon from the start, so 
developers can start writing sync-capable 
applications.

Original comment by Alex.Shu...@gmail.com on 1 Oct 2009 at 10:19

[GoogleCodeExporter]

Alex, that proposal is very powerful and customizable. While I do not believe 
that
many third party apps would work with AOA extensions and options from the start 
of
the proect until it proves itself a viable alternative, such solutions alone 
can save
a lot of battery and even traffic and allow apps to immediately use the 
available
network once it becomes available rather than have to set up short periods of 
refresh
for apps and have them drain the battery even further.

Original comment by rayner...@gmail.com on 1 Oct 2009 at 10:24

[GoogleCodeExporter]

I agree that we should go far beyond syncing the address book. This should go 
much
deeper. And the user should have the freedom to sync with whatever server he 
wants or
even setup his own one. As we're talking about very personal data that's 
essential.

* Notes - http://live.gnome.org/Snowy
* the calendar - http://rscds.sourceforge.net/
* photos - http://fdcl.sourceforge.net/
* contacts, mail, files, passwords, messages,..

This could even become a backup solution where you put all your personal data 
to a
server (encrypted, of course). Loosing your phone wouldn't be a big deal 
anymore. ;)

other noteworthy projects in that area are http://www.ifolder.com/ and
http://chandlerproject.org/

Original comment by weiler.m...@gmail.com on 2 Oct 2009 at 5:04

[GoogleCodeExporter]

I would very appreciate to be able to use open (standard) protocols like CalDAV 
for
calendar synchronization. Those solutions keep your privacy by allowing you to 
run
your own synchronization servers. This would be ideal for people with privacy
concerns against Google.

Original comment by ste...@endrullis.de on 3 Oct 2009 at 1:14

[GoogleCodeExporter]

My preference would be to establish a common XMPP Framework/API and then build 
a sync
manager on top of it. There is a lot of pent-up demand for such a first class
component … http://code.google.com/p/android/issues/detail?id=201

Original comment by scott.p....@gmail.com on 5 Oct 2009 at 8:56

[GoogleCodeExporter]

Would a strictly XMPP framework be usable when dealing with other sync services 
such
as (say) Facebook, Yahoo, etc. I think it woukld be great if the sync manager is
capable of recognizing multuple sync services, even multi-sync data with each
depending what data they can sync (Yahoo could sync contacts, Facebook could 
sync
photos and media, etc.). 

Original comment by rayner...@gmail.com on 5 Oct 2009 at 10:11

[GoogleCodeExporter]

Developers don't want to have to support custom code (formats, protocols, auth) 
for
each new service they want or need to sync with. It would be ideal if syncing 
with
these services was normalized somehow. The question then becomes where to 
perform
this normalization, on the client or in the cloud. If this happens on the 
client then
users will end up having to manage plug-ins for new services or the platform 
gets in
the business of choosing favorites. An XMPP gateway that supports normalization 
may
be beyond the scope of this project but it looks to me as the type of solution 
that
will get the most adoption.

Original comment by scott.p....@gmail.com on 5 Oct 2009 at 12:10

[GoogleCodeExporter]

This is a good question. Generally it boils down to what is easier to code - it 
is
easier to code and support an online cloud solution open-sourced and allowing
personal deployment on private servers, or it is easier to code native code
implementations. Thinking of it, I agree cloud solutions may be easier to 
create and
support, and as long as the protocol is open sources, it would allow different
platform to rival each other on features.

Original comment by rayner...@gmail.com on 5 Oct 2009 at 12:15

[GoogleCodeExporter]

Android 2.0, announced today, have implemened exactly this - sync framework with
credential storing support for multiple services, including third party 
services and
several accounts per service. Google pretty much upped the ante for this 
project to
cover. 

Original comment by rayner...@gmail.com on 27 Oct 2009 at 6:00

[GoogleCodeExporter]

Links to sync info:
http://developer.android.com/resources/samples/SampleSyncAdapter/index.html

With C2DM in 2.2, this can all be automatic and instant:
http://code.google.com/android/c2dm/index.html
e.g.:
http://code.google.com/p/jumpnote/

If you are keen to create links to a bunch of other things, writing an 
Android-OpenSync conduit would be a good solution:
http://www.opensync.org/

In terms of "freeing" data, it would be helpful to have synchronisation to 
standard servers such as CardDav:
http://code.google.com/p/android/issues/detail?id=7639
and CalDav
http://code.google.com/p/android/issues/detail?id=2361

Original comment by lunatick...@gmail.com on 30 Sep 2010 at 2:18

[GoogleCodeExporter]

did anything happen here in the last year?

Original comment by nilsjan...@gmail.com on 12 Jan 2011 at 11:44

[GoogleCodeExporter]

The project is pretty much dead now that Gapps are distributed separately 
anyway.

Original comment by rayner...@gmail.com on 12 Jan 2011 at 12:29