What other ways than NSUserDefaults are there to save and get back Custom Objects? For me, NSUserDefaults has become too much of a hassle (it's not saving correctly), so I'm looking for another way to save data that will work. (I've already posted my problems, and I really just want to look for other ways to save data)
EDIT: I also need to be able to save things like UIIMages and UIButtons.
You can save data as normal text file or plist file.
You can use SQLLite to save data.
Other than this if you are using server driven application, then you can save your data on server and get back when you need that.
UIImages should be saved by creating a PNG or JPEG representation, then writing that NSData block out as you see fit. See UIImagePNGRepresentation.
UIButtons should be serialized/deserialized using the NSCoding protocol. Archives can take care of this for you.
NSData and UIButtons both support NSCoding, so I would recommend archiving instead of NSUserDefaults. See NSCoding for the beginning of that rabbit hole.
You cans use plist or coreData.As you used NSUserDefaults , that means data is quite small so plist will be a good idea.Both are apple's so quite effiecient .If data gets really large you can use sqlite.
To store custom objects, you need to make sure your custom objects implemented NSCoding protocol. Here is Apple's doc on NSCoding. . If you need a tutorial on how to implement NSCoding protocol, check out this site. To save UIImage to a file, you can convert the image to NSData and then using NSData's writeToFile method to write to a file. There are numerous examples on how to do the last part on SO. Here is one.
Related
Been using Core Data for a minute. At some point somewhere in the past, I decided that any image attributes in NSManagedObject subclasses should be instances of NSData. I don't remember exactly what informed that decision, but it's something I learned years ago and have always stuck to since. When I wanted a UIImage, I had a readonly property on my NSManagedObject subclass whose getter would create a UIImage instance from the data using one of the UIImageRepresentation functions.
Now I'm working on a new project, and it occurs to me that Apple's PhotoLocations sample app (Core Data Transformable Attributes) actually uses a UIImage for the persisted property. Why? For simplicity's sake it's certainly easier, no need for that UIImageRepresentation function call.
I'm aware of stuff like "store in external record file" and such, my question isn't about that, or even whether or not images should be in their own entity, related to my original entity - it's simply whether or not I should use UIImage or NSData as the type for a persisted property.
Been hard to figure out what's considered best practice or what the drawback is one way or the other. Any insight would be appreciated.
I always store data in a format that is readable by anyone. It makes for data that is easier to transmit, use in multiple systems, avoids deprecation, etc.
When I store an image I store it in a PNG format instead of UIImage. Why?
UIImage could change.
I may want to upload it to a server.
I may need to read the file on OS X.
I might want to make it transportable later.
When it comes to data, I like to think past just the here and now.
There seems to be conflicting answers on this question and I'm confused what the best way to store images in a Core Data database is.
This question says transformable, however this question says to use Binary Data.
If I just want to take it and turn it into a UIImage/UIImageView what would I be better off using?
I generally store images outside of Core Data (in the documents directory, or in the bundle) and then save paths to them in Core Data.
The other approach I've seen recommended is to save your images as BLOBs, but in a separate entity so you don't bog down your other entities with all that data.
Transformable and binary are really the same thing. In both cases you're saving binary data, the difference is where the data is converted between a UIImage and NSData.
If you use a transformable attribute, you'll use an NSValueTransformer to convert between the two. Your code can read and write UIImage directly, and the value transformer converts the format. Apple includes a sample value transformer for this purpose in one of their sample apps.
If you use a binary attribute, you have to convert to/from NSData any time you access the attribute. You'd do the same steps as the value transformer, but you'd do it a different place. You'd be reading and writing NSData on your objects.
Either one works. A value transformer is nice because it keeps the conversion in one place, regardless of how many places your code uses the images. But either is fine, so do whatever seems most convenient.
This is probably a naive question - but I want to double check to avoid wasting time with UIDocument if it doesn't do what I want.
Background: I have an app for which I have created a simple file system to save out user created documents as plists. I have my encoding/decoding all working. I am using some primitive types and handle that with the appropriate encoder method. I have a naming system and save the plists to a custom directory in the Library directory since these are docs the user should not have direct access to. (they can export their data to the documents directory if they so choose.
I started thinking about "autosave" and then discovered UIDocument - looks pretty great.
So given the above, does it seem like I can use UIDocument? What I save out is a custom class "Project" instance derived from NSObject. It contains a bunch of NSMutable arrays which contain instances of custom classes, NSDictionaries etc. I'm going through this UIDocument tutorial now: http://www.raywenderlich.com/6015/beginning-icloud-in-ios-5-tutorial-part-1 but don't want to discover that it's not going to work because of my data, etc.
Update:(for those reading along at home... ;-) Made some progress with this.
UIDocument uses NSKeyedArchiver rather than NSCoder (Wrong - see answer below) but the encoding method names are the same so it was easy to adjust what I already had.
Have been able to save out a plist that looks like it is capturing all the data - but I won't know until I try to read it all back in. Getting an error that I haven't sorted out:
NSFileCoordinator: A surprising server error was signaled. Details: Connection invalid
Not so surprising since I am saving locally not clear why it is trying to connect to iCloud at all. Hopefully I can switch that off.
I'm not sure where you get the thing about UIDocument using NSKeyedArchiver. For a simple implementation all you need to do is provide an NSData representation of your document contents -- it doesnt matter whether you generate that data from your model objects with NSCoder, NSKeyedArchiver, NSPropertyListSerialization, or some custom scheme.
Given that, I don't see any reason it shouldn't work with the data model you describe.
I'm developing an app which needs to show some logos. These logos are just 8kb PNG files, and I'm just going to handle a little amount of them (10-20 at most). However, these are downloaded from the Internet because they might change. So, what I'm trying to achieve is, making the app to download them (done), storing them into the file system, and only downloading again whenever they change (might be months).
Everyone seems to use Core Data, which in my opinion is something designed for bigger and more complex things, because my files will always have the same name plus don't have relations between them.
Is the file system the way to go? Any good tutorial?
Yes, the file system is probably your best option for this. You say that you've already implemented the downloading. How have you done so? With NSURLConnection? If so, then at some point, you have an NSData object. This has a couple of write... methods you can use to save the data to a file on the filesystem. Be sure to save the files in the right place, as your app is sandboxed and you can't write anywhere you like.
The advantage Core Data brings is efficiency. Using NSFetchedResultsController to display your logos in a tableview gets you optimized object loading and memory management. It will automatically load only the items which can be displayed on one screen, and as the user flicks through the table it will handle releasing items which move offscreen. Implementing that on your own is not a simple task.
If you want to build and display your data without Core Data, you'll probably want to use NSKeyValueCoder, which will allow you to easily write an array or dictionary of objects (including nested arrays, dictionaries, and images).
I am writing a very simple application, for the iPhone. Unfortunately I am really a newbie.
What I am trying to do is to save data at the end of a user experience. This data is really simple, only string or int, or some array.
Later I want to be able to retrieve that data, therefore I also need an event ID (I suppose).
Could you please point out the best way, API or technology to achieve that, XML, plain text, serialization... ?
Use NSUserDefaults. Straight forward and easy to use. This will handle all File I/O for you, and takes only a couple lines of code.
NSUserDefaults is a good choice for small amounts of data.
If you need to manage something larger than a kilobyte or so, you might consider using the initWithContentsOfFile: methods of NSArray or NSDictionary to read in a .plist file. To write the file, use the writeToFile:atomically: methods. This file needs to go in your app's documents directory.
Me and my team created a simple class for this purpose which as Mark pointed out makes use of NSUserDefaults. Hopefully this helps you out...
http://getsetgames.com/2009/10/07/saving-and-loading-user-data-and-preferences/