Let me simplify my example. Imagine I have two buttons.
btn_A.setOnClickListener(v -> {
// update ROOM DB value to A
});
btn_B.setOnClickListener(v -> {
// update ROOM DB value to B
});
Button A will set DB value to 'A'.
Button B will set DB value to 'B'.
Since I cannot access DB from the Main/UI thread, I execute it from the new thread:
btn_A.setOnClickListener(v -> {
new Thread(() -> {
// update ROOM DB value to A
}).start();
});
btn_B.setOnClickListener(v -> {
new Thread(() -> {
// update ROOM DB value to B
}).start();
});
If I press Button A, B, A, B..., then I am worried that new threads will not execute consecutively(in sequence).
I thought about using ExecutorService with Executors.newFixedThreadPool(1) but I am not sure if this will run the worker thread in sequence. Also the DB modification commends are called from different Activities/Service so I should make the ExecutorService static. I am worried if I make the ExecutorService static and don't call 'shutdown()', then it may result in memory leak.
I want to avoid implementing my own producer/consumer design pattern with the queue logic.
It feels like there is a simple way to do it but I can't figure it out. :(
You need to run all updates on a single thread. One way is to use Looper and Handler in order to send messages to the database update thread and it executes those messages in the order received. At a higher level, you can use an event bus library like Otto to help facilitate this inter-thread communication.
Related
I have an android linear search algorithm for finding duplicate files and packed it in the function
public void startSearch()
I was able to run it in a separate thread like this
class ThreadTest extends Thread {
public void run() {
startSearch()
}
}
but when i try to update the progressbar in that thread,it throws a exeption and says i the ui thread can only touch it's views
is there any other way to do this?
There are so many ways to do it, some of them are deprecated, some add unnecessary complexitiy to you app. I'm gonna give you few simple options that i like the most:
Build a new thread or thread pool, execute the heavy work and update the UI with a handler for the main looper:
Executors.newSingleThreadExecutor().execute(() -> {
//Long running operation
new Handler(Looper.getMainLooper()).post(() -> {
//Update ui on the main thread
});
});
Post the result to a MutableLiveData and observe it on the main thread:
MutableLiveData<Double> progressLiveData = new MutableLiveData<>();
progressLiveData.observe(this, progress -> {
//update ui with result
});
Executors.newSingleThreadExecutor().execute(() -> {
//Long running operation
progressLiveData.postValue(progress);
});
Import the WorkManager library build a worker for your process and observe the live data result on the main thread: https://developer.android.com/topic/libraries/architecture/workmanager/how-to/intermediate-progress#java
Complex can have different interpretations. The best way is to have Kotlin Courtines, RxJava with dispatchers.What you have mentioned is a way but if you have multiple threads dependent on each other, then thread management becomes trickier. On professional apps, you would want to avoid the method that you have mentioned because of scalability in future.
I'm trying to implement a simple chat application on web sockets in Clean Architecture. I had to choose a db for caching all information, so I decided to use Realm, because I heard it was pretty good database for any kind of mobile applications. But when I actually faced the Realm, it turned out to be really painful experience for me to implement caching logic with it.
All problems come from applying transaction to database which then must be synced on all threads working with Realm. There seems to some kind of synchronization problem with my code. For example, I want to save my object to Realm and then query it out of.
Here I have two simple functions to save and to get chat:
fun getBackgroundLooper(): Looper {
val handlerThread = HandlerThread("backgroundThread")
if (!handlerThread.isAlive)
handlerThread.start()
return handlerThread.looper
}
fun saveChat(chat: Chat): Completable {
val realmChat = ChatMapper.domainToCache(chat)
return Completable.create { e ->
val realm = Realm.getDefaultInstance()
realm.executeTransactionAsync({
it.insertOrUpdate(realmChat)
}, {
realm.close()
e.onComplete()
}, {
realm.close()
e.onError(it)
})
// Subscribe on background looper thread
// to be able to execute async transaction
}.subscribeOn(AndroidSchedulers.from(getBackgroundLooper()))
}
fun getSingleChat(chatId: String): Single<Chat> {
return Single.defer {
val realm = Realm.getDefaultInstance()
realm.isAutoRefresh = true
val realmChat = realm.where(RealmChat::class.java)
.equalTo("id", chatId).findFirstAsync()
if (realmChat.isValid) {
realmChat.load()
val chat = ChatMapper.cacheToDomain(realmChat)
realm.close()
Single.just(chat)
}
realm.close()
Single.error<Chat>(ChatNotExistException())
// Subscribe on background looper thread
// to be able to execute auto refreshing
}.subscribeOn(AndroidSchedulers.from(getBackgroundLooper()))
}
So, when I try to run simple code like this
remote.getChat().flatMap {
cache.saveChat(it) //save chat to realm
.andThen(cache.getSingleChat(it.id)) //then query it by id
}
I always get no matter of what ChatNotExistException, but if I try to run query again in another attempt or after restarting the application, then the chat object gets found
I also tried many different approaches to execute this code:
I tried to use realm.refresh() in getSingleChat or not use it at all.
I tried to query chat synchronously with findFirst() and findAll() instead of findFirstAsync().
I tried querying chat on current thread without .subscribeOn().
I tried to use realm.executeTransaction() instead of async transactions.
I tried to add thread sleep between saving and querying, so that transaction may take some time to get applied and I need to wait before attempting to query the chat
I'm begging anybody to explain me what am I doing wrong and how to make this code working. I can't change the architecture of my application and use Realm objects as my view models, I need to find solution in these conditions.
But when I actually faced the Realm, it turned out to be really painful experience for me to implement caching logic with it.
Reading the docs regarding best practices help. For example, the default idea is that you define a RealmResults using an async query on the UI thread, add a change listener to it, and observe the latest emission of the database.
There is no "caching" involved in that beyond saving to the database and observing the database. Any additional complexity is added by you and is completely optional.
All problems come from applying transaction to database which then must be synced on all threads working with Realm.
All looper threads automatically make the Realm auto-refresh, therefore if addChangeListener is used as intended in the docs, then there is no need for trickery, Realm will manage the synchronization between threads.
I want to save my object to Realm and then query it out of.
realm.executeTransactionAsync({
No reason to use executeTransactionAsync when you are already on a background thread.
try(Realm realm = Realm.getDefaultInstance()) {
realm.executeTransaction((r) -> {
// do write here
});
}
realm.where(RealmChat::class.java)
If you do import io.realm.kotlin.where, then you can do realm.where<RealmChat>().
.findFirstAsync()
No reason to use findFirstAsync() instead of findFirst() when you are already on a background thread. Also no reason to use load() when you're on a background thread, because you should be using findFirst() in the first place anyway.
You are also most likely missing a return#defer Single.just(chat) to actually return the chat if it's found. That is most likely what your original problem is.
With the handler thread things you're doing though, you might want to consider taking a look at this project called "Monarchy", as it intends to set up the ability to run queries on a background looper thread while still observing the results. It is labelled stagnant but the ideas are sound.
Hi I'm using RxJava for my disk storage get and set operations. Basically I have a method like this:
public Observable<String> getStorageItem(String id, String type) {
return Observable.defer(new Func0<Observable<String>>() {
// Run db operations to get storage item.
}
}
The problem is that it's possible this method getStorageItem(...) gets subscribed to multiple times in a row. And the DB operations within the observable cannot run concurrently. What's my best option here? Should I manually create some sort've queue? Or does RxJava have some kind of tool that allows me to block the operation until a previous one is complete?
You can use a subscribeOn with a single-threaded scheduler created from an ExecutorService to make sure there's only one DB operation in progress:
ExecutorService exec = Schedulers.newSingleThreadExecutor();
Scheduler s = Schedulers.from(exec);
public Observable<String> getStorageItem(String id, String type) {
return Observable.fromCallable(() -> {
// Do DB operations
});
}
getStorageItem("1", "2").subscribeOn(s).subscribe(...);
getStorageItem("2", "4").subscribeOn(s).subscribe(...);
getStorageItem("3", "6").subscribeOn(s).subscribe(...);
But note that by moving the computation off the caller's thread, it may execute any time. If you need to wait for it individually (because the getStorageItem is already called on some thread), you can apply toBlocking() after subscribeOn.
I'm still somewhat new to rxAndroid/rxJava so I'm having a little trouble wrapping my mind around this and if I'm doing everything correctly.
I am using SqlBrite to update a RecyclerView with rows returned from a Cursor. When a db operation is performed on the table, the observable below is responsible for re-querying the data. I want to return a CursorWrapper (ChecklistCursor), but want to make sure I am running the select * query on a worker thread. The checklistRecyclerAdapter subscribes to the ChecklistCursor observable and is responsible for managing the cursor.
The code below seems to be the only way that I am able to get query.run() to run on a worker thread and the subscription to return on the main thread.
I guess it works, but I don't believe this would be the standard way to do this. Could anyone offer a better method than using observeOn twice?
compositeSubscription.add(db.createQuery(Checklist.TABLE, Checklist.QUERY_ALL)
.observeOn(Schedulers.newThread())
.map(query -> new ChecklistCursor(query.run()))
.observeOn(AndroidSchedulers.mainThread())
.subscribe(checklistListRecyclerAdapter));
I would replace the first observeOn call with subscribeOn(Schedulers.io()), in order to perform the query operation in a background thread. Map operator will still perform the operation in the background thread, and after that, you can change with observeOn to update your adapter. I think this is the only way to do this.
I am working on an Android application that uses greenDAO as a data persistence layer. The application downloads data from various different sources across multiple threads (determined by a thread pool), each piece of data is inserted into the database in a transaction using insertOrReplaceInTx. This is working fine.
My question is whether it is technically possible, using greenDAO, to encapsulate these different transactions (which occur on different threads) into an overall transaction, using nested transactions. I know in theory it is possible to do this if all the transactions were taking place on a single thread, however I am unsure if this possible with the insertOrReplaceInTx calls occurring on different threads.
The reason I wish to encapsulate these into a single overall transaction is because they represent a synchronisation process within an app. In the event of any single part of the import failing, I wish to abort and rollback all of the modifications within the overall transaction.
If I begin a transaction with db.beginTransaction on the main thread where I initiate the import process, this creates a deadlock when another thread tries to insertOrReplaceInTxt.
Is the correct way to counter this to ensure that all greenDAO transactions are taking place on the same thread?
Afaik, you cannot because each thread manages its own connection.
If you have such dependency between these operations, you probably want to sync them anyways.
e.g. what if Job A finishes way before Job B and Job B's db connection fails. Your data will go out of sync again. You still need some logic for the other job.
Also, writers are mutually exclusive.
I would suggest creating a utility class that can run a list of runnables in a transaction. Each job, when finished, enqueues a Runnable to this utility. These runnables include the actual database commands.
When the last one arrives (this depends on your dependency logic), the utility will run all runnables in a transaction.
A sample implementation may look like this: (I used a simple counter but you may need a more complex logic)
class DbBundle {
AtomicInteger mLatch;
List<Runnable> mRunnables = new ArrayList();
DbBundle(int numberOfTx) {
mLatch = new AtomicInteger(numberOfTx);
}
void cancel() {
mLatch.set(-1); // so decrement can never reach 0 in submit
}
boolean isCanceled() {
mLatch.count() < 0;
}
void submit(Runnable runnable) {
mRunnables.add(runnable);
if (mLatch.decrementAndGet() == 0) {
db.beginTransaction();
try {
for (Runnable r : mRunnables) r.run();
db.setTransactionSuccessful()
} finally {
db.endTransaction();
}
}
}
}
When you create each job, you pass this shared DbBundle and the last one will execute them all.
So a job would look like:
....
try {
if (!dbBundle.isCanceled()) { // avoid extra request if it is already canceled
final List<User> users = webservice.getUsers();
dbBundle.submit(new Runnable() {
void onRun() {
saveUsers(users);//which calls db. no transaction code.
});
});
} catch(Throwable t) {
dbBundle.cancel();
}