Android Jetpack architecture for componentized application development

Project introduction

This project adopts componentization +MVVM architecture for development, separates functional components and business components, and communicates between components through ARouter. This article is a brief introduction to the technical architecture of the entire application.

Project address: github.com/winlee28/Je… Welcome to star

The main technical points

Kotlin+Jetpack+Coroutines+Retrofit+koin

Overall project architecture diagram:

Architecture. JPG

The host App does not have any business code, the whole business is split into various ft_lib modules. Some functional components are encapsulated and extracted as lib to provide upper-layer dependencies. Ft_lib has no task dependencies and communicates through Arouter.

Home page features

The home page is divided into 5 tabs, mainly for home page, project, navigation, system and mine.

The whole page frame is set up using BottomNavigationView + Navigation. Configure the bottom menu through menu. Use NavHostFragment to configure each fragment. The navigate method of the system-provided FragmentNavigator loads the fragment via replace. This causes fargment to repeatedly call the onCreateView method when switching tabs. This is certainly not what we need. We need to customize our FragmentNavigator to replace the system’s FragmentNavigator and load fragments using show and hide. This will be explained in a future series of articles.

Because the App uses the immersive status bar, only the immersion of the first fragment will be effective in the process of use, while the others are basically not. This problem should be solved from the system source code. The root cause is this code:

private WindowInsets brokenDispatchApplyWindowInsets(WindowInsets insets) {
        if(! insets.isConsumed()) { final int count = getChildCount();for (int i = 0; i < count; i++) {
                insets = getChildAt(i).dispatchApplyWindowInsets(insets);
                if (insets.isConsumed()) {
                    break; }}}return insets;
    }
Copy the code

It just breaks. So we also need a custom view to rewrite dispatchApplyWindowInsets method. The details will also be explained in subsequent articles.

The following is a brief introduction to the technical points of each Tab.

Home page

The home page is mainly divided into the top Banner and the bottom article list. The list is loaded using Paging. And encapsulates the AbsListFragment and AbsListViewModel to quickly build list pages. The AbsListFragment mainly encapsulates elements related to the layout of the page. The AbsListViewModel encapsulates common configurations of paging. We only need the DataSource and Adapter relationships to develop the list page using the two packages described above.

project

Project Tab mainly uses TabLayout and ViewPager2 to achieve linkage. Similarly, the ViewPager2 page directly inherits the AbsListFragment to implement the list page.

navigation

The navigation page is divided into search at the top and classification at the bottom. Click search to open a new page. Use fragments to host popular searches and search results. The bottom of the classification is mainly through RecyclerView+ViewPager2 to achieve. Slide the list by setting the orientation of ViewPager2 to ORIENTATION_VERTICAL.

system

Customize FlowLayout to manage Tag tags. It further encapsulates the TagFlowLayout and provides a TagAdapter to load the data.

All pull-down refresh and pull-down loading is done through SmartRefreshLayout. By reading Paging source code, we know that Paging will not continue to load data for us when the request data returns empty data. By default, Paging will assume that the data has finished loading. This logic is somewhat problematic in real development. So we need to manually load the paging logic when we return empty data. This is done using a custom DataSource. In fact, the Paging framework only provides the mode of loading data, and the logic of adding or deleting data is not supported. All of this can be done with a custom DataSource. The details will also be explained in subsequent articles.

Network request

This is done mostly by Retrofit+ coroutines. The data flow architecture of the entire application is as follows:

dataFLow.jpg

The caching function has not been added at present, and will be realized through room in the future.

Component communication

Component communication is implemented primarily through Arouter. This is done by defining the Service through the provided IProvider. Service implementations are defined in their respective Modules. We define ServiceImpl’s wrapper class in the Base module to be called by the caller so that the caller doesn’t need to care about the business logic and can use it directly.

Dependency injection

Because the App was developed using Kotlin, dagger2 was chosen over Koin, a practical lightweight dependency injection framework for Kotlin developers. Written in pure Kotlin, no agents, no code generation, no reflection.

Insert -koin. IO /#/quickstar…

The above is a brief introduction of the whole App function, and some technical points will be explained separately later.