Develop Reference

RxJava: unpack object

I am using RxJava in my Android project and I'm happy about it. I'm currently using it to make all my DAO methods asynchronous and make UI listens on them.
But I have a big problem, that is, when I retrieve some data from database using Observable<List<User>> getLists(), I need to use List<User> in my ViewModels, but I cannot extract it from the observable.
I would like to know what is the common approach to solve this kind of problem ? I searched on Internet and people said it's not recommended to extract the objects, but in this case how can I use the data from database and at the same time still enable the observers listening ?
Should I create another method using AsyncTask ??
Thanks.
In my UserRepo.java
public Observable<List<User>> getUsers() {
return colisDao.getUsers();
}
In HomeScreenViewModel.java:
public List<User> getUsers() {
return userRepo.getUsers(); // do not work because I need a List<User>
}
In HomeActivity.java:
UserListAdapter userListAdapter = new UserListAdapter(this,
vm.getUsers());

Central idea of reactive extensions is to make use of events' streams observation and timely processing.
So actually, if you need to retrieve data in a straightforward way, I'd say you don't need RxJava2 at all. Still, if you want to stick to the reactive approach, the data stream should be listened to instead.
All RxJava2 types provide a subscribe method that "notifies" the source of data that's lazy by nature that here is an observer that wants to receive the data, so all the data processing flow described by use of RxJava2 operators will become alive.
The most painless approach is to change HomeActivity's code to this:
vm.getUsers()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(userListAdapter::populateWithNewDataSet);
, assuming that adapter will have the mentioned method that will update the UI data set using something like notifyDataSetChanged() (or DiffUtil, for instance) internally.
By doing that the data source is now observed and every time the update is emitted the UI will be repopulated with the most recent data.
P.S.: I've just demonstrated the simplest way to do the thing, but it is up to the developer where to place RxJava-related code: be it ViewModel, Activity, or even some other component. RxJava is a convenient tool to use and it can make complicated asynchronous flow simple, but the problem with RxJava arises when all the code base is dependent on it. The code base can then quickly become unmanageable, fragile and rigid if the tool was used in an improper place.

Adding on #AndreyIlyunin very good answer, You could also use MutableLivedata in your Viewmodel to save the List in the viewmodel as Livedata and observe changes to it in your Activity. This is suggested by Google as a way to maintain MVVM architecture. Something like:
In HomeScreenViewModel.java:
private final MutableLivedata<List<User>> users = new MutableLivedata<>();
public void getUsers() {
return userRepo.getUsers()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(this::onUsers)
}
private void onUsers(List<> list){
users.setValue(list);
}
public MutableLivedata<List<User>> getUserList(){
return users;
}
In HomeActivity.java, in onCreate() add:
vm.getUserList().observe(this,this::onUserList);
and add following methods to activity:
private void onUserList(List<> list){
userListAdapter = new UserListAdapter(this,list);
}
and then from your activity call:
vm.getUsers();
The getUsers() call is made asynchronously in the background, and you get the userList reactivly.

How can I know when I need to dispose of a disposable in RxJava?

Trying to understand RxJava here. We have this code:
public void notifyNewOwnersSynced() {
OrgTreeType orgTreeType = getOrgTreeType();
new OrgTreeQuerier().queryOrgUserIds().byOrgTreeType(orgTreeType).executeAsync()
.map(opt -> opt.isPresent() ? opt.get() : new HashSet<String>(0))
.subscribe(
this::onNewOrgUserIds,
e -> Log.exception(new Exception("Unable to update selected id filter for type " + orgTreeType, e))
);
}
private void onNewOrgUserIds(#NonNull Set<String> allIds) {
synchronized (mLock) {
for (String id : allIds) {
if (!mPreviousAllIds.contains(id)) {
mSelectedIDs.add(id);
}
}
Set<String> idsNoLongerInHierarchy = new HashSet<>(); //Because we can't remove while we are iterating.
for (String selectedId : mSelectedIDs) {
//If there is a selected ID not in the new hierarchy...
if (!allIds.contains(selectedId)) {
//Plan to remove it.
idsNoLongerInHierarchy.add(selectedId);
}
}
mSelectedIDs.removeAll(idsNoLongerInHierarchy);
mPreviousAllIds = allIds;
}
mSaveListener.saveChangesAndPostFilterChangedEvent();
postSelectedIdsChangedEvent();
}
We have two lint warnings showing up on it: The result of subscribe is not used. and Result of single.subscribe() is ignored
This is in a class that is used by our UI(Fragments) to keep track of what users have been selected.
But on a larger scale we have a lot of spots in our code that use Rx like this to do something in the background (map something, network call, save data to the DB) and we don't every use the result.
Can I safely suppress these errors? or do I need to add handling for the Disposables?
How can I know when I need to dispose of a disposable?

