Develop Reference

Syncing offine data with server?

This may be duplicate question but am still having doubt am a beginner in android application i have a couple of doubts my primary doubt is:
I have made one application which will communicate with server when network available it will work as it is. when network is not available data will save in sqlite and later when network is avail need to sync that data to server how can i achieve this.
Whenever there is new update is made with server need to get notification how can i do this
For this one which will be the best approach syncadapter or server or intent service with broadcast receiver which would be opptimized solution for the above requirement
These are all my doubts i would be very glad if someone helps me !!!

If you want an Android app to be notified when something happens on a server you control (without having the app to constantly poll the server to ask for changes), the usual solution is to use Google Cloud Messaging to allow the server to send a notification to the app to tell it to refresh data.
It is kind of complicated to implement, but is the best way to do what you want and is standard practice for mobile apps.

If you need to know when the network becomes available, to reach your server for synchronization, implement connectivity change listener, as discussed in this question.
This does not allow to send messages from the server easily, but if the server messages are not of high urgency, maybe you can simply check for them periodically.
This would allow to use less Google specific infrastructure and change the cloud providers easier.

Android design- Data sync approach

I have following scenario:
Android application running on mobile device needs to have data syncing feature based on given set of interval specified by mobile application user.
I have designed a UI which will accept syncing frequency from user and persist in sqlite db. I was wondering what would be right approach for building syncing logic. Server exposes restfull webservice for getting delta changes in data. Syncing should happen even if application is in dormant( application is not active) Background syncing should be invoked on specified frequency.
Can i use make use service along alarm for implementing this?
Is there a better approach for implementing this?

Use the SyncAdapter class, a Service, AlarmManager, and every component that follows from using the SyncAdapter class.
Using a SyncAdapter allows the user to control the syncing from the same place he controls the accounts and the syncing of all his other apps: google apps, facebook, twitter, whatsapp, etc.
This is really the best way to do syncing. It's part of the standard UI the user is used to. And it's also the most energy efficient way you can do syncing.
Also, using a SyncAdapter doesn't preclude you from having the user set the frequency of the Syncs inside your app (as long as the primary way of turning on and off the syncing still goes through the "Accounts and Sync" main settings of the device itself).

Android app to sync data to remote server asynchronously

I am developing an Android app that stores data locally in Sqlite database and sync it to a remote server (MSSQL server). The sending of data is handled through REST api.
This is the way I would like it to work and my plan to handle it:
When the app stores data in Sqlite database, the app will check if internet connection is available, if it is then the app will make a HttpPost to send the data (I use AsyncTask to handle this). Once the data sent, I will flag the row in the database as "synched" using postExecute callback.
If the internet connection is not available, then the app will continue on.
I need to make the app to listen to the event when internet connection became available and then the app will go through all rows that have not been synched and use AsyncTask again to send the data to remote server.
My questions are:
Is it achievable? and if so, is it best practices?
How to listen to the even when internet connection became available?
Thanks,

You could implement this manually, but I suggest you use a SyncAdapter instead.
Although you can design your own system for doing data transfers in
your app, you should consider using Android's sync adapter framework.
This framework helps manage and automate data transfers, and
coordinates synchronization operations across different apps. When you
use this framework, you can take advantage of several features that
aren't available to data transfer schemes you design yourself.
If you want to implement this without using a SyncAdapter anyway, then for the "detect when connection becomes available", you need to add a BroadcastListener to listen for CONNECTIVITY_ACTION broadcasts, then use a ConnectivityManager to query about the current state.

How to structure an application properly on background processes

I have an application that uses a webservice to get information and save the changes made ​​by the user.
currently I have one service that runs while the application is open, and it has public methods for each operation. the trouble is that service is growing considerably and I'm thinking refactor, but the question is what is the best way?
I can think of the following options:
Deferred services the current service and that all are initialized at boot time application
Create small services and that these are initialized by local broadcast
although I have doubts about performance. Can give me some clue or example about which method is better, do not really care that changes are instantly synchronized, these are stored locally and can be synchronized when possible. Data sent are not many, so the synchronization is relatively fast
Synchronization processes are something like
Check if there is new data (I have several types of data, these are the ones that are growing)
Synchronize user preferences

