Charger des fichiers dans un stockage local avec MvvmCross

Question

Actuellement, j'essaie de télécharger des fichiers à partir d'un serveur à l'aide des services Web de la bibliothèque portable. Pour chaque fichier, je fais ceci:

WebRequest request = WebRequest.Create("http://localhost:49364/" + url); 

request.BeginGetResponse((aResult) => 
{ 
     var retour = aResult.AsyncState as WebRequest; 
     WebResponse reponse = retour.EndGetResponse(aResult); 
     callback(reponse); 
}, request); 

Sur ma méthode de rappel, je fais ceci:

byte[] bytes; 
string currentFileName = fileName; 
string categorie = currentFileName.Split('/').ElementAt(0); 
string dir = currentFileName.Split('/').ElementAt(1); 

using (var reader = new BinaryReader(reponse2.GetResponseStream())) 
{ 
    bytes = new byte[reponse2.ContentLength]; 
    reader.Read(bytes, 0, (int)reponse2.ContentLength); 
} 
fileService.EnsureFolderExists(categorie); 
fileService.EnsureFolderExists(fileService.PathCombine(categorie, dir)); 
fileService.WriteFile(currentFileName, bytes); 

Je reçois tout le fichier comme un tableau d'octets. Mais, avec winRT, l'écriture du fichier s'arrête rapidement et mon fichier local n'est pas complet. Si j'essaie de télécharger un seul fichier, l'écriture s'arrête également. Mais, si j'essaye avec Silverlight (j'ai étendu MvvmCross à Silverlight), l'écriture est terminée. Je n'ai pas encore testé pour MonoDroid et MonoTouch.

Alors, ma question est la suivante: Pourquoi l'écriture cesse?

Answer 1

J'ai regardé à travers le code de WriteFile dans MvxBlockingWinRTFileStoreService.cs et je ne vois pas bug évident.

Pour tester cela, je viens d'écrire une application de test autonome WinRT rapide à l'aide https://gist.github.com/4016898.

Cela enregistre le fichier de page d'accueil Bing 37Kb parfaitement. Cela fonctionne aussi sur votre serveur?

Après ce test, je suppose que peut-être il y a un bogue dans votre code de transfert web - peut-être même dans le service localhost. Cependant, il est toujours possible que le bogue soit dans la sauvegarde de StorageFile.

Quelques questions:

• Pouvez-vous ajouter trace supplémentaire pour trouver la longueur de la mémoire tampon de données déclarées à chaque étape de téléchargement?

• Pouvez-vous adapter le faisceau de test simple ci-dessus afin qu'il montre les mêmes résultats?

---

Un candidat possible est:

Vous utilisez ContentLength comme la longueur du cours d'eau? Êtes-vous sûr que c'est la bonne longueur à utiliser?

par exemple. Si vous avez activé la compression GZip, alors ContentLength vous donnera la longueur des données compressées transmises, pas la longueur des données elles-mêmes - voir content-length when using http compression

Plus je réfléchis, plus cela me semble logique - Silverlight utiliser la pile du navigateur qui aura des en-têtes HTTP différents par rapport à la pile WinRT.

---

Quelques bonnes nouvelles sont que async/Attendent viennent à MonoTouch et MonoDroid bientôt - et quand ils le font alors je vais essayer de faire les API de fichiers tous disponibles en async et attendre.

Answer 2

Stuart,

D'abord, merci pour votre réponse!

J'ai essayé votre exemple et m'adapter à mon cas (télécharger des fichiers à partir d'un serveur via un service web), et tout a d'abord fonctionné. Tous les fichiers sont téléchargés correctement. Mais quand j'ai ajouté des images à télécharger, j'ai eu le même problème. Les fichiers image et les fichiers texte ne sont pas complets.

Mais en regardant le code de votre exemple, j'ai trouvé une solution, pensé que je ne comprends pas vraiment où le problème est.

Pour écrire des œuvres, j'ai remplacé ce (dans ma méthode de rappel):

... 

using (var reader = new BinaryReader(reponse2.GetResponseStream())) 
{ 
    bytes = new byte[reponse2.ContentLength]; 
    reader.Read(bytes, 0, (int)reponse2.ContentLength); 
} 
... 
fileService.WriteFile(currentFileName, bytes); 

par ceci:

... 

var mem = new MemoryStream(); 
using (var stream = reponse2.GetResponseStream()) 
{ 
     stream.CopyTo(mem); 
} 
mem.Seek(0L, SeekOrigin.Begin); 
... 
fileService.WriteFile(currentFileName, mem.ToArray()); 

Je ne sais pas pourquoi, mais ça marche! (Si vous savez pourquoi cela fonctionne, je suis intéressé)

Alors, merci pour votre aide!