AFAAIK, Retrofit uses RxJava internally.Then what is the advantage of integrating Retrofit with RxJava externally like here, if I don't want to filter,sort or modify the data received from api?Does it reduces the time for fetching response from api?In what way does it helps in improving performance of our api calls?
Retrofit started as project before RxJava and you used to retrieve the API via callbacks. Then came RXJava and a more strict integration between the two was possible. So that you change Call<T> with an Observable/Flowable interface, and instead to use a call back into the code you retrieve the result directly exploiting the power of the reactive paradigm.
Please consider you have to specify you are using RXJava when you build Retrofit
Retrofit retrofit = new Retrofit.Builder()
.baseUrl(baseUrl);
.addCallAdapterFactory(RxJavaCallAdapterFactory.create())//here
.addConverterFactory(GsonConverterFactory.create())
.build();
Saying that RXJava implements internally Retrofit is kind of tricky, Retrofit remain indipendent, just RXJava offers some binding code so that you can adapt Retrofit2 to be an Observable.
This code taken from here, explain how to bind the two
public interface UserService {
#POST("/me")
Observable<User> me();
}
// this code is part of your activity/fragment
Observable<User> observable = userService.me();
observable
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.io())
.subscribe(new Subscriber<User>() {
#Override
public void onCompleted() {
// handle completed
}
#Override
public void onError(Throwable e) {
// handle error
}
#Override
public void onNext(User user) {
// handle response
}
});
Then you ask to many questions, in stackoverflow you get one reply per post.
Just please consider that the advantage of using RXJava and Retrofit integrated are a lot, for instance you have a come much more clean, testable and you do not have to consider concurrency issues. Regarding the performance I get is the same for a normal case.
EDIT:
To understand better when to use RXJAVA+Retrofit and when just Retrofit you can see this post
Outside from that content please consider that is really useful to see all the succesion in a functional way inside a single class, plus you have OnComplete, you can operate any sort of transformation.
Furthermore is much easier to combine multiple calls as here, the advantages are really clear in real life situations,
and also to do testing and maintain the code clean, that just taken alone these two, are two great advantages.
You also may want to explore the new Google Architecture functionalities components with Retrofit, where you can use both RXJava or LiveData
Related
I am building an android application. In which in need to handle multiple api calls in queue to avoid collision using retrofit and also i need to manage this in common Applicationclass. It is possible?
You can achieve this using RxJava and Retrofit. RxJava provides us zip operator.
Sample code for this would be in your repository class
Observable.zip(
getCricketFansObservable(),
getFootballFansObservable(),
BiFunction<List<User>, List<User>, List<User>> { cricketFans, footballFans ->
// here we get both the results at a time.
return#BiFunction filterUserWhoLovesBoth(cricketFans, footballFans)
})
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(getObserver())
I am working on an application, where I had used Rx-android and Retrofit to do the network request, but now there is a requirement in the project where I have to do the nested network calls.I tried to google it out but didn't found any good article.If any one has worked on such topic then please let me know your findings.
Assuming you're using retrofit with the rxjava adapter:
fun firstRequest(): Single<Response<String>>
fun secondRequest(idFromFirstRequest: String): Single<Response<ResponseBody>>
Use flatmap operator to chain the network calls:
firstRequest()
// do more operators on the request, like transforming the object, or showing it first on the ui
.flatMap { stringId -> secondRequest(stringId) }
// you can flatMap here again to chain another network requests
// .flatMap { thirdRequest() }
// .flatMap { fourthRequest() }
// and so on...
There are various articles related to API chaining, and the easiest way to achieve is using Rx-Java approaches
1) Using RxJava Zip operator (for parallel requests)
2) Using RxJava flatMap() operator(To request serially one after another)
Refer these two links for more detail examples
Synchronizing Network Calls With RxJava
Multiple api request using retrofit and rx java
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.
There is conflicting information about when and whether to use subscribeOn with Retrofit.
Here is an answer saying to not use subscribeOn.
Here is an answer seeming to imply that subscribeOn has no good default set.
Here is example code using subscribeOn.
So, once for for all, when should I use subscribeOn and with what thread? What are the possible ramifications of using or not using subscribeOn?
apiService.issueRequest()
// Is this useful? Required? Bad practice?
.subscribeOn(Schedulers.io())
// Do actions on main thread
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Action1<Response>() {
#Override public void call(Response response) {
handleResponse(response);
});
In the current version of Retrofit (1.9.0), Retrofit use his own executor to perform the http call and don't use the executor backed by the schedulers given by the subscribeOn method.
In your case, the scheduler will be used only to execute the code that will add your http call to the executor used by retrofit. (So it's a bit useless...)
BUT, regarding the actual code from Retrofit on Github, retrofit stop to use his executor, so it may be possible to used a RxJava scheduler instead.
I am referencing this post Where to keep Retrofit Adapter in Android App? but I am not allowed to comment there due to stackoverflow limitations [thank you stackoverflow for treating new users like kids].
Where does the Retrofit RestAdpater go when using Android? Can anybody please elaborate on #Jake Wharton 's answer of above post.
When I place the RestAdapter in my Activity, it will probably get GCed when the Activity is destroyed, so the Singleton loses its reference and needs to be recreated the next time (I assume).
Further, the first thing that I did for testing is exactly this and Android tells me I cannot do a network request on the Main thread. I understand that I can't do that, but I thought Retrofit would automatically create a separate thread for me.
Will I need to create an AsyncTask to host the RestAdapter? Or how exactly does this work for Android? Where is the adapter best instantiated? Which is the recommended point to attach the Retrofit reference?
So what #JakeWharton was saying is that the RestAdapter and the api interface instances should be created once. How you achieve that is pretty much an implementation details.
In a straight forward manner you could create a class which would hold a single instance to your RestAdapter. You would be responsible of making only a single instance of that class. You'd probably want to hold a reference to this class in your Application class. You could also approach this using the Singleton pattern
Here's a small class to get you started. I took this from a previous post which you can see here
public class RestApiDispencer {
private Map<String, Object> restApiInstances = new HashMap<String, Object>();
private RestAdapter restAdapter;
public RestApiDispencer(RestAdapter restAdapter) {
this.restAdapter = restAdapter;
}
public <T> T getRestApi(Class<T> clazz) {
T client = null;
if ((client = (T) restApiInstances.get(clazz.getCanonicalName())) != null) {
return client;
}
client = restAdapter.create(clazz);
restApiInstances.put(clazz.getCanonicalName(), client);
return client;
}
}
If you're familiar with dependency injection then that would be another way to go. Personally I prefer to use dependency injection when it comes to hiding implementation details from use.
Creating the RestAdapter directly into your Activity would not the way you'd want to go. Instead in your activity would want to get a reference to this RestApiDispencer class from above and have it return the instance of the rest api of your choise by providing its class like so.
MyClassApi myClassApi = restApiDispencer.getRestApi(MyClassApi.class);
There are other ways to achieve this but as I said it's up to you to decide which implementation fits best your needs.
As for Retrofit doing request on a separate thread, yes it does but you need to create your Api interfaces accordingly.
#GET(/some/rest/api/path)
Response getApiData() // Synchronous declaration as the Response is returned from the method.
#GET(/some/rest/api/path)
void getApiData(Callback<Response> callback); // Asynchronous as the Response is delivered in the callback.
#GET(/some/rest/api/path)
Observable<Response> getApiData(); // Asynchronous again but you'll need to read up on rx-java before using this.
Read on rx-java here
So if you do decide to create your rest api by using the asynchronous signature then you won't have to worry about threading when invoking your interface. If you use the synchronous signature then it's all up to you.