Develop Reference

Getting data from server regularly even when the app is closed

I want to get data from the server and store it in a cache regularly, even when the app is closed. I am not sure what is the correct way to do it. I have listed down the possible ways I can think of. Please let me know the correct or the best way to do it. Really appreciate any help.
Create an Activity and set a repeated alarm to call a service. The service should connect to the server and download the data in cache.
From a fragment, check the last time the cache was updated and then if the data is out-dated, connect to server in a background thread and update the cache.

You can Directly Use IntentService for Frequently Updating Data
IntentService is a subclass of android.app.Service class. A stated intent service allows to handle long running tasks without effecting the application UI thread. This is not bound to any activity so, it is not getting effected for any change in activity lifecycle. Once IntentService is started, it handles each Intent using a worker thread and stops itself when it runs out of work.
IntentService would be an best solution, If you have an work queue to process. For example, if your application using analytics you will likely to send event name and related parameter to your tracking server for each user generated event. Although each event means a tiny piece of data, creating networking request on each click will result an overhead to your application
For implementation : Updating Data from Server Using Intent Serive

Do take a look at Android Sync Adapter Framework.
https://developer.android.com/training/sync-adapters/index.html
Hope this helps.

Android app advice, multiple intent services?

My app has a UI and a connection is made to a bluetooth device which is periodically sending barcode scan data to my app. I then want to cache this data in a sqlite db and have another process push this data up to a web server.
I have managed to get the UI and bluetooth scan process separated by using an Intent Service for the scanner component... The thread in the intent service connects to the bluetooth device and loops endlessly pulling in new scan data as it comes... communicating with the UI via broadcast messages as it needs to.
So now I need to handle storing the data in a sqlite db and pushing it up to the Internet.
I'm thinking I can insert a db row directly in the intent service loop I already have working for the bluetooth data... would I do that by firing of an async task or something like that?
Then, would I have a completely different intent service running and looping endlessly checking for new records to be processed and pushed up to my web server via an http post?
I guess the main reason I'm thinking of using intent services is that they seem to keep running even if I lock my phone and put it in my pocket... has worked so far for the bluetooth barcode scanner... can scan away happily with my phone locked and in my pocket.
I also need to handle the reality that internet won't always be available... hence the sqlite db... kind of like a safe buffer to store data until it can eventually be pushed up to the Web server.
Am I going down the right path? I'm really new to Android development and even after much research I'm still unsure about my approach.

You can store data or communicate from IntentService onHandleIntent() directly. You don't need to run it in separate thread, unless you want reading bluetooth to continue ASAP.
Handling everything in an infinite loop smells. Also keeping service alive depends on few factors. If IntentService dies, it won't be restored because by default IntentService.onStartCommand implicitly returns START_NOT_STICKY, or START_REDELIVER_INTENT if you call setIntentRedelivery(true) on this service. Check Service javadoc for more info.
If you can scan bluetooth periodically then I would consider kind of scheduler. For that you would probably need to implement Service, not IntentService and handle background thread yourself. Alternatively, you could use a Timer. These are more hints, not ready solution. Since you asked about direction, I assume you will investigate solutions yourself.
Depending on handled data you could separate DB operations and network to separate services. Think about them as modules which are decoupled. You will benefit maintaing this code in the future and in case one service goes down due to any reason, the rest will keep working. It depends on data size because it's not a good practise to push heavy data between service/activities(data is serialised and deserialised every time it is sent).
If DB is just a buffer/queue then maybe use it directly after reading bluetooth data. In other words queue data for sending. Create second service for HTTP communications. Don't push entire data to second service, just inform it about(knock the door :)) and let HTTP service access DB by itself. I would wrap DB in ContentProvider and access it from services.
There are probably different techniques out there too, but that's what I thought about it in the first place.

Downloading data and updating UI

There are couple of things that are bugging me in the process of downloading data and notifying the UI in Android. I'm using (Intent)Services to download the data, which works good enough.
I'm not sure how to deal with notifying the UI that data has been retrieved though. After some research and discussion in Downloading data using IntentService - Lifecycle Changes, and Which is the best way to communicate between service and activity?, I'm arriving at a point where I'm not sure which method to use anymore.
The alternatives I'm looking at are:
Service + LocalBroadcasts + Databases
An Activity would start the Service
The Service would download the data into a database
The Service would send out the Broadcast with a 'done' notification
The Activity would pick up this Broadcast and retrieve the data from the database using an AsyncTask
The Activity would retrieve the data from the database using an AsyncTask every time it is shown to the user (onResume, for cases it has missed the broadcast due to the user navigating away).
Service + ResultReceivers + Databases
An Activity would start the Service
The Service would download the data into a database
The Service would notify the ResultReceiver that it's done
The Activity would retrieve the data from the database using an AsyncTask
Instead of retrieving the data every time, the ResultReceiver is reused across lifecycle changes, and notifications are not lost.
Service + ResultReceivers + Bundle
An Activity would start the Service
The Service would download the data (optionally into a database)
The Service would notify the ResultReceiver that it's done, and supplies the data in a Bundle.
The Activity would retrieve the data from the Bundle (No AsyncTask needed).
Instead of retrieving the data every time, the ResultReceiver is reused across lifecycle changes, and notifications are not lost.
Options 1 and 2 require the user waiting for the database read/write operations. Option 3 is therefore quicker, but I've seen many sources recommend not using Broadcasts or ResultReceivers to transfer data (I'm not sure exactly why though).
For now, I am sticking with option 3, but I'm not sure if this is actually a proper approach, and if I'm missing something.
Can someone shed some light on this?
While some people (possibly righteously) vote this question to be opinion based, I am looking for pitfalls I am possibly overlooking. Furthermore, I'm looking for the answer as to why using ResultReceivers or Broadcasts for sending result data is recommended against.

Carefully using some sort of DataManager singleton instance, backed up by a database seems to be a robust solution. Using ResultReceivers, the UI gets notified and pulls the data from the DataManager.
I have also found out that using ResultReceivers and Broadcasts to send data has a negative impact on performance, because the objects need to be serialized. This is a costly operation, and GC might kick in because of it.

How to implement automatic synchronization in Android?

My application can now synchronize some data to a remote server, and at the moment, it happens explicitly when my user clicks a button, the app shows a ProgressDialog and does the network operation in background with ASyncTask.
Now my client requires that the synchronization should happen on any data change. I cannot do it on the "foreground" like it's now, because it usually takes 5-10 seconds on mobile data connection, the app has to collect data from sqlite database, serialize it to JSON and send to remote web service.
Do I have to implement a Service that will receive a message from the application that it's time to do the synchronization? Or could I just move my ASyncTask to Application class and do the operation from there?

A service would be the best way to do this.

Retrieving JSON from database through service on Android

I am creating an app that requires a local database to be updated every time there has been a change in the server database. I want to run a service that runs every 2 minutes and updates the local database using ORMLite.
Would an IntentService be the best route to do this? Also I am getting mixed results on my searches about if all services are asynchronous or do I have to call a asynctask in Services other than IntentService.
Any suggestions on which direction I should go would be greatly appreciated!

I think what you need here is a Bound Service
It helps you deal with client-server model, where you main application can take advantage of background service. This service will do the job for you in background. With IntentService, this concept becomes a little bit different, you should handle this when you have a spefic job needed to be done in a short time ( not periodically like yours).
And because of frequent updatings , I think you should keep a socket connection to your server
to receive pushed updates from it ( I think some mail clients do this way).
Hope this helps.