Start a new topic
Solved

Can't seem to clear cached index.js

I have a system that can switch between AR experiences (directories with html, js, and assets) on iOS using the javascript sdk (6.1). 


They are (currently) always placed at the same location in my application's caches directory


It appears that, when reloading the ArchitectView, some aspects of the old experience stick around. 


In particular it almost seems like the index.js file is cached somewhere and I can't seem to force it to reload. Assets however don't appear to be i.e. if I just change a movie to play back, that works fine.


I've attempted all of the following in the viewDidLoad for my ARViewController


   [self.architectView clearCache];


    NSURL *tmpDirURL = [[NSURL fileURLWithPath:NSTemporaryDirectory() isDirectory:YES] URLByAppendingPathComponent:@"com.wikitude.sdk"];

    if ([NSFileManager.defaultManager fileExistsAtPath: tmpDirURL.path]) {

        [NSFileManager.defaultManager removeItemAtURL: tmpDirURL error:nil];

    }


    [[NSURLCache sharedURLCache] removeAllCachedResponses];



without success


I will try moving my AR experiences to uniquely named directories in the morning but in the meantime, any advice on this would be appreciated.


Note restarting the app clears the cache (wikitude picks up the updated index.js) so it appears to be being cached in memory only

Hi David,

At which point do you call `-loadArchitectWorldFromURL`?


As far as I understood, the actual `content` of the index.js file is interpreted correctly, it's just that the index.js is not loaded correctly?


We use an UIWebView internally to load the given .html file, so whatever the UIWebView decides to cache we don't influence specifically.


I just did some investigation and quickly added a new public API that let's you define the cache policy for the NSURLRequest we pass to the UIWebView. You can now pass the cache policy when loading the Architect World (`-loadArchitectWorldFromURL:cachePolicy:`). The value `NSURLRequestReloadIgnoringCacheData` might be interesting for you.

You can download the build here. Please note that this build is just a snapshot of the SDK, so please only check if the new parameter is working for you.


Best regards,

Andreas

Hi Andreas!


Thanks for the updated SDK snapshot to test. Unfortunately it doesn't solve the issue. However I suspect I've misdiagnosed the original issue and that it's not index.js that I'm seeing cached, but rather the javascript methods / context behind it (sooo maybe something coming out of JavascriptCore ? a global JSContext maybe or something along those lines ? ... I unfortunately don't know much about that framework).


One clue to the root cause however is that after implementing storage of updated copies of my experience in different subfolders of the caches directory I could switch between the experiences no problem. So the cache (wherever it is) appears to be URL/path based ... but clearing the shared NSURLCache ahead of calling 


self.architectWorldNavigation = [self.architectView loadArchitectWorldFromURL: self.url]


doesn't help so that's not the one.


Anyway, since my workaround appears to work I'll probably continue with that (storing every update to the experience in a unique directory) . 


But I'll be happy to try any other SDK changes to root cause this . Let me know also if there are other details I can provide about my setup. Also


re : When to I call loadArchitectWorldFromURL - I'm working with a derivative of the example objective C ARViewController so the structure is everything is in viewDidLoad and this viewController is just being pushed and popped from the UINavigationController stack. The architectView itself is an IBOutlet reference . In viewDidLoad I would 


1) try clearing all the caches I could

2) check [WTArchitectView isDeviceSupportedForRequiredFeatures:WTFeature_ImageTracking error:&deviceSupportError]

3) if yes, set license, delegate, requiredFeatures, and then call [self.architectView loadArchitectWorldFromURL: self.url]


 

Hi David,

Thx for testing the snapshot and the detailed feedback! I had high hopes in this change but it seems that I need to continue searching.

Do you have a demo project that I could use to hunt this behaviour down?


Best regards,

Andreas

Hi Andreas, any news on this issue? I have exactly the same problem on Android,I should try creating new folders in the cache as suggested by David as workaround, but I'd really prefer avoid that if possible... 

Tnx!

Hi Andreas, a little update, I tried just renaming the folder after any update and it works ...

Login or Signup to post a comment