Take you to appreciate the charm of Clean architecture, which is explained by Tencent T3

It seems better than the picture above. Do you know why? Because there are many fewer words. ha-ha. The following content and my open source project are written on this basis. Explain it separately.

Presentation layer

Our presentation layer here is based on MVP. Personally, I think Clean itself is more abstract and independent on the basis of MVP. Familiar MVP students know very well what this layer is used for. The old rule, first picture.

[external chain picture transfer failed. The source station may have anti-theft chain mechanism. It is recommended to save the picture and upload it directly (img-e4exjvtx-1631769638694)( https://user-gold-cdn.xitu.io/2017/9/27/ccccf90377a0baa49d63141cdd1a487f?imageView2/0/w/1280/h/960/ignore -error/1)]

Does it look familiar? The P layer makes the V layer (Fragment and Activity) have no other logic except UI logic. The Presenter in my open source project consists of multiple interactors. It will be introduced below.

Domain layer

[external chain picture transfer failed. The source station may have anti-theft chain mechanism. It is recommended to save the picture and upload it directly (img-tfzj2mct-1631769638696)( https://user-gold-cdn.xitu.io/2017/9/27/1950f115073f471ca4b9beb4bc4f88cc?imageView2/0/w/1280/h/960/ignore -error/1)]

It is obvious from the figure that the implementation classes and business objects of the interactor are mainly used here. It's reasonable to say that this should only belong to the java module, but sometimes our business objects may have to implement the entity class interface in the third-party library and have to be changed to the Android module. I didn't think of a good way for the time being. Anyone who knows can give me some advice.

Data layer

[external chain picture transfer failed. The source station may have anti-theft chain mechanism. It is recommended to save the picture and upload it directly (img-qgrncv00-1631769638697)( https://user-gold-cdn.xitu.io/2017/9/27/797ee7d22b857162e258f0432d996c08?imageView2/0/w/1280/h/960/ignore -error/1)]

This is a Repository model. See [here] for details(

). In my current opinion, I can only say that as long as the project is complex and needs to be layered, this mode should be used to make the clean architecture of clean more eye-catching.

This is originally a concept. I believe you don't want to see it, so let's briefly introduce it. If you want to know more, you can stamp [here](

).

summary

Now let's talk about my own opinion. The latter is a more specific Android compliant structure than the former. Insert a dependency rule of the clean architecture: the inner layer cannot rely on the outer layer. The three also explain what they are used for, so Why are they divided into the three, and what is the relationship between them? I'm a layman, so I should use the common saying to use r from the data layer The Repository mode makes the domain layer not feel the existence of the data access layer, that is, the original data is independent, and the business rules do not bind the specific data. Generally speaking, what data do you want? I get it for you, but you don't need to know where I get it; therefore, the domain layer knows nothing about how the data layer is implemented, and the main work of the domain layer is that you give me the data, I'll use it. How to use it? It's up to me to decide. After I use it, I call back to the presentation layer to render the UI. Therefore, most of the business logic is in the domain layer, which can be said to be the core of an APP. I think a very important design concept here is data-driven UI. I want to praise myself, ha ha. In fact, if you already have some 13 numbers in mind here, You can skip to Why, because how to use is already a concrete thing, and the architecture itself is a consensus and abstract. From the perspective of Java, you can implement this interface with multiple classes. The following use is just a code embodiment of my understanding of the clean architecture.

How

The following example is from my open source library [CrazyDaily](

)Take Zhihu daily as an example.

Data layer

The data layer is to take data from our Repository, which can be taken from the cloud, disk or memory.

public interface ZhihuService {
    String HOST = "http://news-at.zhihu.com/api/4/";

    @GET("news/latest")
    Flowable<ZhihuNewsEntity> getZhihuNewsList();

    @GET("news/{id}")
    Flowable<ZhihuNewsDetailEntity> getZhihuNewsDetail(@Path("id") long id);
}

public class ZhihuDataRepository implements ZhihuRepository {
    ...
    @Inject
    public ZhihuDataRepository(HttpHelper httpHelper) {
        mZhihuService = httpHelper.getZhihuService();
    }
    @Override
    public Flowable<ZhihuNewsEntity> getZhihuNewsList() {
        return mZhihuService.getZhihuNewsList()
        ...
    }
    ...
}

The embarrassing thing here is that only cloud data is provided, and the framework of retrofit+okhttp is used to obtain it. The correct way is to provide a Factory to ZhihuDataRepository instead of HttpHelper, and the Factory obtains the corresponding data according to different conditions. For example:

 @Inject
  UserDataRepository(UserDataStoreFactory dataStoreFactory,
      UserEntityDataMapper userEntityDataMapper) {
    this.userDataStoreFactory = dataStoreFactory;
    this.userEntityDataMapper = userEntityDataMapper;
  }

UserDataStoreFactory is a factory class that obtains data from different places. UserEntityDataMapper is our data wrapper class. Don't you remember the Interface Adapters above? Careful friends can notice that ZhihuDataRepository implements zhihrepository, but zhihrepository is not a data layer thing, but a domain layer thing. Obviously, it is entered by interface Line correlation, but content independence. Yes, this is the legendary dependency inversion principle.

[external chain picture transfer failed. The source station may have anti-theft chain mechanism. It is recommended to save the picture and upload it directly (img-jjbjsqel-1631769638699)( https://user-gold-cdn.xitu.io/2017/9/27/f6374b51c60eeaf235aea664d94309b3?imageView2/0/w/1280/h/960/ignore -error/1)]

Domain layer

public interface ZhihuRepository {

    Flowable<ZhihuNewsEntity> getZhihuNewsList();

    Flowable<ZhihuNewsDetailEntity> getZhihuNewsDetail(long id);
}

public abstract class UseCase<T, Params> {

    ...

    public UseCase() {
        ...
    }

    protected abstract Flowable<T> buildUseCaseObservable(Params params);

    public void execute(Params params, DisposableSubscriber<T> subscriber) {
        ...
    }
    ...
}

public class ZhihuNewsListUseCase extends UseCase<ZhihuNewsEntity, Void> {

    private final ZhihuRepository mZhihuRepository;

    @Inject
    public ZhihuNewsListUseCase(ZhihuRepository zhihuRepository) {
        mZhihuRepository = zhihuRepository;
    }

    @Override
    protected Flowable<ZhihuNewsEntity> buildUseCaseObservable(Void aVoid) {
        return mZhihuRepository.getZhihuNewsList()
        ...
    }
}

It's really perfect. It has nothing to do with the data layer. It uses the interface to control the data layer. It really feels that the architecture is becoming more and more interesting. I can handle most of our business logic here.

Presentation layer

@ActivityScope
public class HomePresenter extends BasePresenter<HomeContract.View> implements HomeContract.Presenter {

    private ZhihuNewsListUseCase mZhihuUseCase;
    ...

    @Inject //Multiple usecases
    public HomePresenter(ZhihuNewsListUseCase zhihuUseCase ...) {
        mZhihuUseCase = zhihuUseCase;
        ...
    }

    @Override
    public void getZhihuNewsList() {
        mZhihuUseCase.execute(new BaseSubscriber<ZhihuNewsEntity>() {
            @Override
            public void onNext(ZhihuNewsEntity zhihuNewsEntity) {
                mView.showZhihu(zhihuNewsEntity);
            }
        });
    }
}

public interface HomeContract {

    interface View extends IView {

        void showZhihu(ZhihuNewsEntity zhihuNewsEntity);
        ...
    }

    interface Presenter extends IPresenter<View> {

        void getZhihuNewsList();
        ...
}



### end of document

For many junior and intermediate Android As far as engineers are concerned, if they want to improve their skills, they often grope and grow by themselves. The learning effect of fragmentation is inefficient, long and helpless. These architecture technologies hope to Android Development friends have reference and avoid detours. The focus of this paper is whether you have harvest and growth. The rest is not important. I hope readers can keep this in mind.

Finally, if you want to get a high salary to improve your technology and get a qualitative leap in salary, the quickest way is that someone can take you to analyze together, which is the most efficient way to learn. Therefore, in order for you to smoothly advance to middle and senior architects, I specially prepared a set of excellent products such as source code and framework video for master learning Android Architect tutorial to ensure that your salary will rise to a higher level after you learn it.

When you have a learning route, what to learn, and know how to go in the future, you always have to practice when you see too much theory.
**[CodeChina Open source projects:< Android Summary of study notes+Mobile architecture video+Real interview questions for large factories+Project practice source code](

)**

**Advanced learning video**

![](https://img-blog.csdnimg.cn/img_convert/4f1488144bf0e4b377a004e20d7afd84.png)

**Attached: We collected 20 sets of first and second tier Internet companies because of autumn recruitment Android Interview questions** (contain BAT,Xiaomi, Huawei, meituan, Didi) and I sort it out Android Review notes (including Android Basic knowledge points Android Expand knowledge points Android Source code analysis, design pattern summary Gradle Summary of knowledge points and common algorithm problems.)

![](https://img-blog.csdnimg.cn/img_convert/4751e4d1c7abe41f7e66927ee4fbee1c.png)

*Attached: We collected 20 sets of first and second tier Internet companies because of autumn recruitment Android Interview questions** (contain BAT,Xiaomi, Huawei, meituan, Didi) and I sort it out Android Review notes (including Android Basic knowledge points Android Expand knowledge points Android Source code analysis, design pattern summary Gradle Summary of knowledge points and common algorithm problems.)

[External chain picture transfer...(img-KJbjb1Ud-1631769638702)]

Tags: Java Android Design Pattern

Posted on Fri, 17 Sep 2021 11:41:30 -0400 by MikeNye