Although not a comprehensive list of cases, I think I can point out some that I've faced during my career and might help you out.
The most common scenario I faced was when we make network calls that take too long and the app is put in the background. If not disposed, the result of the network will be forwarded to the subscriber. This is not really the issue. The problem is that usually the subscriber wants to change something UI related, which crashes the app. In this case, you dispose because you are no longer interested in receiving these events.
There are cases where the way the subscriber handles the result wouldn't be problematic, but the IDE has no way to know this and hence it warns you all the time.
I'm sure there are tons of other reasons why disposing should be handled - i.e., when observables acquire resources when subscribed and release them once unsubscribed from. So in general I guess it's good to handle the disposables. I only ever kept a disposable undisposed when I wanted to keep downloading files in the background and to be honest with you, I'm not even sure if this is a good practise.
Adding to this, if an observable or any of the other flavored observables (single, maybe, etc.) terminates, then it's disposed automatically.

Can I make the LiveData static?

I don't know if this is a stupid question. This may defeat the purpose of LiveData/ViewModel.
Can I make the LiveData static? My reason is I have a listener from a Service which updates the information. So I need to have a way from a service to "set/change" the LiveData.
I used to do following and it works:
1. Service changes the DB
2. ViewModel listens to the DB change
3. UI updates from the liveData change
I found this way is too slow. To increase the performance, I want something like:
1. Service changes the class object directly
2. ViewModel listens to the the class object changes
3. UI updates from the liveData change
In order to achieve what I want, either I need to make the MutableLiveData static or make the ViewModel class to share the same instance of ViewModel between Activities.
Is this good idea?
public class MyViewModel extends AndroidViewModel {
// Note: this MutableLiveData is static
private static MutableLiveData<MyModel> mutableLiveData;
public MyViewModel(#NonNull Application application) {
super(application);
}
LiveData<MyModel> getLiveDataList() {
if (mutableLiveData == null) {
mutableLiveData = new MutableLiveData<>();
loadDataFromDb();
}
return mutableLiveData;
}
private void loadDataFromDb() {
// load data from DB
// mutableLiveData.setValue(MyModelFromDb); // Omit the real implementation
}
// Note: this method is static
public static void setData(MyModel newData) {
mutableLiveData.setValue(newData);
}
#Override
protected void onCleared() {
super.onCleared();
}
}

The whole point of ViewModel from Android Jetpack (as opposed to other versions) is for the ViewModel to be lifecycle aware and perform magic like destroying itself when observer is destroyed (activity/fragment), or surviving configuration changes (for example, orientation) without initialising itself all over again thereby making it much easier to deal with issues related to configuration changes.
So if you made the ViewModel or LiveData static you would actually beat their purpose and most likely leak ViewModel's data, though the need to do this is understandable. So this requires you to engineer your way around it, and the first way you mentioned is probably the best way you can do it. I don't understand why you have an issue with the first solution. The way I see it, it provides the best user experience:
You init ViewModel in your fragment or activity in onCreate and add an Observer to the data.
If database already has some data, your observer will receive it instantly and UI will be updated with existing data instantly.
Service makes the API request and changes the DB
DB changes triggers an update to the data in ViewModel
Observer refreshes received data and you pass this to your views/adapters
UI updates with latest data with some nice animations that indicate addition/removal of items.
From what I can see it cant get better than this. Since your question is from months ago, I am curious to know what you ended up doing?

I think if MyViewModel will have lots of LiveData fields it will grow with large amount of getters and setters. And what even worst, as for me, you will break the testablity of your code, because if you will create a new instance of MyViewModel you will expect that your LiveData objects are stateless at this point of time, but as it's a static object you don't know in what exactly state it is after simple creation.
As well static methods can't be overriden. And about fields: if you will want to have common field, suppose errorMessage, in class A and class B while both of them extend class C(which contains your common field) you can have unexpected behavior. On the other hand you can duplicate this code in other classes(what is bad).
The memory issue: if a large number of static variables/methods are used. Because they will not be GC until program ends.
But it just my opinion.

Using RxJava to temporarily save variables during configuration changes

