I'm looking to update the data in Firestore by using some kind of background task. Currently, I'm using a ListenableWorker, since Firestore operations are asynchronous and listenable worker supports asynchronous work with SettableFuture. But Listenable worker runs the startWork() method in the main thread and the periodic work requests are then run in the background if I'm not wrong. I want to run the whole thing (updating data in Firestore) in the background even when the app is not opened throughout the day, but the process should be run periodically throughout the day.
Related
There is an large app that uses coroutines to update data in local Realm database. Realm is factored and distributed by Dagger 2. All this happens when using the app in foreground. But now I shall update data from background service (FirebaseMessaging).
How to update realm database with data from Worker in WorkManager that is queued from background service. What is ideal approach that will not lead into deadlocks or any other kind of collisions.
I'm using WorkManager in my application, is there any chance to force using same thread on each Worker instance? I'm doing operations from those Worker on my list and I need to be sure that they will be in a proper order. I know that there is ExistingWorkPolicy.REPLACE but it is working only when Worker is pending not already started.
I'm doing operations from those Worker on my list and I need to be sure that they will be in a proper order
WorkManager does not guarantee the order in which work gets done. Either:
There should be only one piece of work that does everything (so the "proper order" is simply your own logic in doWork()), or
You need to change your application logic such that the work can be performed in any order
I've an android app where I'm retrieving data into a Fragment. And I believe that Firebase manages its asynchronous calls. But still I've doubt the if we need to write the Firebase code in the background thread or not?.
If we need to write it into the background thread then can you please tell which operations takes more time. eg:
mDatabase = FirebaseDatabase.getInstance().getReference().child("Blog");
I think that performing this on the main UI thread may become risk full because setting connection between database may sometime take large time.
The Firebase Database client performs all network and disk operations off the main thread.
The Firebase Database client invokes all callbacks to your code on the main thread.
So network and disk access for the database are no reason to spin up your own threads or use background tasks. But if you do disk, network I/O or CPU intensive operations in the callback, you might need to perform those off the main thread yourself.
If you're pulling down a large-ish collection of data from the database, and you want to convert that all into a JavaBean type collection, you may want to offload that onto another thread as the size of data its use of reflection may cause too much work for the main thread. The only way to know about this for sure is to benchmark it yourself. Generally speaking, you get 16ms to do things on the main thread before you start dropping from the optimal rendering speed of 60 frames per second.
I recently tweeted a diff on a project of mine where I refactored a pattern for sending database listener to an Executor for background processing. However, your app may not call for this kind of complexity. It was good for my app, however. https://twitter.com/CodingDoug/status/773277680867258368
Firebase runs all of its callbacks asynchronously as documented https://www.firebase.com/docs/android/guide/retrieving-data.html . This is done through a web socket layer.
If for example, you need to do a large amount of data processing on the result of the Firebase data update - you should probably spin up an AsyncTask to prevent the UI from blocking. This isn't any different from how you would normally approach data processing before being presented to the UI.
The Firebase documentation covers how data is handled and the reason why you do not need to execute any background reads. You should probably spend some time reading the documentation.
I am working on a app that syncs data over the network, and inserts user data in a database. To avoid slowing down the UI thread, both database queries and network requests run in the background.
At the moment, both are implemented using AsyncTask, started with executeOnExecutor(AsyncTask.SERIAL_EXECUTOR). The problem is, if a network request is taking a long time, database writes will be delayed by that much. Is it possible to have multiple SERIAL_EXECUTORS (in this case, two)?
If not, would the basic implementation of SerialExecutor shown in Google's documentation be enough?
it is logical question so I don't have code.
My question is:
How may I run background task that make Network work (waiting for messages from the server) and in the same time updates the UI when Message arrive!!
the Paradox "Android prevent access to UI from another nonUI thread", and "prevent network accesss from UI thread!!!"
Important: I want to run my method all the time that the application run, and scan network buffers and when I get message I want to update the UI and messages List...
That sounds like a perfect description for a Service. You can use IntentService or build your own Service (be careful, the last one doesn't start in a new thread by default).
There are also many examples out there how to update the UI from a Service (i.e. using Notifications or Broadcast).
Android provides built in class to perform network operation. For this purpose you can use AsyncTask class.
AsyncTask enables proper and easy use of the UI thread. This class
allows to perform background operations and publish results on the UI
thread without having to manipulate threads and/or handlers.
You can get details from here Android AsyncTask
But if you want to check message continuously then Service is the best solution as #AlexS explained it perfectly.