UploadDataProvider

fun close(): Unit

Appelée lorsque cette UploadDataProvider n'est plus nécessaire pour une requête, afin que les ressources (comme un fichier) puissent être libérées explicitement.

abstract fun getLength(): Long

S'il s'agit d'une importation non fragmentée, renvoie la longueur de l'importation. Doit toujours renvoyer -1 s'il s'agit d'une importation fragmentée.

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

Lit les données d'importation dans byteBuffer. Une fois l'opération terminée, la position du tampon est mise à jour à la fin des octets lus. La limite du tampon n'est pas modifiée. Chaque appel de cette méthode doit être suivi d'un seul appel, synchrone ou asynchrone, à uploadDataSink : onReadSucceeded en cas de succès ou onReadError en cas d'échec. Ni la lecture ni le retour en arrière ne seront appelés tant que l'une de ces méthodes ou l'autre n'est pas appelée. Même si la UrlRequest associée est annulée, l'une ou l'autre doit toujours être appelée avant que les ressources puissent être libérées en toute sécurité. La génération d'une exception entraînera également la libération des ressources et l'échec de la requête.

Remarque : Pour les importations non fragmentées, onReadSucceeded ne doit être appelé que lorsque la lecture a réussi et qu'au moins un octet a été lu dans byteBuffer. Pour les importations fragmentées (la taille des données est inconnue), il est autorisé d'appeler onReadSucceeded pour le dernier fragment avec un tampon d'octets vide.

abstract fun rewind(uploadDataSink: UploadDataSink!): Unit

Remet les données d'importation au début. Appelée lorsque Cronet exige que le fournisseur de données d'importation soit dans un état équivalent à celui où read n'a pas encore été appelé.

Pour signaler que l'opération est terminée, les implémentations de cette fonction doivent appeler onRewindSucceeded pour indiquer la réussite ou onRewindError en cas d'échec. Même si la UrlRequest associée est annulée, l'une ou l'autre doit toujours être appelée avant que les ressources puissent être libérées en toute sécurité. La génération d'une exception à partir de la méthode équivaut à appeler onRewindError. Si le retour en arrière n'est pas compatible (par exemple, si la lecture provient d'un flux unique), cette méthode doit appeler onRewindError immédiatement.

L'implémenteur peut supposer en toute sécurité qu'aucun appel read ni rewind simultané ne sera émis tant qu'il n'aura pas notifié au récepteur que le retour en arrière est terminé, comme décrit dans le paragraphe précédent.

Cette méthode est utilisée en interne par Cronet si le corps doit être importé plusieurs fois. Cela peut se produire dans de nombreuses situations différentes, par exemple lors du suivi des redirections ou lors de nouvelles tentatives de requêtes après un délai d'inactivité ou une déconnexion réseau. Notez que, bien que l'implémentation du retour en arrière soit généralement facultative, les requêtes qui finissent par en avoir besoin échoueront si le retour en arrière n'est pas implémenté.