I am using RxJava on an Android project and want to make sure I'm implementing something correctly.
I am using an Observable to login to a server. After the login occurs I may want to save the username on the client side so I'm using the doOnNext() operator to do this. Here's an example of what this looks like:
Observable<Response<Void>> doLogin(Observable<Response<Void>> retainedObservable, Subscriber subscriber, String username, String password, boolean saveUsername) {
if (retainedObservable == null) {
retainedObservable = networkLayer.loginWithcredentials(username, password)
.doOnNext(new Action1<Response<Void>>() {
#Override
public void call(Response<Void> voidResponse) {
if (saveUsername) {
databaseLayer.saveUsername(username).subscribe();
} else {
databaseLayer.saveUsername(null).subscribe();
}
}
})
.cache();
}
mSubscription = retainedObservable.subscribeOn().observeOn().subscribe(subscriber);
return retainedObservable;
}
If the device goes through a configuration change before the login finishes I want to be able to resubscribe to the observable that was running so that I don't have to ask the user to reenter their credentials of press the login button again.
To accomplish this I initially call doLogin(...) and temporarily save the returned observable in a data holder class. If the device goes through a configuration change I can grab the already created observable from the data holder class and resubscribe to it. This works great, my only hang up is that I need to also temporarily save off the username, password and saveUsername flag. This is easy enough to do, however I'm wondering if there's a way I can leverage RxJava to hold these values in the Observable and still have access to them when I need them in doOnNext(...). If I don't do this and just resubscribe to the Observable then when doOnNext(...) runs I won't have values for the saveUsername flag or the username which is obviously bad.
It would be really nice to only have to retain the Observable and somehow have it retain the username, password and saveUsername flag. Is there a way to accomplish this in RxJava or is the way I'm currently doing it the way it needs to be done if I want those variables to be retained during a configuration change?

Essentially, yes. RxJava uses a functional, stateless API, so you're not really able (or supposed) to attach additional data to an observable aside from the values it returns.
As with functional languages, there are generally two ways you can go about this:
You can either capture additional values in a closure, similar to how
you are doing it now. But obviously those values will only be
accessible within the scope of said closure, so you can't return an
Observable from a method and still access variables that were used to
create it later.
If you do need to access that data at a later point, the usual approach is to create some kind of result object that contains all your data. For example a "LoginResult" class, that contains your response as well as the original login data.

How to get collection from Meteor server with Android DDP?

Let me to start explain my problem. There is repository with some explanations, but there are no methods how to get collection or json file from Meteor server(only insert). Also author did not explain properly methods onDataChanged, onDataAdded etc.
public class Login extends Activity implements MeteorCallback{
public static Meteor mMeteor;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_login);
mMeteor = new Meteor(this, "some_socket_it_doesn't_matter");
mMeteor.setCallback(this);
}
}
public class ListOfElements extends ListFragment implements MeteorCallback{
#Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
String subscriptionId = Login.mMeteor.subscribe("notifications");
Log.d("Log", subscriptionId);
}
}
I didn't understand how i have to use subscription or how to get collection from server. Why there are only insert methods in github repository and no get? I really have no idea how make the code to get collection, use subscribe and so on. There are no any understandable explanations in the network. Please, can you help me with this by explaining how to realize getting, subscribing in this code.

There are two special things about Meteor: It works asynchronously and it has been designed specifically for real-time applications. Thus it has a few different concepts for retrieving data and for some other tasks.
In a synchronous application, you would just call insert(...) and immediately get the method's return value, e.g. a boolean value for success/error or a numeric value for the number of rows that have been inserted.
You would call get(...) and immediately receive a collection of rows as the method's return value.
But in Meteor, everything is asynchronous. This means that you get the results not immediately, but a few (milli)seconds later, in a callback method.
When you call insert(...), this is not so important, as you have noticed. You just call this method and often forget about the result, i.e. you don't wait and check for the result because insertions are usually successful. But this method is still asynchronous and you could (and sometimes should) listen for the result which will arrive a few (milli)seconds later, again.
When you want to call get(...), this would be possible in theory, with the important point again being that it's asynchronous. So you would say "get me all chat messages from the last 5 minutes". There would be no result or return value, as usual, but the result would arrive a short time later, asynchronously, in a callback method that you define. This is what onDataAdded(...), onDataChanged(...) and onDataRemoved(...) are for.
Now it's not clear, yet, why you can't call get(...) and wait for data to arrive in those methods.
The answer to that question is Meteor being designed for real-time applications. This is why you can't say "get me all chat messages from the last 5 minutes". Instead, you have to say "I want to subscribe to all chat messages from the last 5 minutes and always be updated about changes".
So, in Meteor, you subscribe to data sets instead of requesting them via get(...).
All in all, this means the following:
If you want to get some messages, you subscribe to your data set that holds those messages.
When the initial rows are sent (!) and whenever new rows are added to the collection, you receive those in your onDataAdded(...) callback. When rows are modified, you receive those changes in your onDataChanged(...) callback. And, finally, when rows are deleted, you are informed about those deletions in your onDataRemoved(...) callback.
When you don't want to get updates for your data set anymore, you unsubscribe from that set. This is optional.
With the Android-DDP library in your Android application, it translates to the following:
final String subscriptionId = mMeteor.subscribe("chats");
public void onDataAdded(String collection, String docID, String json) { ... }
mMeteor.unsubscribe(subscriptionId);
As you can see, what you have to learn is really Meteor and not the library Android-DDP. Meteor has some new concepts that one has to understand. But when you know how Meteor works, translating those things to Android-DDP is really simple and only a matter of looking up the method names.