Most likely there's no point of having Service running all the time. Instead, I'd go for IntentService. If possible, I'd also condifer using push notification (like GCM) so the server could let my app know that there's new data to fetch (or maybe even send it to me if you'd fit in the GCM payload limit).

Synchronizing partial database model from server to client

This is more of a conceptual question not necessarily bound to any specific technologies.
Lets say you got some database on a server, some REST/JSON API to access content in that database and some mobile client displaying data retrieved through the API.
It would be nice to have some caching mechanism on the client and also to be able to enable offline access to the data as long as the client is only reading (In my case it's fine to deny write access to offline clients to avoid having to manage all those nasty conflicts that might happen).
It appears that a nice way to solve that would be to have a subset of the servers database model present on the client and synchronizing data from the server to the client.
Access to the local database might then immediately return results but also trigger update requests to the server. In case the server returns modified data the client model then synchronizes it's local database and notifies the display of data changes.
The goal in the end is of course is that the user may browse the information regardless of the stability of his internet connection and is not annoyed by connection dialogs or similar as long as he doesn't modify any data.
Now from an implementation perspective... on one hand it seems like a bad idea to couple the server database directly to the client database as they may be from different vendors. I guess at least there would need to be a vendor independent model above both database implementations. On the other hand, transforming the data from the server database into some transport format and than putting it back into the client database seems like a lot of overhead.
Any suggestions how to solve that in an elegant and maintainable way?

I am working on an app that syncs small portions of a large database locally onto the handset. There is an initial preload that has to occur on the handset but after that the updates happen asynchronously in the background.
First of all, decoupling the server and handset using JSON or XML is highly advised. Locking into one technology always causes issues as you are forced to use the same technology regardless of the platform. That is, if you plan on expanding into other platforms (Web,iOS,etc..) you are forced to use the format dictated by the server. Choosing a generic format will make that simpler in the long run. In reality with the amount of public libraries reading/writing JSON is a trivial matter.
There are two ways that we use to sync the data;
1. AlarmManager
We schedule the AlarmManager to trigger a service to wakeup on a regular schedule (lets say every 6 hours). The wakeup starts a background service that contacts the server, downloads the changes in JSON and updates a local SQLite DB. If there is no connection, the update is skipped and scheduled for the next wakeup. We add a ConnectivityChanged receiver to automatically restart the sync when the connection is restored.
2. GCM
It's a little more work but saves a lot of battery and data usage if you only update the local database when there are changes. Google Cloud Messaging can send a wakeup message to the device and tell it to start the sync service. The sync service runs the same as the AlarmManager method above.
We do a combination of both of the methods above depending on how "fresh" you need the data and how often it changes. Something like an RSS feed should probably be updated every 30min whereas weather data may not need to be updated more than every 4 hours.
So to run the database sync we use;
Receivers -> listen for system events and trigger Service
Services -> connect to the server, download the JSON and update the SQLite providers
Providers -> insert the records into the database and broadcast content changes to ContentObservers
ContentObservers -> when the app is running, the ContentObservers update the UI with the new data
There is a lot of technical details in each of the components above but that should provide you with a very robust architecture for syncing server data with a local db.

I'm working on a project that has similar requirements. We want to have a big, available database on a server somewhere and then mobile devices that get data from it. If the devices go offline it's ok because they have saved their own copies of the data locally.
We've decided to use BigCouch (fork of Apache CouchDb that supports clustering) as the server technology and then Couchbase Mobile on the mobile devices. (As a note TouchDB for Android will replace Couchbase Mobile, but it's not stable yet.)
The reason we went with Couch* technologies is that Couch has good replication over HTTP. You can programmatically initiate a sync event on the mobile device and it will replicate all inserts, updates and deletes for you. It stores the information on it's own embedded CouchDb on the mobile device, so it can be read offline.
If you didn't want to go down the Couch road, you could simply use something like SQLlite to store the results of your REST/API calls. Then you would have to write your own replication logic for when a mobile device goes offline and then comes back. There are creative ways to do this, so maybe it's an option.