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.
Related
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.
The documentation for Android's SQLite interfaces mention that database accesses should be performed from an IntentService as they are potentially long-running operations, so the GUI thread should not block on them.
The IntentService is shut down as soon as no further Intents are queued for it, which would happen basically after every request, so the database handles are built up and destroyed for each query as well, which seems wasteful.
Is there a way to keep an IntentService around longer, or somehow otherwise avoid a race between the GUI thread posting more Intents and the service answering them?
Should I just make my query Intents contain a list of queries that should all be performed, or would that cause other problems with message sizes?
The documentation for Android's SQLite interfaces mention that database accesses should be performed from an IntentService as they are potentially long-running operations, so the GUI thread should not block on them.
I/O of all forms should be performed on background threads, so as not to block the main application thread. IntentService itself is not a great choice, given changes on Android 8.0+.
A more typical approach nowadays is to have database access be managed by a singleton repository (whether a manually-created singleton or a singleton supplied to you via a dependency injection framework). The repository can use any number of approaches to provide a reactive API while doing the I/O on a background thread, including:
RxJava
LiveData and ordinary threads, executors, etc.
Kotlin coroutines
If you use Room as your database access layer, it gives you all three of those options "for free". Some other ORMs offer similar capabilities.
Is there a way to keep an IntentService around longer, or somehow otherwise avoid a race between the GUI thread posting more Intents and the service answering them?
Background services can only run for one minute. If your concern is the overhead in opening the database, use a singleton repository, and only open it once per process invocation. It's also entirely possible that you do not need a service; if you have a foreground UI, a service may be pointless.
Should I just make my query Intents contain a list of queries that should all be performed...?
Um, possibly, but again, using a service here may not be necessary and definitely makes the problem more complex.
So: use a background thread for I/O. That does not have to involve a service.
I am having problem with observing LiveData and querying data from Room Database in a foreground service class. This service run in the background and perform various database operations.
Observing LiveData seems possible by using observeForever and
querying can be done by accessing repository class (bypassing ViewModel) but it seems like a hack, not a standard way.
I need share some data between Android devices live (at least every 5 seconds update). I first had in mind to create an async task in which the one device sends its own data to a server and gets the other data as response. I recently read about firebase or synchronized database so I was wondering which is the best way with keeping performance in mind.
I'm not asking for code but for ideas to improve my app. I also need to save the "old" data from each client for a history.
There is no need to use AsyncTask
For implementing Firebase operations. Firebase is already optimized. So you don't need to use a background thread for performing network-related operations using firebase.
firebase childevent listener frequently checks for database changes and you can show them on the UI screen, no async task needed.
I have an app that have two processes, one for the ui and one for a service. Currently, when a change is made on the ui, i send the object through a bundle to the service in the other process. Currently, it looks too hard to do this way, parcelling and unparcelling data. Will like to know if its safe to save those changes to realm on the ui process and then notify the other process (service) of the change, fetching the data from realm there ?.