UploadDataProvider

fun close(): Unit

Se llama cuando una solicitud ya no necesita este UploadDataProvider, de modo que los recursos (como un archivo) se puedan liberar de forma explícita.

abstract fun getLength(): Long

Si se trata de una carga no fragmentada, muestra la longitud de la carga. Siempre debe mostrar -1 si se trata de una carga fragmentada.

abstract fun read(uploadDataSink: UploadDataSink!, byteBuffer: ByteBuffer!): Unit

Lee los datos de carga en byteBuffer. Una vez completada, la posición del búfer se actualiza al final de los bytes que se leyeron. No se cambia el límite del búfer. Cada llamada a este método debe ir seguida de una sola llamada, ya sea síncrona o asíncrona, a uploadDataSink: onReadSucceeded si se realiza correctamente o onReadError si falla. No se llamará a read ni a rewind hasta que se llame a uno de esos métodos o al otro. Incluso si se cancela el UrlRequest asociado, se debe llamar a uno o al otro antes de que se puedan liberar los recursos de forma segura. Si se arroja una excepción, también se liberarán los recursos y se producirá un error en la solicitud.

Nota: Para las cargas no fragmentadas, se debe llamar a onReadSucceeded solo cuando la lectura se haya realizado correctamente y se haya leído al menos un byte en byteBuffer. Para las cargas fragmentadas (el tamaño de los datos es desconocido), se permite llamar a onReadSucceeded para el último fragmento con un búfer de bytes vacío.

abstract fun rewind(uploadDataSink: UploadDataSink!): Unit

Rebobina los datos de carga al principio. Se invoca cuando Cronet requiere que el proveedor de datos de carga esté en un estado equivalente a si aún no se llamó a read.

Para indicar que la operación finalizó, las implementaciones de esta función deben llamar a onRewindSucceeded para indicar el éxito o onRewindError si falla. Incluso si se cancela el UrlRequest asociado, se debe llamar a uno o al otro antes de que se puedan liberar los recursos de forma segura. Arrojar una excepción del método equivale a llamar a onRewindError. Si no se admite el rebobinado (por ejemplo, si se lee desde una transmisión única), se debe llamar a onRewindError de inmediato.

El implementador puede suponer de forma segura que no se emitirá una llamada read ni una llamada rewind simultánea hasta que notifique al receptor que finalizó el rebobinado, como se describe en el párrafo anterior.

Cronet usa este método de forma interna si el cuerpo debe subirse varias veces. Esto puede ocurrir en muchas situaciones diferentes, por ejemplo, cuando se siguen redireccionamientos o cuando se reintentan solicitudes después de un tiempo de espera o una desconexión de red. Ten en cuenta que, si bien la implementación del rebobinado suele ser opcional, las solicitudes que terminan requiriéndolo fallarán a menos que se implemente el rebobinado.