Why should we bring DAGGER2,MVP and Rxjava into the project?

1
Why?

Why should we bring DAGGER2,MVP and Rxjava into the project?

There is no doubt that these three technologies are often mentioned in the Android development circle, so many articles and open source projects are introduced to them, using them, and developers are more or less being driven to use them in their own projects, but before using them we know why to use them, Can they bring us any benefit, or just follow the trend

In fact, most of our projects are not available to them, or the demand for these technologies is not very large, why do we say so?

Most developers are actually in the development of a small number of functional modules, for these projects, in fact, the benefits of using these technologies compared to the time spent in the development of the cost is not really high, because learning these will have a learning curve, and these techniques will not allow you to develop faster, Instead, you can write a lot more code, such as MVP and Dagger, which will allow you to write more classes and interfaces.

So it's not like we're developing small projects that we don't feel the benefits of these technologies, and why do we have to introduce these technologies?

Then why are these technologies so hot?

In fact, most of these puzzles appear on the developers who have been doing small projects with less function modules, as long as you have done a larger project, as the code increases you will encounter code coupling, team collaboration conflict resolution, class dependency complexity and so on, in fact, these technologies are to solve these problems, So there's a lot of big projects for these technologies.

What do these technologies appear to solve?

To use a technology flexibly, it is necessary to understand why these technologies appear, to solve any problem

2

Mvp

MVP article a lot, I do not do too much introduction here, my personal understanding is decoupling and extension and teamwork, most of the articles are just about how to write the MVP interface, we do not understand why use them, even if they will write and just do copy and paste

Give me a chestnut.

We need the user to click on the button to get a news message from the network to the TextView, if all in the activity to do these things, OK, very cool, do not write more MVP-related interfaces and classes, snapped and finished

But we now need to change, we want to join the cache, and not textview display, use toast Display, now go to change activity, although trouble, but no problem is you write, change also no problem, but this if not you write, you now go to change, to the logic to look again, Before re-modifying the code, if the logic of a complex, you re-read the logic to time, and if the wrong, will affect the previously written function, which completely violates the open and close principle

But we use MVP to develop, we can narrow these problems, we only need to add the cache logic in the model layer, because the presenter layer is the model interface, he only cares about the model layer returned data, as to how your interface is implemented, Does your data get from a network or a database or a local file, you don't have to care

Presenter get is also the view interface, presenter from the model to get the data, return to view, finished his work, he does not have to control the view is how to achieve, use TextView display or toast display, these are view things , so they only use their own things to do the right thing at all.

So we can take View,presenter,model to three different people to write, the need to change will not affect the entire code, the problem is minimized, such as UI requirements change we only use the view layer changes, the problem can be positioned immediately, and easy to test

3

Dagger

Dagger the threshold of the individual think in these three is the highest, related articles are many, but many just tell you how to write these classes, annotations how to use, a lot of did not say why not directly new, why to make such a simple thing so complicated? Actually, it's still about the size of the project. Because the problem it solves is the need for big projects.

Give me a chestnut.

We now need a class called Car,car in Need to hold an object called people, people also need to hold the key object, Ok, this is not simple

Car car = new Car(new People(new Key()));

But the reality of the big project is this.

A a = new A();B b = new B(a);C c = new C(a,b);D d = new D(c);E e = new E(a,b,d);

Just for example, building an e, building a bunch of other objects, and building the other objects is equally complex and must be built in order, with different life cycles for the objects, some of which may be like Activity, some of which may be singleton, So in the construction of the time to consider the object declaration cycle, consider the source of the object, in large projects, it is very painful, not only with the old fire, others see the code and look at the same Bible

So it comes in handy to rely on the injection framework at this time, and we just use focus on how to implement the function, the object's dependencies, and the life cycle, and let it help us manage, a inject that will help us inject the objects we need in terms of dependencies, and it will manage the life cycle of each object. It's not going to repeat new until the life cycle is over.

So dagger is very suitable for large projects, small project developers because of the low complexity of the project, did not encounter these problems, so will not understand why to use dagger, so simple new, to become so complex

4

RxJava

Mention Rxjava most people are used to deal with, thread scheduling, callback hell, plus retrofit and support Rxjava, so most developers will only in the request network and need to switch threads when the use of Rxjava, in fact, it has a most important feature, it can make the flow of data more intuitive, Clearer code

Give me a chestnut.

For example, a large project, the entire process of an event may have to go through a lot of methods, method set method, the location of each method pieces, a way to jump in to see, jumping over to jump over very easy to head dizzy, not intuitive, but Rxjava can all the logic with the chain to add the way of the closed package, What to do, who is in front of the very intuitive, logical clear, maintenance will be very easy, even if you do not write you can quickly understand, you can see it as a river, the whole process is to do the inside of the water to do processing, Knowing this feature, we know how important it is to use Rxjava in complex logic.

Conclusion

Learning new technology, we should not blindly follow the follow-up, if we do not know why this technology appears, is to solve what, we do not know why use it, we even in the project can not be used flexibly, very simple use, copy and paste some template code, also can not expand their thinking

While these techniques are better suited for large projects, it is recommended that developers start using them, using them to expand their thinking, consider coupling, scaling, teamwork, and so on, and if you have repeated the simplest way to write your project and don't think about it, you are 5 years of experience, It's just a 5-year repetition of a first-year experience.

Finally, we introduce a framework that combines mvp,dagger,retrofit,rxjava and other technologies for rapid development, and if you want to build a new project using these techniques, change the package name to use it directly, including detailed documentation, compared to the long learning curve of these techniques, Don't we learn them in practice faster? Later I will write an article about how it combines Mvp,dagger and uses it in the project

Finally, a framework for author Open Source:

Mvparms an MVP Quick build framework

Https://github.com/JessYanCoding/MVPArms/wiki

Why should we bring DAGGER2,MVP and Rxjava into the project?