I'm doing a tutorial on CoreData and they talked about the "Allows External Storage" option. The documentation says "When enabled, Core Data heuristically decides on a per-value basis if it should save the data directly in the database or store a URI to a separate file which it manages for you. You cannot query based on the contents of a binary data property if you use this option." I understand the first part but I don't understand what they mean by "You cannot query based on the contents of a binary data property if you use this option". I feel this is important stuff, but I can't understand it. "You cannot query based on the contents of a binary data", what does that mean? I don't if it's my bad english or something but I can't figure it out.
The tutorial is "Core Data by Tutorials" from the Ray Wenderlich's tutorial book series. I highly recommend!
image the NSData you store is jpeg data with an exif header.
if you store the data inside the DB, you can use a predicate matching said exif data: e.g. something like (pseudo) "jpgedData CONTAINS author: dominik"
if you store it as a separate file, that query wouldn't work as the data isn't really inside the database
[note that this was explanatory pseudo code and I can't really think of a practical / useful example]
All that means is that if you enable that option for a property, you can't use that property in an NSPredicate when fetching objects. A fetch request is a query, and when you use a predicate you're fetching objects based on whether they match the predicate. That doesn't work if external storage is allowed for the property.
Ok I think I got it. Basically you can't use the image's raw meta data to look for a specific image, because you don't have access to the raw data. You only have access to the URI. Sounds logical and fair to me, since you could just extract the meta data, and store it in your CoreData model before saving the image as a transformable (if need be).
Related
I'm having some issues with the app, that I'm making, which I thought would be a lot easier to explain with some photos, so ... :
Ofcourse the "Create New Person-button" in nr. 1 leads you to number two.
Now, I'm having issues figuring out how to save this data about the person in the "People Diary". The goal is, that when you enter a person's name, add a photo (an enable-camera feature, I will struggle with at a later time...) and add an answer to the question - then you only need to press "Save this person", and then you will be redirected to the AllPersonsInYourDiaryViewController, where there is now a new tableViewCell with this new person's name (maybe with a subtitle containing the answer and the photo shown in miniature in the cell too).
(Naturally you can then enter this cell with the data about the person too - but that comes next.)
So far in the app, I have used NSUserDefault, when allowing the user to create this specifik Diary by the Name "Antons Diary" with the specifik question and so on. But now it came to my attention, that maybe it is smarter to use something else? I tried with dictionaries, but couldn't get this to work properly.
So...: Before I spend hours and hours playing around with one of these ways, will someone smarter than me, tell me what the best approach would be?
If I can give my two cents, the first thing you have to do is to “design” how to represent a person programmatically. You can create a struct or class to do so, even though a struct is more suitable:
struct Person {
var name: String?
var answer: String?
var photo: String?
}
Then you can decide how to save the data of such an object persistently. If you want to use a database, then I would recommend using SQLite with FMDB library. It’s really easy and fast to learn how to use it, and it's also quite handy. I've used it big projects and it works smoothly. I find CoreData too complicated and an overkill based on what you need.
If you don’t want to use a database, your only other way is to save to files, but still, you’ve got options here too. If you encode (see Codable protocol in Swift), you can use NSKeyedArchiver to convert to Data object and write then to disk. If you like using dictionaries, and since the properties you’re going to have for a person are not going to be too many, you could create a dictionary by assigning the properties and their values, and then convert and save as JSON data, or even Plist files. Without any intension to do promotion here, but just to provide some additional help, if you want take a look to a library that I’ve written and that can do all these automatically for you. It’s a protocol that you have to adopt, and then you can instantly convert your struct to a dictionary, JSON or plist and save to files.
No matter which way you’re going to select, save the images as single files to documents directory, and keep their file names only stored to database/file. Based on them, you can build the path to each image (or the URL) easily when needed. Warning: Do not save the full path to the documents directory, especially if you’re testing on Simulator; paths are changing on each build. Save the file name only.
Additionally, if you’re going to use a struct like the one shown above, you could implement small but super convenient functions that will be responsible for saving, loading, or updating your data to the solution (database/file) you’ll eventually select. That way, you’ll have related stuff gathered in one place, and easily accessible (i.e., person.save()).
struct Person {
var name: String?
var answer: String?
var photo: String?
func save() {
…
}
func load() {
…
}
// More functions…
}
Lastly, avoid using UserDefaults, or at least keep just a few non-critical data there. UserDefaults are not meant to keep all data produced by your app. Most importantly, do not use it for saving sensitive data, especially passwords or other stuff like that.
I hope the above will help you make your mind.
I can give you the logic behind coreData and NSUserDefaults, but you will decide which one should be used.
CoreData is usually used as a database. you can create entities and attributes for every entity. Moreover, you can create relations between these entities.
When extracting data from coreData, you can arrange this data using NSSortDescriptor or select a specific record using NSPredicate.
So as you can see CoreData is a database.
While NSUserDefaults is usually used to save a password, username, userID... and such issues that you will regularly use in the app. NSUserDefaults gives you a direct access to the saved variables at any time. However, CoreData will take more time and lines of code to access the entity and make the query.
Now, check which method suits your case more.
I have iOS app that takes data from the server as json and then serializes them into objects of different types. Types can be complicated, can contain subtypes, can inherit, so there is no any limitations. Another thing that makes everything even more complicated is some of types are stored as AnyObject? and only in run time they are being serialized into real types accordingly to the specific rules. Something like that:
class A {
var typeName: String?
var b: AnyObject?
}
Then when it's serialized it can be done something like that:
if let someClass = NSClassFromString(typeName) as? SomeGenericType.Type{
b = someClass.init()
}
Also querying should be done on all the data. Currently I'm trying to store all of them locally, then load into memory and query there from the code. I'm using User defaults, but they have some limitations, also I needed to provide custom coding to make it work, and each time when I add a new field it turned out that I missed something in coding and nothing works. So it's pain.
Ideally I would just do some magic command and all the objects are sent to local storage no matter how complicated they are. The same to extract them from this storage. Also, user change data so I can't just store primary Json. And I don't want to covert objects back to Jason as for it's pain too.
Any suggestions?
If you want to use sqlite then You can store whole object in one row! I means you can create table with 2 columns one is id and second is your dataobject(it's data type should be blob). Then convert your whole object into data. Then store in sqlite table and retrieve it as data then convert it to object when want to use. By this way your object will remains in same format as you asked
Firebase while meant for online synching and storage can also cache everything locally in case you are offline and perform query's against the local cache. It uses JSON.
CouchDB also has a mobile version for iOS.
Both of those are over kill if your dataset is small; you can just store it as a text file and read the JSON back in. See performance characteristics here. The graph is for a 7MB file so if you are significantly less than that your load time may be minimal.
NSKeyedArchiver.archivedData(withRootObject:) is great for storing custom objects as Data objects. The only thing you need to do to be able to use this is to make your custom objects conform to NSCoding. A great example can be found here:
Save custom objects into NSUserDefaults
Once you have the Data version of the object, it can easily be stored in UserDefaults, as a property in CoreData, or even in the app's keychain entries. Depending on your use case, sensitivity of data, and how much data you intend to store, you might want to use any number of storage methods. NSKeyedArchiver.archivedData(withRootObject:) allows you to pretty much use any of them.
I need to cache json data from API in swift.
So I researched a Lot & get to this Post.
I tried to implement the Option 1 in my App. But the Custom manager always returned nil. I don't know why?
After that I got AwesomeCache. It says that it an do Awesome API Caching.
But I don't know how to implement this?
I referred this Issue. Still I can't figure it Out.
This is how my Current implementation Looks without Cache:
Alamofire.request(.GET, "http://api.androidhive.info/volley/person_array.json")
.responseJSON { (_, _, data, _) in
let json = JSON(data!)
let catCount = json.count
for index in 0...catCount-1 {
let name = json[index]["name"].string
println(name)
}
Please suggest me the Best way to Cache JSON from API ?
Thanks in Advance!
UPDATE
These are my requirements
Fetch the JSON from the API & Parse the JSON data. These can be done with the help of Alamofire & SwiftyJSON
I will populate the parsed data in the Table View. It works when the user is in Online.
But I want to show the data in the Table when the user is in offline too.
So I need to save the Parsed data or the JSON data in my cache & I need to refresh or expire the cache within a week or days.
I don't prefer to store the JSON in my disk because it will be updated.
Please suggest me the Best way to achieve this...
You have many tools already at your disposal.
NSURLCache
All your requests are already stored in the NSURLCache in the NSURLSessionConfiguration on the NSURLSession stored inside the sharedInstance of the Alamofire Manager. Those stored requests already follow all the caching policy rules provided by the servers you are hitting. You can control the caching behavior by setting the requestCachePolicy on your own custom NSURLSessionConfiguration. I'd also suggest you read through this awesome NSHipster article that walks you through the ins and outs of NSURLCache and how to control it.
Creating custom Manager objects is covered in the current Alamofire docs.
Downloading JSON to Disk
You can also download the JSON directly to disk using Alamofire.download instead of using Alamofire.request. This will download the payload to a fileURL that you provide in the destination closure. This would give you full control over the caching of the file after that point. You would need to create your own caching policy around these files afterwards if you wanted to follow the caching header rules provided by the server.
Populating Table View
Once you have your data downloaded to disk, you need to load it into an NSData blob and parse it into JSON to populate your table view. This should be pretty straight forward. You need the destination NSURL that you specified to Alamofire when you started your download. Then load the file data into an NSData blob. Finally, use NSJSONSerialization to convert the NSData object into a JSON AnyObject which can be parsed into model objects to populate your table view.
Obviously you don't "have" to parse the JSON into model objects, but this helps protect your table view from malformed JSON data.
Storing JSON for Offline Usage
If you stick with this approach, you'll need to track your cache expiration dates in something like CoreData or SQLite. You can do this by either caching the paths to the JSON files on disk, or store the model objects directly in CoreData or SQLite. This could get fairly complicated and I would not recommend this approach unless you absolutely don't want to cache your model objects.
Offline Usage
Generally, if you need to cache data for offline usage, you want to store your model objects in something like CoreData. You would use the Alamofire request method coupled with a responseJSON serializer to parse the data into JSON. Then you would convert the JSON into model objects. From there, you'd save your model objects in CoreData, then finally populate your table view with the model objects.
The nice thing about this approach is that you have all your model objects cached in the case that your table view is accessed when the device is offline. Coupling this design with queries to your NSURLCache to see if your request is cached let's you avoid unnecessary server calls and parsing logic when you already have your model objects generated.
Given the updates to your original question, I would recommend this approach.
You can use this cache open source. It cache data on disk and memory. Can cache many swift type, and custom class which inherit NSObject and conform NSCoding protocol.
https://github.com/huynguyencong/DataCache
To implement:
First, it use NSCache for mem cache. NSCache use like a dictionary.
Second, save cache to disk, use NSFileManager methods.
I am planning on creating my app in a 'Model-View-Controller'(MVC)-style, and in the end, for me at least, this means that all data is stored in the controller-class. Let's say I have a class Player, and the player has several objects of class Weapons or Equipment or whatever. The initialization of Controller* stores the player(s), so if I can store/save only the Controller-object over time, even if the app or the device restarts, that would be nice. I did this in Java one, I put in Serialization = 100L;(or something like it) in the top of the file of every object that would be included when saving the Controller-object, and it worked perfectly. Is this possible in ios/cocoa-touch/objective-c?
I have read and used Core Data (not very much), but that is just a database-table, sql?, which would have me extract every piece of information of every object?
For instance, if the object Player* has a member NSString *name;, I would have to save the actual string in Core Data, instead of saving the object of the player? Like, varchar.
If there is any way to store an entire custom object on the device for further use, I would very much like to know what it's called, and where I can read about it/tutorials.
Read up on the NSCoding protocol. You can make your object complient to it, then serialized it and save it to a file. Later you can restore it to the same state by using a decoder. For sure some other posts that cover this topic on SO.
In my app I will have an array of up to 50 images that people can maintain. They can choose to create new or delete existing images. Each image will have a few things associated with them, like a rating for example.
My question is how I should go about storing them. Should I create a CoreData entity called "Image" and store them that way? Should I set up a UIView subclass that conforms to NSCoding and just encode and decode the array and store it on the device? Is there another way I should consider? Thanks for any suggestions.
You can create an entity that represents the image with its information, and use core data's external storage property for entity's attribute. This way, you get the convenience of core data without actually storing the images on the persistent store.
I had to make a similar decision recently and I decided to store the image in CoreData. I have a managed object called photo with a Binary Data field called image:
photo.image = UIImagePNGRepresentation(imageFile); // <- imageFile is a UIImage
And I recreate the image using:
[UIImage imageWithData:self.image];
One immediate advantage is that the images are deleted automatically with the object and there's no extra overhead in retrieving the image if you've already queried for the record.
Core Data is probably overkill for what you want to do. Choose some key value pairs for descriptive information about the image. One key will be "path" and the value will be the path to the image file (or just its name). You can serialize array (or set) of dictionaries.
When your app starts up, read in the serialized array of dictionaries. Every time something changes, serialize and save the information. Write a short audit routine to insure that there is a one - to - one correspondence between dictionaries and images on file, and if one or the other is missing delete the other (will handle situations were you crash before getting to update something or the other).
Later on you can add more attributes to the dictionaries if you want, or even remove some.
[PS: I did this in a shipping app for one version, when the information needed to become relational I switched to Core Data.]