Заредете файлове в локално хранилище с MvvmCross

В момента се опитвам да кача файлове от сървър, използвайки уеб услуги в преносимата библиотека. За всеки файл правя това:

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);

В моя метод за обратно извикване правя това:

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);

Получавам целия файл като масив от байтове. Но с winRT записването на файла спира бързо и локалният ми файл не е пълен. Ако се опитам да кача само един файл, записът също спира. Но ако опитам със Silverlight (разширих MvvmCross до Silverlight), писането е завършено. Все още не съм тествал за MonoDroid et MonoTouch.

И така, въпросът ми е: защо писането спира?


mvvmcross c# windows-runtime
person Titecarma    schedule 05.11.2012    source източник

Отговори (2)


arrow_upward
2
arrow_downward

Прегледах кода за WriteFile в MvxBlockingWinRTFileStoreService.cs и не виждам очевидна грешка.

За да тествам това, току-що написах бързо самостоятелно приложение за тестване на WinRT, използвайки https://gist.github.com/4016898.

Това запазва идеално 37kB файла с началната страница на Bing. Работи ли и на вашия сървър?

След този тест моето предположение е, че може би има някакъв бъг във вашия код за уеб трансфер - може би дори в услугата localhost. Въпреки това все още е възможно грешката да е в запазването на StorageFile.

Някой въпроси:

  • Можете ли да добавите допълнително проследяване, за да разберете дължината на буфера на данните, докладвана на всеки етап от вашето изтегляне?

  • Можете ли да адаптирате простия тестов сноп по-горе, така че да показва същите резултати?

Един възможен кандидат е:

Използвате ContentLength като дължина на потока? Сигурни ли сте, че това е правилната дължина?

напр. ако имате активирана GZip компресия, тогава ContentLength ще ви даде дължината на предадените компресирани данни, а не дължината на самите данни - вижте https://stackoverflow.com/questions/3819280/content-length-when-using-http-compression

Колкото повече мисля за това, толкова повече това има смисъл за мен - Silverlight ще използва стека на браузъра, който ще има различни хедъри за приемане на HTTP в сравнение със стека WinRT.

Някои добри новини са, че async/await скоро идват в MonoTouch и MonoDroid - и когато го направят, ще се опитам да направя всички API на файловете налични като async и await.

person Stuart    schedule 05.11.2012

arrow_upward
1
arrow_downward

Стюарт,

Първо, благодаря ви за отговора!

Опитах вашия пример и се адаптирах към моя случай (качване на файлове от сървър чрез уеб услуга) и в началото всичко работеше. Всички файлове са качени правилно. Но когато добавих изображения за качване, имах същия проблем. Файловете с изображения И текстовите файлове не са пълни.

Но гледайки кода на вашия пример, намерих решение, но си помислих, че наистина не разбирам къде е проблемът.

За писане на произведения замених това (в моя метод за обратно извикване):

...

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

с това :

...

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

Не знам защо, но работи! (Ако знаете защо това работи, интересувам се)

Така че, благодаря ви за помощта!

person Titecarma    schedule 05.11.2012
comment
вижте моя отговор - той е в удебеления коментар - ContentLength не е разархивирана дължина на потока. PS Искаме вашето silverlight порт публично :) - person Stuart; 05.11.2012
comment
Стюарт, идвам при теб с адаптацията на Mvvmcross Silverlight. Мога ли да получа вашия имейл адрес, за да ви изпратя кода? Не използвам GitHub ... И когато имате кода, имам въпрос към вас относно изтичане на памет;) Благодаря ви! - person Titecarma; 28.11.2012
comment
най-добрите данни за контакт са на slodge.blogspot.co.uk/p /if-youve-got-questions.html - person Stuart; 28.11.2012
comment
макар че ако щракнете върху моето име в StackOverflow, това също има някои съвети в него;) - person Stuart; 28.11.2012