Android app database syncing with remote database
1) Looks like this is pretty good way to manage your local & remote changes + support offline work. I don't think this is overkill
2) I think, you should cache user's changes locally with local timestamp until synchronizing is finished. Then server should manage all processing: track current version, commit and rollback update attempts. Less processing on client = better for you!  (Easier to support and implement)
3) I'd choose polling if I want to support offline-mode, because in offline you can't keep your socket open and you will have to reopen it every time when Internet connection is restored. 
PS: Looks like this is VEEERYY OLD question... LOL
I'm in the planning phase of an Android app which synchronizes to a web app.  The web side will be written in Python with probably Django or Pyramid while the Android app will be straightforward java.  My goal is to have the Android app work while there is no data connection, excluding the social/web aspects of the application.
This will be a run-of-the-mill app so I want to stick to something that can be installed easily through one click in the market and not require a separate download like CloudDB for Android.
I haven't found any databases that support this functionality so I will write it myself.  One caveat with writing the sync logic is there will be some shared data between users that multiple users will be able to write to.  This is a solo project so I thought I'd through this up here to see if I'm totally off-base.

The app will process local saves to the local sqlite database and then send messages to a service which will attempt to synchronize these changes to the remote database.  
The sync service will alternate between checking for messages for the local app, i.e. changes to shared data by other users, and writing the local changes to the remote server. 
All data will have a timestamp for tracking changes
When writing from the app to the server, if the server has newer information, the user will be warned about the conflict and prompted to overwrite what the server has or abandon the local changes.  If the server has not been updated since the app last read the data, process the update.
When data comes from the server to the app, if the server has newer data overwrite the local data otherwise discard it as it will be handled in the next go around by the app updating the server.

Here's some questions:
1) Does this sound like overkill?  Is there an easier way to handle this?
2) Where should this processing take place?  On the client or the server?  I'm thinking the advantage of the client is less processing on the server but if it's on the server, this makes it easier to implement other clients.
3) How should I handle the updates from the server?  Incremental polling or comet/websocket?  One thing to keep in mind is that I would prefer to go with a minimal installation on Webfaction to begin with as this is the startup.
Once these problems are tackled I do plan on contributing the solution to the geek community.