Source Code Analysis of Flutter Dio (Ⅱ) —— Comparison among ——Http client, Http and Dior
Flutter Dio source code analysis (3)- depth analysis
Flutter Dio source code analysis (4)-encapsulation
Flutter Dio source code analysis (1)-Dio introduces video tutorial.
Source code analysis of Dio (2)-HttpClient, Http, Dio comparative video tutorial
Flutter Dio source code analysis (Ⅲ)-video course of depth analysis
Flutter Dio Source Code Analysis (IV) —— Package Video Course
Github warehouse address
This article will teach you how to package a class library. Usually, we use wheels made by others in our work. This article will show you how to make your own wheels, and provide a new idea and method when other class libraries need to be packaged in the future.
In the last article, we learned the basic usage of Dior, request library comparison and source code analysis. We know the usage of Dior is simple, so why do we need packaging? There are two points as follows:
When the method of component library changes greatly and needs to be migrated, if it is used in many places, then every file used needs to be modified, which is very cumbersome and prone to problems.
When Dior library is not needed, we can easily switch to other network request libraries at any time. Of course, Dior currently has built-in adapters that support the use of third-party libraries.
Because an application is basically configured in a unified way, we can manage interceptors, converters, caches, unified error handling, proxy configuration, certificate verification and other configurations in a unified way.
Because our application will use network requests in every page, if a Dior is instantiated every time it is requested, it will only increase the unnecessary overhead of the system. However, once we create the same object every time we access it with singleton mode objects, we don't need to instantiate this object again.
This is a singleton pattern created by a private constructor of a static variable.
We uniformly set timeout, response time and BaseUrl.
Because both get () and post () requests will eventually call the request method inside Dior, but the incoming methods are different, so we define an enumeration type here and handle it with a method.
We simplify the Restful API style into a method, and express different request methods through DioMethod. In our usual development process, before the request, before the response and when there is an error, we need to do special treatment on some interfaces, so we need to use interceptors. Dior provides us with a custom interceptor function, which can easily intercept requests, responses and errors.
We found that although the Dio framework encapsulates a DioError class library, we can only customize it if we need to handle the returned error in a unified pop-up window or route jump.
When we send a request, we will encounter several situations. For example, we need to automatically add some specific parameters to the interface that does not start with open, and get a unified token that needs to be added to the request header.
Before requesting the interface, we can do some basic processing on the response data, such as customizing the response results and special processing on a single URL.
After reading the introduction of converter, we found that the function of converter is similar to that of interceptor, so why does converter still exist? There are two points:
Execution process: Request Interceptor >; & gt request converter >; & gt Initiate request >> Response converter >:> Response interceptor >:> Final result.
Can only be used for "PUT", "POST" and "PATCH" methods, because only these methods can carry the request body.
The return data that will be used for all requested methods.
In the development process, when the client deals with the server, it often uses a token for verification, because the logic of refreshing the token is different for each company. Let me give you a simple example here.
Why do we need the ability to cancel the request? If when our page sends a request, the user voluntarily exits the current interface or the data has not responded when the app application exits, then we need to cancel the network request to prevent unnecessary errors.
A short piece of text information generated by the server is sent to the browser, and the browser saves the cookie in a local text file in the form of kv, and will send the cookie to the server the next time it requests the same website.
Using cookies requires two third-party components, dio_cookie_manager and cookie_jar.
Because in our usual development process, we will encounter a situation. When making a network request, we hope to access the last data normally, so as to have a better experience for users, instead of displaying a blank page. This cache is mainly for the reference of network port cache in flutter combat.
Our memory cache will disappear after the program exits, so we use shared_preferences to cache the data on the disk.
When we use flutter to grab the package, we need to configure the Dior proxy. OnHttpClientCreate callback is provided by DefaultHttpClient and used to set the proxy of the underlying HttpClient.
Used to verify whether the website you are visiting is real. Provides security because certificates and additional domains are signed by the root certification authority.
Log printing is mainly to help us debug during development.