I have a big amount of data (more then 100 entries) to show on a table view. The data will be static, so i was thinking in store it on a plist file. The problem is when it is shown in table view, the user will be able to select or deselect a row and this information must be stored.
In other words the app will have a list of things and the user can select the things he own.
What's the best way to store the data in the app and the selected information?
PS.: I was avoiding Core Data, but if this is the best way how can i pre store the data in an entity?
100 entres isn't actually a large amount of data.
I would be inclined to use a plist for this small amount of data.
If you wanted, you could keep the user-data in the same plist too:
When app first runs it could copy the plist to the document directory so that it can be edited (the ownership data written).
Or, you could use a separate plist for the user-data.
There is no "best way", but one viable approach is to use a JSON file. If the data isn't too large, say the JSON file is much less than 1 MByte.
Creating and modifying a JSON file is quite comfortable in an editor. You can parse and create a representation as usual with NSJSONSerialization.
Hint: A JSON file which has N number of bytes, creates a representation of Foundation objects which roughly need a total of 5*N to 10*N allocated space.
The easiest way to track the selected and unselected row is here:
this code will save value with your tap on the cell.
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath{
BOOL isSelected=[[NSUserDefaults standardUserDefaults] boolForKey:[indexPath.row stringValue]];
[[NSUserDefaults standardUserDefaults] setBool:!isSelected forKey:[indexPath.row stringValue]];
}
Related
Im trying to create an application that will show in a table 3 floors and in the detailTextLabel show how many computers are available in those floors. For now I dont have the realtime data but I want to just keep some fake fixed data for now and be able to plug in the real data later.
I thought I would create an array, FloorList and FloorListAvailable. Floor list would contain "First Floor" "Second Floor" "Third Floor" and FloorListAvailable would show a number of how many computers are available.
Im currently unsure on how to go about this, it sounds easy enough to do but I cant wrap my head around it. I thought about using NSDictionary. I have used the .plist but can that be changed to by dynamic when I get the real time data?
One possible approach:
generate the realtime data by a script (e.g.); JSON would be a good format
let your app download the data files with a suitable frequency
parse the JSON (see: NSJSONSerialization into own objects; e.g. arrays
use these arrays as the data sources for your table views
whenever you get new data, send reloadData to your table views
q) what is the best method of storing persons complete details i.e.
steve > details contain :name address,dob, other details etc..
john > details contain :name address,dob, other details etc..
and many more records max would be around 200 tops.
now i want to display these individually and with the option to add them what is the suggested way?
i had a look at core data,userdefaults and NSFileManager but not sure what would be best way to implement such nested texts for save and load.
if you want to search or query them I would always recommend going with core data from the get go.
You'll only end up wishing you add gone down that route in a few months and then would have to factor in a migration.
For core data I use https://github.com/magicalpanda/MagicalRecord for new projects, it does most of the heavy lifting for you.
For a recent app I used NSUserDefaults. Basically keeping all my 'person' objects as NSDictionaries in an NSArray. This suited the app as the data was low, c100 records in use max.
I could just as easily have used a save to disk method, but as I did't have any other use for saving small amounts of preference data, it was just a convenience.
(remember, accessing NSUserDefaults brings back all its contents, not just the particular object you are interested in).
Hope this helps.
I have a bunch of game data (10 integers) I need to save and load.
Is it more efficient to use a NSMutableDictionary, add the items and save it, or to save each item into NSUserDefaults?(NSMutableDictionary is already created, when the data is loaded in on startup)
The same question goes for the loading, is it faster to load the dictionary and then extract the data, or just get each one from NSUserDefaults one at a time?
A benefit of NSUserDefaults is obviously the global access.
This is a trifling amount of data and relative efficiency doesn't even come into it. Go for the simplest code in this case, which is user defaults.
I'm loading in data from an sqlite database, storing the values i load from there in the instance variables of a custom class, and then adding this class to a mutable array, which i'm then assigning to the instance variable of my view controller, for use in a tableview.
I would, though, like to save this array into a .plist file in the documents directory on the app's first run, so that i can retrieve the whole object from there on load, rather than pulling all 214 items from the database.
Is this approach a better option? if so, could someone please help provide me with some code that will allow me to save an array of my custom classes as a .plist file? I've come across a lot of sample code on the web, but none of it works correctly.
I'd like to:
Check for the existence of the my_data.plist file.
If it exists, read it in as the array.
If it doesn't, read the data from the sqlite db into an array.
save this data to a .plist so that it can be read in faster later.
Thanks guys, appreciate any help you can give me.
It will probably be faster to just get the values from your database on launch. There will almost definitely be more cost to parse a plist containing these values than to just get them all from the database, unless the query you have to use to get them from the database is really slow.
Note also that once you're saving these objects to a plist on disk, you're actually going to be hurting performance of your program because you'll be writing your objects to disk twice and reading them from disk twice. You'll also be introducing opportunities for discrepancies between the plist and the database in the event of a bug or a crash.
That said, the only way to prove this to yourself may be to implement and profile both options, and compare actual numbers. Check out #occulus's link, above, for instructions how to read and write a plist. To profile your app, try using Instruments
When I google for "nsarray writetofile custom object" (no quotes) and click on the first link in the results, I find a really useful page.
For the record, it's this:
http://www.cocoabuilder.com/archive/cocoa/240775-saving-nsarray-of-custom-objects.html
Is there a way to select a fixed number of random entries from a Core Data store? I am just getting started with Core Data and have been stuck on this problem for quite some time.
As a last resort, I could query a large selection of entries into memory and then randomly select a fixed number.
Also, is there a way to specify custom SQL statements to be executed on the Core Data store? I realize that this would be highly unlikely since the underlying implementation of the store could be an XML file as well.
Mmm... maybe
[[[managedObjectsContext registeredObjects] allObjects] objectsAtIndex:r]
where r is random int between 0 and the number of objects minus one? Not efficient at all but quick and easy.
EDIT: if you want to pick the random object between a selection of your objects then create a fetch request that describes your object selection and do the same as above with the query results:
[[[managedObjectsContext executeFetchRequest:request error:&error] objectAtIndex:r]
With regards to your second question, that is one of the points of Core Data, to abstract away the underlying data store. Using NSPredicate and NSExpressions to build a fetch request, or storing one in the data model is the only way to query the store.
Not sure, but I think Core Data puts data into NSSets for you. So you might be able to use -[NSSet anyObject]. I haven't tested that or anything.