Add RxJvav2 support #669
Add RxJvav2 support #669
Conversation
- add org.greenrobot.greendao.rx2 package and rxjava2 support code. Type: feature Scope: DaoCore Signed-off-by: Zhang Tingkuo <zhangtingkuo@gmail.com>
|
Hi @ZhangTingkuo, I am a user of greenDAO. Firstly thanks for the PR. I am experimenting with your PR, using your master branch from jitpack, and it compiles. However I found some API missing: There is a rx() version but no rx2() version. Is it intentional? |
|
To my understanding adding that API is quite trivial. |
|
@BrianOn99 What is your use case? Perhaps you're already aware, but it's my understanding (and please correct me if I'm wrong) that the previous greenDao rx implementation and this one are not truly reactive, but just simple convenience wrappers around what amounts to a Single call. They won't ever trigger more than once. If that's okay with you, then carry on and don't mind my comments. Anyways there's probably a slim chance you fall into my use case, but I figured I would reach out since I saw you post on a few threads. I had success wrapping SQL Brite around greenDao. It's not optimal, because they aim to do two very different things. GreenDao seems to focus on efficiency and decent ease of POJO generation. I've worked on projects and used GreenDao where its efficiency was a big asset; my current one is not. In the project it was needed, I was indexing and ingesting file metadata ranging from at least hundreds of thousands of files to millions. Since it that initial ingestion was part of startup process and the first impression users would have with the app, greenDao was very helpful. I would say most projects its not needed. I've been pulled onto a large, old project that desperately needs some love. There are over 80 tables so ripping greenDao out is not just a weekend project, at least not in its current state. I wanted a more reactive solution so I'm using this combination as a stop gap. If you find yourself in the same situation as myself, I would be happy to offer some help. I most likely won't have a cookie cutter perfect solution for your case, but I think passing along my work and words of advice could be helpful if you fall into my niche. To summarize my jimmy rigged solution involves an rxQueryBuilder function to use alongside the rest of greenDao feature set that will actually observe the database tables so that when they're updated the observables emit the queries you defined (so not just one off async calls). There's also some convenience functions catering to Optionals if you're a fan. Its using greenDao 2.2.1. It's not some robust solution; it was developed in a weekend on "I wonder if..." that got out of hand, but has served me fairly well. Let me know if you're interested. |
|
@jhowens89 Thanks for your suggestion, but I am OK with the old non-reactive approach. |
|
Has some error! RxJava 2.x no longer accepts null values. So, the |
Type: feature Scope: DaoCore Signed-off-by: Zhang Tingkuo <zhangtingkuo@gmail.com>
| @Override | ||
| public Void call() throws Exception { | ||
| mDao.delete(entity); | ||
| return null; |
There was a problem hiding this comment.
throws NPE when use Observable.concat. All like this methods should not return null value.
Maybe return Void.TYPE.newInstance() much better!
Type: bugfix Scope: DaoCore Signed-off-by: Zhang Tingkuo <zhangtingkuo@gmail.com>
|
Great! Hope to be officially released as soon as possible |
Type: feature
Scope: DaoCore
Signed-off-by: Zhang Tingkuo zhangtingkuo@gmail.com