U Want To Learn

Hello, everyone. Those who already read my posts they already know I have one whole series of Reactive Programming (What the hell is this )[Rx | Java | Android ] Season 1. Now in that series, I try to share my knowledge related to what is Rx and some of their essential concepts. If you are new, I will recommend you to read those that first will be good.

1. Observer Pattern – Reactive Programming Part1
2. Pull vs Push & Imperative vs Reactive Part2
3. Functional Interfaces, Default Methods, { Higher Order – Pure – Side Effects in } + Functions, Im + { Mutable } , Lambda Expression & Functional Programming Part3
4. War against Learning Curve of Rx Java 2 + Java 8 Stream Part4
5. Dialogue between Rx Observable and a Developer (Me) Part5
6. Continuation (Summer vs Winter Observable) of Dialogue between Rx Observable and a Developer (Me) Part6
7. Continuation (Observable Marriage Proposal to Observer) of Dialogue between Rx Observable and a Developer (Me) Part7
8. Confusion between Subject and Observable + Observer Part8

Now the question is what will be interesting in season 2 of Rx ( What the hell is this )[Rx|Android]?

Motivation:

Note: If you read my previous season. Then motivation which is available there that still valid for this season 2.

As we all know Android is open source and our evolution is community driven. No one body control the app development standards. Now, this is great, but that also create some problems and sometimes demotivate our community developers who are working solo or with small teams and no experienced team members. They faced a lot of issues. Like until now Google is recommending kind of MVVM architecture for an app, but they are not creating that as a Standard of Android apps. Instead, they are saying if you are using something else and that is working for you then stick with that. We can see these type of scenarios everywhere in our Android development. Instead, this is the same issue which we are facing with Rx in Android. Now Rx is again given by the community and Google never recommend this officially, but now in new libs, they are adding the support of Rx. It’s mean still we have something new which is not the standard but every employer expecting this from a developer. Now the issue raised when people start working as a solo, and they don’t have a proper mentorship. They need to learn on their own. They start trying different sources like medium articles. Now every post has there particular intention, but sometimes as an experienced developer, we learn the implementation not the purpose of the article which is really bad and occasionally fruitful. In my opinion, the same thing happen in the case of Rx in the Android community.
Like as we know, threading is not easy in Android due to lifecycle and Main UI thread management. To make this thing easy some of the smart community members give us the Retrofit with Rx. That is the massive relief for the developers especially for those developers who are working solo and have no excellent mentorship, no good resources but they learn from different sources how to use Retrofit. Now due to community-driven everyone start learning this from various sources and in the end, we are in the place where mostly developer start thinking using Retrofit with Rx adapter is Reactive programming. Later after some years, some developer starts knowing what they are doing that is not Reactive Programming, but we are using some concepts of Reactive Programming. Now, the next step is tough where this series may help. My primary goal is to differentiate between Retrofit Rx and how to use Reactive programming in Android or maybe we can say Practical use of Rx in Android.

Observable is not Rx:

I am expecting you guys already know what is Reactive Programming and if you are new or you want to revise please read my season 1 of this series.

I am going to copy paste one code block here.

interface GitHubRepositoryDataSource {
    Observable<List<GitHubUser>> getUsers();
    Observable<List<GitHubUserRepository>> getRepositories(String usename);

}

gitHubRepository.getUsers()
                 .subscribeOn(Schedulers.io())
                 .observeOn(AndroidSchedulers.mainThread())
                 .subscribe(gitHubUsers ->
                         {
                             homeAdapter.add(gitHubUsers);
                             progressBar.setVisibility(View.GONE);
                         },
                         error -> Toast.makeText(this, error.getMessage(), Toast.LENGTH_SHORT).show(),
                         () -> {
                         },
                         disposable -> this.disposable = disposable);

In above code blocks. I am using Retrofit2 with RxJava for API calls. It is a straightforward code, and I am expecting everybody aware of what this code block will do. So here I am not able to say this is a Reactive Programming code. Instead, I can say I am using some of the Reactive Programming concepts. Like in subscribe success code block I am using Imperative code.

 homeAdapter.add(gitHubUsers);
 progressBar.setVisibility(View.GONE);

Callback Confusion:

A lot of time I observe people give an argument about Rx use. There are no callbacks. That is also an important thing to remove this confusion. In Rx, we are not able to say there are no callbacks instead we can tell there are no callback hells, but callbacks are there like in the above code block we have callbacks also as shown below:

...
.subscribe(gitHubUsers ->
              { // Callback 1
               homeAdapter.add(gitHubUsers);
               progressBar.setVisibility(View.GONE);
               },

               // Callback 2
               error -> Toast.makeText(this, error.getMessage(), Toast.LENGTH_SHORT).show(),
                
               // Callback 3 
               () -> { },
               
               // Callback 4
               disposable -> this.disposable = disposable
);

Plan:

Now, there are two things, one Reactive Programming concepts and second how we can use these concepts into the practical world. For the first part, you can refer to season 1, and for the second part how to use Reactive Programming Practically in Android we will discuss in this season.

So I feel we can discuss first what are the pain points in learning and implementation of Reactive Programming.
1. Abstract thinking
2. Generics
3. Chaining
4. Imperative mindset
5. Stream ( Data + Event )

In my opinion above are the pain points which we need to resolve first.

Abstract Thinking:

This one is tough for me to explain here now. So I will tell once we are good with other pain points.

Generics:

Most developers don’t care about generics, and I feel working with generic you need to be good with Abstract thinking, and due to this, we are not able to apply Generics on our codebases. Which is ok but over time generics are more and more critical. For example in Kotlin we can write functional code, and we have some builtin functions ‘let’, ‘apply’, ‘also’, ‘run’, ‘with’ etc. these are really important, but if we are not good with generics we are not able to use these instead we can use, but we never feel comfort. So we will do focus on Generics once we start our next part.

Chaining:

In functional reactive programming, we use a lot of chaining of different operator or functions. Now, this is also one big pain point. First, these functions are mostly returning generics and second, they are changing output, and we are sending this new output as an input to the next function. Once we want to go with Reactive, we need to learn how to read chaining and how to implement everywhere. Also, this issue is dependent upon on our Imperative mindset which is our next point.

Imperative mindset:

Mostly developer who is doing development in this period. They learn Java, C++, PHP, etc which are imperative programming languages. Imperative programming mindset is the most significant pain point which requires our full attention. For example, if I am not able to achieve something in Reactive Programming, I start writing the Imperative code. Which is ok because we want to complete our tasks, but I feel we need to be strict with our self. We must do promise with ourself we will not write any imperative code; instead, we will invest more time to find out Reactive solution of the problem. We will discuss more this in the next part.

Stream ( Data + Event ):

In imperative programming we have Data and Event but once we are going to implement Reactive solution we need to remove this concept from our imperative mindset. In Reactive Programming, we have only one thing which is called stream. To make easy things I can say Stream = Data + Event but I don’t want to use this term Data + Event. Instead, we will use only one term stream.

Now all these pain points we will cover in all parts of this series. We will do some examples in which we will convert the imperative code block to Reactive. Then we will do to create our operators before going to start using a built-in one. That will help us to grab the knowledge of operators very fast. Then we will make a cheat sheet of problems and their solutions in Reactive Programming. That will be helpful for us.

Conclusion:

I hope this makes sense for you guys. If you have any suggestion or you feel due to my lack of knowledge, I missed something, or you think I am wrong in some place. Please feel free to raise that thing in the comments, and we will resolve our conflicts.

Again thanks for reading. Have a nice weekend :).

by