How can i transfer large amount of transaction from android device to server? - android

I am currently storing my transactions in SqLite DB if there is no internet connection at the moment and when there is internet available i send the pending transactions with the new one made so making it quite a lot of data and a lot of API hits which chokes the device and it becomes unresponsive. So need help with a proper way to sync these transactions to the server. Also these are being sended to a Socket as well as a Server.
I tried using AsyncTask for it but it also causes problems if transactions are above 200. Tried Retrofit for it and to some extent the count exceeded from 200 to almost 350 but the issue and unresponsivness remains.

You should give a try to PriorityJobScheduler lib or WorkManager from JetPack.
When there is no network connection you can queue those request and those request will be send ones network connection is available. (So you dont need to wait until someone made new transaction to send old queued data too)
Also, in your current scenario, rather than sending single request for each transaction, ask your API Guy to accept request in List of object format. So you just need to create list of request body object and send to server


How to keep http requests pending until restoration of internet connectivity in Android Apps?

I am relatively new to developing Android apps. I have an android app that downloads several resources from the internet and keeps on generating these requests. I want to create a queue of such download requests when there is no internet connectivity and get them started as and when the connection is restored. In this case, the connectivity may be in either form both Mobile data as well as over Wifi
There are several parts to this: first, detecting whether you're online now, if you're not online detecting when you'll come online, and having the actual queue.
The queue itself can use a SQLite database. You just need to store enough information to reconstruct what the request should be when you resume.
You can see the documentation on monitoring the connection state here.
Basically, if you're targeting API less than 24, you register a broadcast receiver to receive the CONNECTIVITY_ACTIVITY broadcast. (Otherwise, you can "listen" for CONNECTIVITY_CHANGE). Your logic once you figure out what request you want to queue will probably be something like the following:
Push request onto the queue
Check to see if you have connectivity
If so: start processing the queue.
Otherwise: wait for a broadcast receiver to notify you that you have connectivity again and start your service that does the processing.
Sorry to be a little vague (I'm not sitting in front of an IDE right now) but hopefully that outline'll be at least semi-useful.
There's a number of popular "job queue" libraries that allow you to specify dependency on network being available (along with various retry policies). For example:
Create a local database which should have HTTP request details, time stamp and its status. Whenever your application initiate HTTP request store it in database with HTTP request details and time stamp of its initiation and its status to non completed.
When your HTTP request is complete change its status to complete so when your Http request generates some kind of exception or error you don't have to do anything.
Now your application should have a connectivity broadcast listener so when your application connects with internet read your database and initiate your HTTP requests.

how to submit data to server from Android app when connection is unreliable

I have an Android app that is storing data locally, and a server is set up so that I can backup this data remotely.
My question is what is the best way to ensure that when data is added locally, it also gets through to the server?
I am currently using HttpUrlConnection to POST my JSON encoded data to a RESTful API. But what happens if the server is unavailable (because the Android phone is out of range, for example)? My basic connect timeout is 10s, but if it is out of range for longer than this then the data won't get sent to the server.
Is there a good way to queue my data submissions so that even if I'm out of range for a long while, they will all get submitted properly once the connection is re-established?
A general approach is the following:
Decouple your flow of saving data locally and sending it to server. Keep the two actions separate.
Use a Service to periodically send data from your local Android store to the Server. Plan to catch any errors and build in retry logic. The Service code could determine if the connection is there or not and do the sync accordingly.
Provide a manual action in your app (depends on your design) to begin syncing data to the server or not. Again plan for catching errors and retry logic.
Provide a settings page that the user (if required) can tweak how frequent he wants the sync between the local and server to happen.

Message queuing from android considering unreliable network

My architecture will use ActiveMQ on the server and have Android clients send and receive messages.The network situation will be very unreliable; possibly hours of missing connection. Is there a framework that will allow me to queue up the messages on the android client and deliver them reliably once the connection is back?
You can efficiently implement one yourself, I don't think anyone will provide you this service, and if they do they will certainly charge, Here is what I can suggest for an optimal solution.
Design a db using SQLITE to hold you message, once a message is ready for deliver from android client, you can perform the following
a. If network is avaibale, then you can directly deliver message to your web clinet
b. If network in not present, then cache it directly to you local android db
Design a Sync logic, you can achieve it by network listener, so when user device comes back into network,
you can write a logic to query from databse and posting to your webclient, deleting local data subsequently
upon successful posting into server
You can strengthen you logic, by caching message everytime into local db first, then a Sync logic which will commit your local changes to web server in bulk, thus improving upon processing time.
Hope this answer your problem.

How to handle a request for data that is not yet ready

I have a server that accepts JSON requests. This server connects to various API's, collects data and arranges it based on the client request.
If a client requests data, but I am still in the process of downloading/manipulating required data from another API from the server, then what is the best way to handle this ?
Right now I can think of two options;
Wait until the data is ready, and then send the response.
Tell the client it is not ready yet and to try again soon (in 5-10
Which one of these would be more appropriate ? Is there a standard way of dealing with this situation ?
Personally I would rather have a very short delay before being given some indication that data would be available in a while than just have nothing happen, (my preference), if it is a web client you can return a page with an auto-refresh setting.
My reasoning is that I am reassured that the server is working and I have a working connection rather than just not getting a reply, (for an indeterminate time). You do need to clearly specify in your client API that a valid response is "Not Ready Yet come back in ...."

Best strategy to handle broken network connections?

i want to keep my app in sync with the Server. The communication between client (android app) and server is handled through JSON Objects / HTTP. What is the best strategy if the connection is not available anymore? It is important that the user can continue his work with the app. Does there even exist frameworks for such sync-problems?
i thought about a queue of transactions?! Any reccomendations or experiences?
For fetching... I once wrote a caching URL manager that would load read the JSON from reply from the server and write it to the SD Card. When if the user did another request for the same URL a short time later, the URL manager would simply return the cached json from the filesystem as the JSON reply. This made the communication code somewhat transparent, in that I was always dealing with JSON replies, whether or not they were cached or real time.
For sending information to the server, you could write all information to the database, and use a background service that pushes the data to the server. That way the UI will always succeed in writing the information and your sync service would push data if there was a network connection. Using a Service you can simply pass the data in the Service intent and it can worry about the writing to db and syncing, etc.
i think this is what i will use in my next project :)