Descarga de Flutter Capítulo 2 | Cuando el descargador encuentra un cambio de biblioteca de red

Antecedentes de la demanda

Siguiendo el artículo anterior " Descarga de Flutter - 1 | Análisis del código fuente de flutter_download_manager ", se presenta en detalle el uso y el principio de flutter_download_manager. Como se mencionó en las ventajas y desventajas, esta biblioteca se implementa exclusivamente en Dart y admite administración de descargas, pausa, reanudación, cancelación y reanudación de puntos de interrupción. Una desventaja es que la biblioteca de red está fuertemente acoplada con dio y no admite extensiones de biblioteca de red personalizadas.

Algunas personas dirán: dio es increíble, ¿por qué no lo usas directamente? ¿Por qué necesitas admitir otras bibliotecas de la red? No juegues con él si no tienes nada que hacer.

Quiero decir:

1. El mundo tiene más de una voz, de lo contrario sería aburrido.
2. Las bibliotecas de terceros son cajas negras para la aplicación en sí. Los desarrolladores generalmente no prestan atención al impacto de sus cambios funcionales en la aplicación a menos que ocurra un accidente grave. Esta situación incontrolable debe ser cautelosa.
3. El diseño sigue el principio DIP. La abstracción no debe depender de detalles de implementación específicos. Los detalles específicos dependen de la abstracción. Necesitamos una capa de red abstracta que dependa del proyecto en lugar de depender directamente de dio.
4. Cambie rápidamente a otras bibliotecas de red.

Este artículo comenzará con la situación actual y lo llevará paso a paso para desacoplar la biblioteca de red en flutter_download_manager.

Declaración de estado actual

Obtenga una comprensión general del proceso de diseño de clases flutter_download_manager a partir del diagrama de clases y resuma el fuerte acoplamiento de dio, y luego explíquelo en detalle a través del código.

Realización del diagrama de clases

Reflexión de código

Punto de acoplamiento uno: dio.CancelToken

dio:CancelToken se utiliza en cada solicitud de tarea de descarga para implementar indirectamente la función de cancelación de tarea a través de la biblioteca de red dio.

Punto de acoplamiento dos: dio.download

cancelToken.cancel() depende de CancelToken

Como se muestra en el código abreviado anterior, la relación de la cadena de llamadas, la cadena de llamadas final y el resumen de dependencias de dio:

La dependencia de la biblioteca de descarga de dio es: CancelToken y métodos de descarga .

Cómo personalizar la biblioteca de red

A través del análisis anterior y el resumen de la situación actual, combinado con los principios básicos del diseño: los cambios de empaque aislarán lo inalterado de los cambios. Los cambios son la descarga de la biblioteca de red, CancelToken y funciones de cancelación. Solo se encapsula esta parte del cambio, y la descarga de la biblioteca de red y el token se abstraen y encapsulan.

1. Diseño de capa de red

Propósito : Desacoplar flutter_download_manager de dio.download.

Idea : abstraiga las operaciones relacionadas con la red en interfaces e inyecte dependencias en el objeto downloadManager.

Pasos de implementación :

1. interfaz de capa de red abstracta

Teniendo en cuenta que la descarga devuelve objetos en el futuro, debido a que se usará Response.statusCode, aquí se usa directamente la dinámica, específicamente, se puede refinar y encapsular en DownloadResponse, que contiene el atributo statusCode.

2. customhttpclient se pasa a DownloadManager mediante inyección de dependencia, de modo que no depende de una implementación específica sino de la abstracción. La inyección de dependencia implementa la relación de combinación entre objetos para mejorar la escalabilidad.

2. Diseño de CancelToken

Propósito : desacoplar flutter_download_manager de dio.CancelToken.

Idea : CancelToken está estrechamente relacionado con la recepción de mensajes y se debe proporcionar un método de cancelación para que lo utilicen métodos como pausar en el administrador de descargas. Teniendo en cuenta que la estructura CancelToken de cada cliente_http_personalizado es diferente y el principio de diversidad de nombres del método de cancelación, aquí se diseña una interfaz DownloadCancelToken unificada para proporcionar el método de cancelación y proxy de la implementación al objeto CancelToken de la biblioteca de red específica.

Pasos de implementación :

1. Resuma un objeto Token y proporcione un método de cancelación e implemente una clase Proxy que de forma predeterminada actúe como proxy de otras bibliotecas de red.

Consejo: utilice Function.apply porque admite el paso de parámetros posicionales y parámetros opcionales.

2. Custom_http_client abstrae una interfaz abstracta DownloadCancelToken para uso externo

3. Diseño del descargador

Propósito: Desacoplar el descargador de la implementación específica del administrador de descargas

Idea: downloadmanager proporciona métodos de descarga comunes, como addDownload y abstracción de la lógica de administración de descargas. Este cambio existencial se puede implementar de muchas maneras y también se puede abstraer.

Pasos de implementación:

1. El descargador se abstrae en una interfaz.

2. downloadManager depende de IDownloader

En este punto, se ha completado la transformación de la biblioteca de red personalizable y luego se puede implementar el aislamiento de la red dio.

Efecto de aislamiento de la biblioteca de red

Simplemente inyéctelo en DownloadManager mediante inyección de dependencia.

Esto completa la expansión y transformación de la biblioteca de red de flutter_download_manager e implementa una biblioteca de descarga de marco de red personalizable.

Portal de código fuente completo

Resumir

Antes de implementar el principio de apertura y cierre, lo más importante es aclarar los cambios e invariancias en el código en función del modelo de implementación mínimo.

❤️Este artículo fue escrito originalmente por Programming Blackboard . Bienvenido a seguir la cuenta pública del mismo nombre. Los artículos técnicos originales se publicarán lo antes posible❤️