Montrant les progrès réalisés en pourcentage alors que le téléchargement et le téléchargement à l'aide de classe HttpWebRequest

Vous allez avoir besoin de savoir quelques petites choses pour être un succès.

Étape 0: conserver la documentation .NET 4.0 pratique:

• HttpWebRequest
• HttpWebResponse

Si vous regardez la HttpWebRequest de la documentation, vous verrez que GetResponse() a deux même nom de méthodes: BeginGetResponse() et EndGetResponse(). Ces méthodes utilisent la plus ancienne .NET un système modèle, connu comme "le modèle IAsyncResult". Il y a des milliers de pages de texte sur ce modèle, et vous pouvez lire des tutoriels si vous souhaitez obtenir des informations détaillées. Voici le crash course:

1. Pour une méthode Foo(), il y a un BeginFoo() qui peuvent prendre des paramètres et doit retourner un IAsyncResult mise en œuvre. Cette méthode effectue la tâche Foo() effectue, mais fait le travail sans bloquer le thread courant.
2. Si BeginFoo() prend un AsyncCallback paramètre, il attend de vous fournir un délégué elle appellera quand il est terminé. (C'est l'un de plusieurs façons, à savoir que c'est fini, mais se trouve être la technique HttpWebRequest utilise.)
3. EndFoo() prend la IAsyncResult retourné par BeginFoo() en tant que paramètre et retourne la même chose Foo() retourne.

Ensuite, il y a un piège dont vous devriez être au courant. Les contrôles ont une propriété appelée "fil d'affinité", et cela signifie qu'il n'est valable que pour interagir avec un contrôle si vous travaillez sur le thread qui a créé le contrôle. Ceci est important, parce que la méthode de rappel que vous donnez à BeginFoo() n'est pas garanti d'être appelé à partir de ce thread. C'est en fait très facile à gérer:

• Chaque champ a un InvokeRequired de la propriété qui est la seule propriété de l'appeler à partir du fil conducteur de mal. Si elle renvoie true, vous savez que vous êtes sur un dangereux fil.
• Chaque champ a un Invoke() méthode qui accepte un délégué paramètre et appellent le délégué sur le thread qui a créé le contrôle.

Avec tout ce qui est hors de la voie, nous allons commencer à chercher un peu de code que j'ai écrit dans une simple application WinForms rapport à la progression du téléchargement de la page d'accueil Google. Cela devrait être similaire à un code qui permettra de résoudre votre problème. Ce n'est pas la meilleur code, mais il illustre les concepts. La forme d'une barre de progression nommé progressBar1, et j'ai appelé GetWebContent() à partir d'un clic sur un bouton.

HttpWebRequest _request;
IAsyncResult _responseAsyncResult;

private void GetWebContent() {
    _request = WebRequest.Create("http://www.google.com") as HttpWebRequest;
    _responseAsyncResult = _request.BeginGetResponse(ResponseCallback, null);           
}

Ce code commence la version asynchrone de GetResponse(). Nous avons besoin de stocker de la demande et de la IAsyncResult dans les champs car ResponseCallback() besoins à l'appel de EndGetResponse(). Tout en GetWebContent() est sur le thread de l'INTERFACE utilisateur, donc si vous voulez mettre à jour des contrôles qu'il est sécuritaire de le faire ici. Ensuite, ResponseCallback():

private void ResponseCallback(object state) {
    var response = _request.EndGetResponse(_responseAsyncResult) as HttpWebResponse;
    long contentLength = response.ContentLength;
    if (contentLength == -1) {
        //You'll have to figure this one out.
    }
    Stream responseStream = response.GetResponseStream();
    GetContentWithProgressReporting(responseStream, contentLength);
    response.Close();
}

Il est forcé de prendre une object paramètre par l'AsyncCallback délégué de la signature, mais je ne suis pas à l'utiliser. Il appelle EndGetResponse() avec le IAsyncResult nous avons eu plus tôt, et maintenant nous pouvons procéder comme si nous n'avons pas utilisé un système d'appels. Mais puisque c'est un rappel asynchrone, il pourrait être en cours d'exécution sur un thread de travail, afin de ne pas mettre à jour les contrôles directement ici.

De toute façon, il obtient le contenu de la longueur de la réponse, qui est nécessaire si vous souhaitez calculer vos téléchargements en cours. Parfois, l'en-tête qui contient cette information n'est pas présente, et vous obtenez -1. Cela signifie que vous êtes sur votre propre pour les progrès de calcul et vous devrez trouver un autre moyen de connaître la taille totale du fichier que vous avez téléchargé. Dans mon cas, c'était suffisant pour définir la variable à une valeur puisque je n'ai pas de soins sur les données lui-même.

Après, il obtient le flux qui représente la réponse et le passe le long d'une méthode d'assistance que le téléchargement et la production de rapports d'avancement:

private byte[] GetContentWithProgressReporting(Stream responseStream, long contentLength) {
    UpdateProgressBar(0);

    //Allocate space for the content
    var data = new byte[contentLength];
    int currentIndex = 0;
    int bytesReceived = 0;
    var buffer = new byte[256];
    do {
        bytesReceived = responseStream.Read(buffer, 0, 256);
        Array.Copy(buffer, 0, data, currentIndex, bytesReceived);
        currentIndex += bytesReceived;

        //Report percentage
        double percentage = (double)currentIndex / contentLength;
        UpdateProgressBar((int)(percentage * 100));
    } while (currentIndex < contentLength);

    UpdateProgressBar(100);
    return data;
}

Cette méthode pourrait quand même être sur un thread de travail (puisqu'il est appelé par la fonction de rappel) donc c'est pas encore sûr à mettre à jour les contrôles à partir d'ici.

Le code est commun pour des exemples de téléchargement d'un fichier. Il alloue de la mémoire pour stocker le fichier. Il alloue un tampon pour obtenir le fichier de morceaux à partir du flux. Dans une boucle, il saisit un morceau, met le morceau dans l'ensemble, et calcule le pourcentage de progression. Quand il est téléchargé comme autant d'octets qu'il s'attend à obtenir, il se ferme. C'est un peu de difficulté, mais si vous utilisez les astuces qui vous permettent de télécharger un fichier d'un seul coup, vous ne seriez pas en mesure de rapport de progression du téléchargement dans le milieu.

(Une chose, je me sens obligé de souligner: si vos morceaux sont trop petits, vous serez la mise à jour de la barre de progression très rapidement et cela peut encore causer de la forme pour le verrouiller en place. J'ai l'habitude de garder un Stopwatch de course et essayer de ne pas mettre à jour les barres de progression de plus de deux fois par seconde, mais il y a d'autres façons de limiter les mises à jour.)

De toute façon, la seule chose qui reste est le code qui fait les mises à jour de la barre de progression, et il y a une raison, c'est dans sa propre méthode:

private void UpdateProgressBar(int percentage) {
    //If on a worker thread, marshal the call to the UI thread
    if (progressBar1.InvokeRequired) {
        progressBar1.Invoke(new Action<int>(UpdateProgressBar), percentage);
    } else {
        progressBar1.Value = percentage;
    }
}

Si InvokeRequired retourne vrai, il s'appelle via Invoke(). Si elle arrive à être sur le bon thread, il met à jour la barre de progression. Si vous arrive d'être en utilisant WPF, il existe des moyens de maréchal des appels, mais je crois qu'ils arrivent via le Dispatcher objet.

Je sais que c'est beaucoup. C'est en partie pourquoi la nouvelle async truc est si grande. Le IAsyncResult modèle est puissant mais n'est pas abstraite de nombreux détails loin de vous. Mais même dans les nouveaux modèles, vous devez garder une trace de quand il est sûr de mettre à jour une barre de progression.

Choses à considérer:

• C'est un exemple de code. Je n'ai pas compris toute la gestion des exceptions pour des raisons de concision.
• Si une exception aurait été jeté par GetResponse(), il sera jeté au lieu de cela lorsque vous appelez EndGetResponse().
• Si une exception se produit dans le rappel, et vous n'avez pas traité, il va mettre fin à son fil, mais pas votre application. Cela peut être étrange et mystérieux pour un débutant asynchrone programmeur.
• Attention à ce que j'ai dit sur le contenu de la longueur! Vous pouvez penser que vous pouvez demander à la Stream par la vérification de la Length bien, mais j'ai trouvé que cela soit fiable. Un Stream est libre de lancer NotSupportedException ou de retourner une valeur comme la valeur -1 si il n'est pas sûr, et généralement avec des flux de réseau si vous n'êtes pas informés à l'avance de la quantité de données à attendre alors vous ne pouvez continuez à demander, "Est-il plus?"
• Je n'ai rien dit à propos de téléchargement parce que:
  • Je ne suis pas aussi familier avec le téléchargement.
  • Vous pouvez suivre un schéma similaire: vous aurez probablement utiliser HttpWebRequest.BeginGetRequestStream() de sorte que vous pouvez de manière asynchrone écrire le fichier que vous avez télécharger. Toutes les mises en garde à propos de la mise à jour des contrôles s'appliquent.

OriginalL'auteur OwenP

La octetsreçus variable qui obtient la valeur de responseStream.Read(buffer, 0, 256); retourne la taille de chaque unique de paquets reçus, et non pas le total ainsi l' (do...while) sera presque toujours retourner vrai résultant dans une boucle infinie, à moins que le contenu téléchargé est si petit que le paquet combiné avec TCP rembourrage finit par être plus grande ou égale à la contentLength.

La seule solution requis est d'avoir une autre variable locale à agir comme un accumulateur de suivre l'avancement total par exemple totalBytesReceived += octetsreçus; et l'utilisation while(totalBytesReceived < contentLength) à la place. J'ai essayé d'utiliser currentIndex à cette fin, cependant, il a été à l'origine de problèmes (télécharger stands), donc une nouvelle variable indépendante a été utilisé.

C'est ce que j'ai fini par utiliser:

    private byte[] GetContentWithProgressReporting(Stream responseStream, long contentLength) {
UpdateProgressBar(0);

//Allocate space for the content
var data = new byte[contentLength];
int currentIndex = 0;
int bytesReceived = 0;
int totalBytesReceived = 0;
var buffer = new byte[256];
do {
    bytesReceived = responseStream.Read(buffer, 0, 256);
    Array.Copy(buffer, 0, data, currentIndex, bytesReceived);
    currentIndex += bytesReceived;
    totalBytesReceived += bytesReceived;

    //Report percentage
    double percentage = (double)currentIndex / contentLength;
    UpdateProgressBar((int)(percentage * 100));



} while (totalBytesReceived < contentLength);

//DEBUGGING:  MessageBox.Show("GetContentWithProgressReporting Method - Out of loop");
UpdateProgressBar(100);
return data;

}

Autres que le code a vraiment bien travaillé!

OriginalL'auteur Achim