MvxDynamicImageHelper untrusted

I have an iOS project with an Mvx base that has problems loading images.

I have several screens that contain UICollectionViews, and UICollectionViewCells use MvxDynamicImageHelpers to set the image of their UIImageViews to images posted on the Internet (the Azure blob repository via the Azure CDN actually). I noticed that images sometimes don’t appear and that this is more likely to happen when connecting slowly, and if I view the entire UICollectionView while loading images - apparently because it initiates a large number of simultaneous downloads. Restarting the application causes some, but not all, images to be displayed.

In the Cache / Pictures.MvvmCross folder, I see that there are several files with .tmp extensions and some without .tmp extensions, but the file size is 0 bytes. I assume that the .tmp files are those that are reloaded after the application is restarted and that an invalid entry in the in-memory cache does not allow them to be reloaded until this happens.

I implemented my versions of MvxDownloadRequest and MvxHttpFileDownloader and registered my IMvxHttpFileDownloader. The only modification to MvxHttpFileDownloader is to use my MvxDownloadRequest instead of the standard Mvx file.

As far as I can tell, the exceptions in MvxDownloadRequest.Start or MvxDownloadRequest.ProcessResponse and MvxDownloadRequest.FileDownloadFailed are not called. Replacing MvxDownloadRequest.Start as follows, all images always load and display successfully:

try { ThreadPool.QueueUserWorkItem((state) => { try { var fileService = this.GetService<IMvxSimpleFileStoreService>(); var tempFilePath = DownloadPath + ".tmp"; var imageData = NSData.FromUrl(NSUrl.FromString(Url)); var image = UIImage.LoadFromData(imageData); NSError nsError; image.AsPNG().Save(tempFilePath, true, out nsError); fileService.TryMove(tempFilePath, DownloadPath, true); } catch (Exception exception) { FireDownloadFailed(exception); return; } FireDownloadComplete(); }); } catch (Exception e) { FireDownloadFailed(e); } 

So, what can cause problems with the standard WebRequest, which does not affect the above version? I guess something with the GC and will continue to debug when I get the time, but, unfortunately, this will not happen yet. It would be very appreciated if someone could answer this or provide pointers when I look at it.

Thanks,

J

+4
source share
1 answer

From the description of your research, it still sounds like you isolated the problem to a level that httpwebrequest is sometimes unavailable, but that NSData methods are 100% reliable.

If so, then this suggests that the problem is somewhere on the xamarin.ios network stack or when using it.

It might be worth checking out the xamarin bugzilla repository, as well as contacting their support team if they are aware of any issues in this area. I believe that they made some announcements about changes in iOS networks during evolution - see the CFNetworkHandler part at the end of the video and slides at http://xamarin.com/evolve/2013#session-b3mx6e6rmb - and there are exciting questions like this how the iPhone application enters a state where network requests never complete

In addition, I would suggest that the first step in any debugging would be to isolate the problem in a simple test application - for example, a simple application that simply loads one image at a time and shows a simple pass / fail for each technician. If you can replicate the problem in a small test application, then it will be much faster to solve the problem.

+1
source

Source: https://habr.com/ru/post/1487497/


All Articles