Storing objects in iOS for later use
Asked Answered
E

3

6

My app is pulling in JSON data from our web service. In all instances up til now, the information would be retained in memory or just refreshed on the fly with no need to retain anything locally other than the login token used in the API. With one of the new features we are adding, we will be taking in a group of locations, 26 max, with long, lat, radius, and name.

I also need to add 1-2 fields to this data to create a larger object. So my question is, what would be the best way to store this type of data in the iOS filesystem? Currently I have been using the NSUserDefaults, but that seems sort of limited or ill advised for larger amounts of data. Maybe not.

This data will need to be retrieved, changed or edited, and resaved. All of this while still retaining the ability to pull any of those 26 objects. Thank you in advance for reading and helping out.

Engel answered 7/8, 2011 at 12:2 Comment(0)
V
5

For such a small amount of data (26 items) I suggest archiving.

Save to plist using NSKeyedArchiver/NSKeyedUnarchiver. Read your data from the delegate's didFinishLaunchingWithOptions, and listen for UIApplicationWillResignActiveNotification to save it.

A NSUserDefaults is a plist with features designed to store user preferences. It's often used instead a regular plist to save a couple of lines of code, which I think it's a bad idea because you get an additional complexity unrelated to your task.

If you want the login to be protected against someone stealing the device and performing forensics use the Keychain. You may want to use a wrapper and read some articles, comment if you are interested.

If you look for more features see Best way to store data on iphone but doesn't seem to be the case now.

Some code to get you started... Register to call save on app resign:

[[NSNotificationCenter defaultCenter]
        addObserver:self 
           selector:@selector(saveMyData) 
               name:UIApplicationWillResignActiveNotification 
             object:nil];

On each object of the graph/dictionary/whatever you want to archive implement NSCoding:

- (void)encodeWithCoder:(NSCoder*)coder {
    [coder encodeObject:myIvar forKey:kmyIvar];
}

- (id)initWithCoder:(NSCoder*)coder {
    if((self = [super initWithCoder:coder])) {
        self.myIvar = [[coder decodeObjectForKey:kmyIvar] retain];
    }
    return self;
}
Veronikaveronike answered 7/8, 2011 at 12:32 Comment(2)
I have seen some examples of using the KeyChain for storing login info which I was planning on implementing. Thanks for the info.Engel
Archiving sure sound like much better idea for 20-ish items then CoreData. And if you need to store username and password, there is Apple's sample source which I described how to use here: #6972592Ignatius
N
3

Check out this guide on core data. It's the best way to store data locally on your device. It's a native cocoa API and it is bindings compatible. Plus, you can choose whether to store data as XML, SQLite, and Binary.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html

For anything remotely large, I would use this.

Noland answered 7/8, 2011 at 12:5 Comment(0)
B
1

I had this same question and just figured out a much better solution.

What you could do is just store the JSON string as your NSUserDefault. Then, when you reload the app use the same method (or framework utility) you used to map the JSON string to your objects the first time. This way you can still take advantage of the ease of NSUserDefaults.

If you're using RestKit to manage your web services it gets even easier. The answer on this post shows how to use RestKit's JSON parser to map from JSON to your object.

Deserializing local NSString of JSON into objects via RestKit (no network download)

Baber answered 18/8, 2012 at 0:23 Comment(1)
very nice, I will use this approach in my project, thanks! :-)Gnat

© 2022 - 2024 — McMap. All rights reserved.