While developing Facebook applications I have faced this problem many times that if I delete any image, then it appears on the application while testing, even I delete the whole file then, even, it is executed successfully, so I want to know "Does Facebook have its own cache from where files are executed?".
If so then is there any solution of this problem?
If not then why is happening this?
Best Regards & Thanks in advance
Not sure about image files (they reside in CDN) but facebook uses MemCached server to cache their stuff.
It's not that it has cache but that its main backing store doesn't provide any more coherency than is strictly necessary. Coherency has a cost, so if you don't need it, it makes sense not to pay the cost.
When operations have no enforced order between them, they may complete as if they were executed in either order. If your retrieval and your delete have on enforced order, then they may complete as if they were executed in either order. This applies even if one operation receives its response before the other operation was sent.
My understanding was that there was a cache. Especially for images and styles.
I have frequently made changes to css and updated images only to be left wondering why i can not see these updates.
I always change my css url to be something like styles/styles.css?time= which remedies everything.
In regards to the images , right click on the image in application and view in browser. Refresh to get the updated image and then go back to you application.
Related
PWA application storage (IndexedDB) isn't able to provide data persistence.
In case that PWA is pinned to home screen it is possible to clear all application data from browser by clearing browsing history.
It might be unclear for users that cleaning browser data can affect pinned application and unsynchronised data will be lost.
Is there any way to avoid this?
The only way I see for now - turn back to native apps.
The clear storage mechanism in browsers is to put the user in control of their device.
This is why you as an application should never (native or web) assume your cached assets are cached.
If it is absolutely important to you to make sure you have core assets and data persisted then you need to have some sort of integrity check when the service worker initiates. That way you can restore cached state in case the application goes offline.
You also need to realize the operating system, looking at you iOS, will purge data when it feels like it (think when the available disk space gets critical), which takes you out fo control. It does this for native apps too as far as I know.
I do not know a way around that. The function in Chrome to "clear storage" (for example) does exactly that. I suppose it is reasonable for a user to be able to remove any data from their own device, but I agree it is not a good situation for the developer.
This is not possible.
The Storage API provides a StorageManager.persist() method to request the user explicit permission to persist data until deleted by the user itself:
if (navigator.storage && navigator.storage.persist)
navigator.storage.persist().then(function(persistent) {
if (persistent)
console.log("Storage will not be cleared except by explicit user action");
else
console.log("Storage may be cleared by the UA under storage pressure.");
});
If the local storage is running out of space, the User Agent will start automatically pruning cached resourced except the ones set as "persistent". However if the user itself chooses to clear the local data, there is no way to prevent this.
As far as I am aware, there is no event you can intercept in order to detect a browser clear action from the user.
See API reference doc :
https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persist
In our iOS app we have close to a hundred image files in resources bundle. Now we want to make them network based since the images may change (updated/no longer needed/additions) at any time. We are debating at what approach would be optimal. From what I have read, I understand that the resource bundle will not be editable on the device. So, when I start the app, I will check from the server if there are any image updates. If so, I will download the changed images and then save them to documents directory. Then in the app, for every image, I will basically have to check if it is in the resources bundle, then grab it from there. Else pick it from documents directory and display it.
Another approach is I don't have anything in the resources folder, I download all images on app launch from the server and store them to documents directory and then on, download the changed files at subsequent app launch. Here I am eliminating the check on resources folder if an image is present or not and my app bundle size would be reduced.
The third approach would be to copy the files from my resources directory to the documents directory on first launch and thereafter continue from documents directory.
Any suggestions on what would be a better approach or all of them would be similar from the performance point of view?
IMO, option three offers the best balance between eliminating needless code and preloading as much data as possible. You don't want to make the user wait for 100 image downloads when the app starts the first time, so pre-load as many as possible. The copy code is simple and will only be used once. So that eliminates the runtime checks you'd have to do with the other options.
No worries, performance will not be an issue, unless you use a particularly unwise image lookup algorithm.
Filesystem traversal should be pretty fast for such a small amount of files.
Before implementing something yourself, I would recommend looking at something off the shelf for Image Caching. Namely EGOImageView from EnormEgo.
I have used it in several applications which are dependent on grabbing images from URLs. It handles everything for you, you just set up a 'background' image for it to show while it goes about it's business of grabbing the URL based image in the background. The second time you use it, it's available immediately. Definitely gets my vote for ease of use...
p.s. it's free to use
I have a small APP which allows users to view information on Beers and Beers they have tried for a local Bars Beer Club.
I have 4 Views. Beer Menu, All Stats, My Stats and Settings.
Originally, I thought to pull all of the data via a web service and return xml at initial load of the app, and use it throughout.
OR...
I could just pull what I need when I need it. This would result in just pulling the data I need, which would be faster, but it would result in more requests. What would be better:
a) pull all data, store globally, build views as needed.
b) pull only data I need, when I need it. This means if they click on a beer, I would make a request for that beers info. If they clicked on 10 different beers, then that would be 10 different requests.
What is better? Or does it even matter.
yeah, I think on mobile devices these kind of decisions to matter.
With these kind of concerns I think sometimes there is no right answer but here are a few pointers:
Use json, not xml (if you can)
it's less verbose and, depending on the data, could make a difference to the speed.
Do not block the UI thread
This is really a general guide to all app development, in my opinion. The worst thing you can do is block the UI thread.
Coding for a progressive UI that loads data separately will always be more fiddly than just doing a batch load, and then returning everything. But the extra work will really make your User Experience a lot more pleasurable.
Be clever about your requests
This kinda of carries on from the last point. I'm not saying do a million request, but do try and find a balance before less requests, and loading data as needed (which would suggest more requests).
Try and really think about how the user is going to use your app, and see if you can do some clever pre-fetching based on what you THINK the user might need more in the certain view.
i.e What is the most likely view to be used next? can you pre fetch the data for that?
This last part is really the fine tuning, and will result in a lot of trial and error. But the end result will hopefully be a really great app that just feels fast, and feels right.
I'd go with loading cached data on launch (if it exists) and then load fresh data in the background as needed. This keeps your app as responsive as possible. it's a balance between draining battery life on requests VS responsiveness and data availability. I think the balance is caching information with a timestamp (if the data changes, if not it's even better) and then update as needed.
HI,
For how long data can be saved in Cache folder. I want to cache lot of images which I will be using multiple times. What should be the best place to save them?
Also, these images will rarely change like once in a week kind of. So how and when should I trigger the image refreshing without hampering the app experience.
I assume you’re referring to ~/Libraries/Caches/. The system doesn’t automatically remove stuff there, so the answer is “indefinitely”. If you’ll be adding unbounded amounts of data, you need to clean it out yourself.
Keep in mind that by putting data there you’re effectively promising that your app won’t break if it’s deleted at any time, and it won’t be backed up.
Just refresh the images in the cache when you download new ones. Downloading new ones depends on the images, and where they are used. Eg you could cache the Cocoa-Cola Logo indefinitely as it never changes, but say the Google logo (including the doodles) should be checked for pretty much every day, as it can change (like it has changed today)
Say I have a TODO list iphone app, that can be edited/viewed from both a web application and the iphone application.
When on the iphone, when a user views all his todo lists, or sub-items, I would think that each time the user views a particular list it shouldn't be hitting the web applications API every-time, but rather cache locally the values and only hit the web when things change.
What strategies are there for this type of scenerio?
I agree with you in your dirty-otherwise-do-not-contact-the-server point. And I think this point is pretty straightforward and easy to implement.
However, be careful in this scenario: it gets dirty but at the same time, the device cannot reach the internet. In this scenario, I suggest you check the internet accessibility on a frequent basis (even when your app is in the background), and try to reach your server and update whenever possible.
This is a tricky problem. I'm currently working on an app that needs to perform a similar synchronization, and I haven't decided how I want to handle it yet.
You're right in that you don't want to be hitting the web repeatedly. It would slow the app down considerably. Keeping a local cache is the way to go.
One drawback is that the user could change/add an item on the web and you wouldn't see it on the phone. You'd need to have a refresh button (like in the Mail application, for example) to allow the user to get the changes.
Then you have an issue with conflict resolution. Say the same item is edited on both the phone and on the web. How does the user pick which one to keep, or do they get duplicated?
I think the best way to do this is to replicated your server's schema in CoreData. Then load a given element from the local DB, and in the background go out and check that element for updates if the device has an internet connection. You're hitting the db each time, but the user is not slowed down by the process.
You should not query the internet everytime you view the list.
But when you make updates to it, or edit it, you should update the server as well. That will make your life a whole lot simpler. That way when the user updates an item that he deleted in the web server, the server will just throw that request out...