Demand background
Following the previous article " Flutter Download - 1| flutter_download_manager Source Code Analysis ", the usage and principle of flutter_download_manager are introduced in detail. As mentioned in the advantages and disadvantages, this library is implemented purely in Dart and supports download management, pause, resume, cancellation and breakpoint resuming. One disadvantage is that the network library is strongly coupled with dio and does not support custom network library extensions.
Some people will say: dio is so awesome, why don’t you just use it directly? Why do you need to support other network libraries? Don’t mess around with it if you have nothing to do.
I want to say:
- The world has more than one voice, otherwise it would be boring.
- Third-party libraries are black boxes for the application itself. Developers generally neglect to pay attention to the impact of their functional changes on the application unless a major accident occurs. This uncontrollable situation should be cautious.
- The design follows the DIP principle. Abstraction should not rely on specific implementation details. Specific details rely on abstraction. We need an abstract network layer to depend on the project rather than directly relying on dio.
- Quickly switch to other network libraries.
This article will start from the current situation and take you step by step to decouple the network library in flutter_download_manager.
Current status statement
Get an overall understanding of the flutter_download_manager class design process from the class diagram and summarize the strong coupling of dio, and then explain it in detail through the code.
Class diagram embodiment
Code reflection
Coupling point one: dio.CancelToken
dio:CancelToken is used in each download task request to indirectly implement the task cancellation function through the dio network library.
Coupling point two: dio.download
cancelToken.cancel() depends on CancelToken
As shown in the abbreviated code above, the call chain relationship, the final call chain and the summary of dependencies on dio:
The dependence of the download library on dio is: CancelToken and download methods .
How to customize the network library
Through the above analysis and summary of the current situation, combined with the basic principles of design: packaging changes will isolate the unchanged from the changes. The changes are the download of the network library, CancelToken and cancellation functions. Only this part of the change is encapsulated, and the network library download and Token are abstracted and encapsulated.
1. Network layer design
Purpose : To decouple flutter_download_manager from dio.download.
Idea : Abstract network-related operations into interfaces and inject dependencies into the downloadManager object.
Implementation steps :
- abstract network layer interface
Considering that download returns objects in Future, because response.statusCode will be used, dynamic is used directly here. Specifically, it can be refined and encapsulated into DownloadResponse, which contains the statusCode attribute.
- customhttpclient is passed into DownloadManager through dependency injection, so that it does not rely on specific implementation but relies on abstraction. Dependency injection realizes the combination relationship between objects to improve scalability.
2. CancelToken design
Purpose : Decouple flutter_download_manager from dio.CancelToken.
Idea : CancelToken is closely related to getting messages, and a cancel method must be provided for use by methods such as pause in downloadmanager. Considering that the CancelToken structure of each custom_http_client is different and the cancellation method naming diversity principle, a unified DownloadCancelToken interface is designed here to provide the cancel method and proxy the implementation to the CancelToken object of the specific network library.
Implementation steps :
- Abstract a Token object and provide a cancel method, and implement a Proxy class that defaults to proxy other network libraries.
Tip: Use Function.apply because it supports the passing of positional parameters and optional parameters.
- Custom_http_client abstracts a DownloadCancelToken abstract interface for external use
3. Downloader design
Purpose: Decoupling the downloader from the specific implementation of downloadmanager
Idea: downloadmanager provides common download methods such as addDownload and download management logic abstraction. This existential change can be implemented in many ways, and is also abstracted.
Implementation steps:
- The downloader is abstracted into an interface
- downloadManager depends on IDownloader
At this point, the customizable network library transformation has been completed, and then the isolation of the dio network can be implemented.
Network library isolation effect
Just inject it into DownloadManager through dependency injection.
This completes the expansion and transformation of the network library of flutter_download_manager, and implements a customizable network framework download library.
Summarize
Before implementing the opening and closing principle, the most important thing is to clarify the changes and invariances in the code based on the minimum implementation model.
❤️This article was originally written by Programming Blackboard . Welcome to follow the public account of the same name. Original technical articles will be pushed out as soon as possible❤️