I am new to using Alamofire for swift. I tried reading the documentation, but didn't succeed.
I am making a
Alamofire.request("http:json").responseJSON
and I discovered, that it works and returns a response even when the phone is offline. If I'm not mistaken, the response is saved in the cache.
How long will this response stay in the cache for the user to use offline?
Should I store the response as a preference?
Thanks for the help.
You are right, Alamofire caches your response.
Although, I don't think there's a way to know when your response will be dismissed from cache, as there are many variables for the system to consider, for example- disk space... You may use a custom caching policy if you think it's right for you.
I wouldn't count on the default caching policy to save me files for offline usage, and implementing a custom policy feels wrong for that case. So if you really need your files offline, I would recommend you to use a different way.
Take a look on URLCache- this what Alamofire uses for response caching-
Response Caching is handled on the system framework level by URLCache. It provides a composite in-memory and on-disk cache and lets you manipulate the sizes of both the in-memory and on-disk portions. -> From Alamofire documentation
Related
I'm looking to implement a thin client around a RESTful(or a close attempt) API.
I'd like the client to cache the API responses where appropriate but to reduce the logic in the client I would also like the backend to handle the cache clear logic.
Lets say we have a resource "item list" at
example.com/items/
CRUD methods (GET,PUT, and DELETE) can be called on
example.com/items/{id}
Now, as you've already guessed, adding and removing items will also change the full list response. In this example we want to clear the cache for the list response after a DELETE call to an item. Is there a standard way to clear the cache on arbitrary urls?
I'm imagining something like Clear-Caches: ../items/
Is there another way to do this? If this doesn't exist, why not? Perhaps this is a bad pattern for some reason?
Is there a standard header to clear cache for arbitrary URLs in a RESTful API
No.
As far as I can tell, the Linked Cache Invalidation draft expired in March. That approach is close to what you are after, I think, but doesn't seem to have gotten any traction in the standardization process.
First of all I'm new in ios/swift...
I need to have offline mode of my app.
I'm using Alamofire for all networking getting json, convert to objects and save into the DB (Core-Data). Wanted to know do I need to have additional cache in between (like: Haneke, or DataCache) in case no internet connection or getting from CoreData?
Is DB request fast/convenient enough?
CoreData is very fast (if correctly used). I don't believe it would be necessary to have an additional cache layer.
It would be just a duplication of data that you already have stored in your DB.
By the way all depends from your project use cases. I would not rely on temporary cached data if my app must work without internet connection.
To give you an idea of core data performances so that you can choose what works best for you: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/Performance.html
I want to know what is the best way to store data on the iPhone from a web service.
I want the information to be stored on the device so the person doesn't need to access the web service every time he/she needs it. The currently information isn't much and contains less that 150 records. The records might update from time to time and a few new ones will be added. What is the best way to go about storing the data?
Thanks
If you use ASIHTTPRequest for your network stuff (and if you don't already, I can't sing its praises highly enough), you will find it has a cache layer built in which is perfect for situations like this.
You can activate it with a simple one line;
[ASIHTTPRequest setDefaultCache:[ASIDownloadCache sharedCache]];
And you have full control over the cache policy etc - just read the documentation.
The other simple approach of course is - on the assumption that your web service is returning JSON or XML - simply to store the response in a local file against a hash of the request parameters, then when you request the data again, you can first look to see if the file exists and if it does, return that data rather than going back to the website. You can roll your own cache policies etc too.
Since I discovered ASIHTTPRequest had a cache though, I've not needed to roll my own again.
I find that using coreData or sqllite3 is just overkill for 99% my requirements and a simple cache works very well.
If the data is relational, a Sqlite3 database would be the best storage option you have.
Also, this helps by allowing you to retrieve from the server and to update only the records that have changed, thus saving time and bandwidth.
This is the best option from a scalability point of view as well, as you stated that "current information isn't much", thus giving the impression that this is only a current situation, that may be subjected to further change, probably towards more records being added in time.
Sqite3 also gives you more control and better performance than using, for instance, Core Data. Here's an article explaining some of the details. Moreover, if you work through an Objective-C wrapper, such as FMDB, you get all the advantages without managing the complexity yourself.
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.
Working on an app where all the contents/data for it will be coming via JSON and occasionally i will display a HTML page.
The client is suggesting that maybe we should have some local database(MYSQL Lite) to cache the JSON data returned so we use less of the users data(if there search for the same item again) allowance and because it maybe slightly faster.
Are these good enough reasons for adding the extra complexity and potential problems of having a local DB on the phone?
I didn't think from my experience that the phone was particularly slow or that JSON or HTML were data heavy in there data usage. I'd prefer having a thin client.
Facebook/Twitter/etc work with very little problems using JSON and Html.
Would I be wrong to try steer away from the local DB idea?
Thanks,
-Code
Caching url request results can improve your application's latency over a slow connexion. You could use CoreData to manually manage a cache (key:url, value:request's answer)
Another more elegant solution would be (if you have write access to the webservices) to implement server-side the "if-modified-since" header so that your request data received would be kept at a minimum level.