[TIMOB-5334] iOS: Write remote images to disk fails!
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Invalid |
Resolution Date | 2012-02-10T00:30:41.000+0000 |
Affected Version/s | Release 1.8.0.1 |
Fix Version/s | n/a |
Components | iOS |
Labels | n/a |
Reporter | Mads Moller |
Assignee | Sabil Rahim |
Created | 2011-08-08T10:04:56.000+0000 |
Updated | 2012-02-10T00:30:41.000+0000 |
Description
When download an image gallery and save it to the phones filesystem, problems occur.
It works great with 30-50 images at the time. But a large amount of images resolves in some of the images are not saved to disk. The skipped images are random each time I test this. Sometimes it is only a few that are left out, other times its 20 images out of 150.
Its the same behaviour on iOS and Android.
Here is my json loader of the remote images:
xhr.onload = function() {
try {
var items = eval('('+this.responseText+')');
for (var c=1;c<items.length;c++)
{
var id = items[c].id;
var imageLarge = items[c].imageLarge;
var imageSmall = items[c].imageSmall;
var imageMedium = items[c].imageMedium;
//image related content
var imageArr = [imageLarge, imageSmall, imageMedium];
var imageNameArr = ['imageLarge_', 'thumb_', 'thumb_'];
var imageNativePath = [];
for (var i=0; i < imageArr.length; i++) {
var filename = xtractFile(imageArr[i]);
var imageName = '' + imageNameArr[i] + id + filename.extension;
//SAVE REMOTE FILE NOW !
//get_remote_file( filename, url, debug, progress, override)
getRemoteFile('gallery/'+imageName, imageArr[i], function(fileobj){ Ti.API.info(fileobj) }, null, true );
};
//all done
showContent();
}
catch(e) {
//something goes wrong - showcontent
trace("CATCH ERROR: " + e);
}
};
xhr.onerror = function() {
trace("ONERROR: " + e);
};
xhr.open("GET",rssFeed);
xhr.send();
};
The below is my save to disk function. It works great when the app is handling 50 images at the time, but once its higher, some of the images are not stored, even though this below function is called.
function getRemoteFile(filename, url, fn_end, fn_progress, override ) {
var file_obj = {file:filename, url:url, path: null};
var file = Titanium.Filesystem.getFile(Titanium.Filesystem.applicationDataDirectory,filename);
if ( file.exists() ) {
file_obj.path = Titanium.Filesystem.applicationDataDirectory+Titanium.Filesystem.separator;
if(override) {
file.deleteFile();
} else {
return;
}
}
if ( Titanium.Network.online ) {
var c = Titanium.Network.createHTTPClient();
c.setTimeout(10000);
c.onload = function()
{
if (c.status == 200 ) {
var f = Titanium.Filesystem.getFile(Titanium.Filesystem.applicationDataDirectory,filename);
//write file to disk
f.write(this.responseData);
if(f.size == 0) {
//size 0 - start over
trace("ERROR: image write, try again");
getRemoteFile(filename, url, fn_end, fn_progress, override )
}
file_obj.path = Titanium.Filesystem.applicationDataDirectory+Titanium.Filesystem.separator;
} else {
file_obj.error = 'file not found'; // to set some errors codes
}
};
c.ondatastream = function(e)
{
if ( fn_progress ) fn_progress(e.progress);
};
c.error = function(e)
{
file_obj.error = e.error;
fn_end(file_obj);
trace("error: " + e);
};
c.open('GET',url);
c.send();
} else {
file_obj.error = 'no internet';
fn_end(file_obj);
}
};
For JSON see [here](http://cph.napp.dk/index.php?option=com_phocagallery&view=napp&format=json)
There are no errors or exceptions I can paste in, due to the fact that Titanium does not make "errors" it just skips a lot of files.
Yes, it has nothing to do with the server. I have tried without the "write remote to disk functionality" and the gallery works great.
Q&A Thread at [save 100+ remote images to disk](http://developer.appcelerator.com/question/123769/save-100-remote-images-to-disk)
Attachments
File | Date | Size |
---|---|---|
consoleLog.txt | 2011-12-10T15:19:53.000+0000 | 13730 |
TestImageApp.zip | 2011-09-18T02:02:38.000+0000 | 2330453 |
Mads Thank you for raising this ticket. In order to progress it, please add the missing information in the format and places requested in the guidelines at [Jira Ticket Checklist](http://wiki.appcelerator.org/display/guides/Contributing+to+Titanium#ContributingtoTitanium-Summary%3AJiraTicketChecklist). For instance, in the environment field: * *Titanium SDK version:* number, build date and build hash, copied and pasted from the console at application launch * *Platform & version:* iOS x.x, Android x.x, Blackberry x.x, OSX x.x, Windows x, Ubuntu x.x * *Device Details:* iOS simulator, Android emulator or physical device model * *Host Operating System:* OSX x.x, Windows x, Ubuntu x.x * *Titanium Studio version:* copied and pasted from Help / About In the description: * *logs:* the console output of any exceptions, placed within a \{code\} wiki markup block Ideally your usecase would also be simpler, but it's essential that it runs without any modification. Have you tried checking the server logs, network traffic and HTTP response codes to try to determine whether something other than Titanium is causing the problem? Many thanks in advance
I have updated the ticket as requested.
*Severity: Blocker* (my app is in production, so its quite an issue I got here ) Q&A link: [http://developer.appcelerator.com/question/123769/save-100-remote-images-to-disk]
Mads So this is simple to reproduce, would you please include the json file, preferably with URLs of files that exist on a remote server? Cheers
json feed: http://cph.napp.dk/index.php?option=com_phocagallery&view=napp&format=json
Hi Paul, Do you need anything from me? any solution?
Mads Are you saying that the *exact same* problem exists on Android and iOS, with *exactly the same* results? If so, this is quite unusual. However, if this is indeed correct, you will need to raise a ticket for each platform. Would you confirm that your code can reproduce the issue, just by pasting it into an app.js file and launching the app? Once these corrections have been made, I can move the ticket across to the relevant project. Cheers
Have you resolved this, Mads? If not, would you respond to my previous comment? Also, do you think that downloading so many images at once is a good idea for users of mobile devices? Bear in mind that many have monthly download limits. Can you tell us the average size of the images, in terms of resolution and filesize. Cheer
Hi Paul, No, its still a big problem for me. its because in Denmark we have free download on payment plans. nice, right :) anyway, the average image is 640x960 and jpg quality 80, so its about 80kb - 150kb each. I know its a lot of images, but I do not if appcelerator is capable of using the lazyload technique instead. So I only load what is displayed? Is that possible?
Here is an working app example, where the problem occurs..
Mads, did you see my question about android vs ios? Does another ticket need to be raised?
Hi Paul. Its not exactly the same result on each platform, due to its ramdom which images the are saved to the filesystem each time I test the script. Ive uploaded an test app so you can see the end result on iphone and android.
OK, Mads Please would you raise a new ticket for the other platform, and then explain the behavior you observe in the respective tickets. We will then link the two. Thanks a lot
Sorry, Mads, I thought I had already moved this over with the other ticket. It's done now. Thanks for the time you spent on it.
At least on iOS Titanium, we provide remote image caching for you. It isn't necessary to store images to disk yourself, unless you need them to persist for long periods of time across application sessions (or need to manually force updates of the local cache whenever an image changes remotely).
Resolved.. does that mean that in 1.8 this is fixed? can I download a nighly build and get this fix also?
I CRITICAL NEED THIS INFO: Can I get this Android Fix in the continuous builds?
Reopening bug. Do not see 60 images being downloaded to the app. Only see 1 image downloaded. See attachment for console log. Tested on: OS: Mac OS X Lion SDK build: 1.8.0.1.v20111209204243 Titanium Studio, build: 1.0.7.201112080131 Device: iphone 4S (5.0.1)
We do support downloading data retrieved via an HTTP request directly to a file, via setting the
file
property on theTititanium.HTTPClient
object. The documentation reads: bq. File to download contents to. Can only be set after calling open. This, combined with local image caching, should be able to provide a less complicated solution which may not trigger this bug.Hi Stephen. I use the file method for iOS, but thats not possible for Android. So the same disk writing error occurs on Android.
Mads - Android supports this as well, but I believe under a different feature name. I would have to check with their team to make sure. Does this bug only affect Android then, or both Android and iOS?
Mads - I checked with the Android team - they don't allow specific download to file from what I'm able to understand. This property is iOS-only for the time being.
That was also my impression. How do I solve this issue on Android then? I can only fix this issue on iOS with the file porperty, not with the code provided in this ticket.
The TestImageApp sample project appears to save image files to disk in the iphone simulator application data folder, and in android (SDK 1.8.0.1, quick pass). The images do not display due to code problems. If someone could make a simple, functional sample case, we could test this further.
Closing issue as per invalid status