I'm storing just one NSArray to NSUserDefaults, but this array may eventually have many objects inside.
Could it be a problem using NSUserDefaults?
I would say use Core Data just because you want to simplify your life when dealing with anything more than a hundred data objects within two or more categories or "entities".
Using Core Data means that you're not dumping the entire data set into memory when you load it. Instead, you're using what are called faults which fire when necessary to load additional relationships and associated data.
Migrating the data is also another big benefit of Core Data. When you need to change the data structure, you just create a simple migration and it's done automatically for you. If instead you had an NSArray or NSDictionary in the user defaults, you'd have to iterate over the entire thing and try to change the data structure or migrate an old key name to a new key name. Not an easy task.
Another benefit of Core Data is that it works seamlessly with UITableView and UICollectionView to intelligently search and load only relevant items within your data set which helps improve overall app performance. This is all done via NSFetchedResultsController.
Working with one type of NSArray such as People that only has a hundred people in it shouldn't be a big deal and you can use NSUserDefaults for that as long as the People array doesn't have a lot of associated data stored within it.
Honestly, every app I create that needs any kind of data storage other than basic user preferences uses Core Data now. I don't waste my time on Property Lists or user defaults anymore and I would recommend you not to either.
NSUserDefaults is named as it is for a reason. It's designed to store a handful of user preferences and settings for your app, not the bulk of its data. If you're storing anything that resembles a database, NSUserDefaults is not the way to implement it -- use Core Data, as per #iWasRobbed's answer.
NSUserDefaults only use to store limited amount of data.if you have large amount of data you should go with coreData.
Related
usually in Android I use </string-array name=""> tag in .xml file and refer to it inside the code by its name.
what is the best practice to create an array in IOS that I can use in multiple views without having to create it over and over again?
Depending on what values you want to store in your array and if you want to persist if you need to write into the array and persist it between app runs as well, you have several methods.
Store the array in UserDefaults. You can read from/write to UserDefaults from each of your ViewControllers and your data will be persisted even if the user quits the app.
Store it in a file. I wouldn't really recommend this option, unless you have a lot of data to store that can be easily represented as String/NSData.
Store data in a shared, singleton variable. This method is only suitable if you don't want to write into your array or you don't need to persist it between runs.
Use a database framework (CoreData or Realm). This is only recommended, if you have really complex data, but since you mentioned only an array, this shouldn't be your case.
Based on the amount of information provided in your question, I would suggest going for UserDefaults, it is quite easy to handle data in UserDefaults and it should be sufficient for your task.
I am really confused on what the Core Data actually is. Or I guess my question is, when dealing with a database, would you use Core Data? Like if I wanted access values from a database would I be using Core Data to access those values? How would I approach this problem?
Thank you so much for the help.
Core Data is an framework that does the work of "object persistence". In other words, it's code you can use that takes care of saving a collection of objects to disk and loading them again later. It does a lot of work to allow you to store lots of data and load only the objects you need at a time, and unload ones when memory is tight.
Core Data can use a database to accomplish this, but that's it's business, not yours. When you use Core Data, it is a black box. You tell it to save the data and then step out of the way.
If you want to interact with an existing database, such as a MySQL database on a web server, that's a completely different matter. You might use Core Data to store local copies of objects on your device, but in that case Core Data won't care that the objects are copies from some other database. It doesn't care.
It is a convenient, native means of storing data in your iOS applications. Don't think of it as sqlite although you can view the files it creates with various sqlite tools. Instead think of it as a tool for manipulating an object graph of information important to your app.
I've used it in two main ways. First to store a bunch of static data that is important to an app, in one case that was a large amount of location data for an indoor mapping application. What arrived as a massive CSV file of waypoints was converted to core data. Core Data was incredibly useful for this because it allowed preparing a sqlite file which was shipped with the application containing all the infomation. Updates from a web service arrive as more CSV that is added to the Core Data to keep information current. At runtime the location information object (the waypoint a user is at) is retrieved with a predicate (i.e. the point they tapped on) and that object, through its Core Data relationships, indicates where it is possible to go from that point. Core Data provided the information necessary to perform A* routing through the indoor map.
Second it is great when you have a bunch of objects arriving as JSON and you want to be able to store and access those objects later. Let's say you have a typical app where you have a User and some information about the User, let's call it Thing. Users have Things. When you want to know something about a User you retrieve the Core Data record using a predicate - typically "name" or similar - and you get all the information you stored about the User back. Again you can make use of relationships to explore the user's connections and make displaying information easy. Perhaps the User has many Things, then you can say "user.things" and you get a NSSet of NSManagedObjects representing those Things.
You use it like a database. Its utility is that it is easy to access from anywhere in your iOS code, it is easy to store and easy to retrieve information also. Faulting lets you retrieve one object and navigate to any object connected through relationships by following the relationships. Because you define the attributes and relationships yourself in the data model editor it is easily customized for what you need to store. To me it is one of the most used and most useful parts of iOS.
When you want to automate display of information from Core Data you can use a NSFetchedResultsController to initiate a fetch and to respond through delegate methods to changes to the underlying data. If you set up a UITableView to use a NSFetchedResultsController as data source, you can have the table automatically update whenever the objects displayed in the cells changed. Very useful for apps where you periodically update information and want what is displayed to be kept current.
When your object model changes it is possible to maintain all of your existing information and migrate it to the new model. Core Data manages automatic (lightweight migration) when it can, or if you have made more radical changes you can supply rules to handle the migration.
The limitation of Core Data is that it is not great for storing binaries. If you have images that you need to store, far better to store a path to the location of the image than trying to store the actual data.
Yes, if you want a local database on your device, Core Data is the appropriate technology. It probably makes sense to start your research with the Core Data Programming Guide.
You can alternatively use SQLite (which Core Data uses in the backend), but Core Data offers some material advantages and is the preferred database interface for iOS. If you decide to pursue SQLite for any reason, though, I'd suggest you contemplate using the FMDB Objective-C SQLite wrapper.
But Core Data is generally the way to go.
I am relatively new to iOS and programming, and I made an app before, but it used a plist for storage, which I saved to the documents folder. Now, I am thinking about switching over to Core Data, but it looks a little complicated, and I'm not sure if it will work for what I want. I am going to have a bunch of data which I need to graph, so I'm not sure if Core Data is best for this, as it seems that I cannot create an array type in the .xcdatamodeld file. What are some other advantages of Core Data? Is it faster? Easier to use (once you set it up)?
Update: For anyone wondering, I finished the app, and it was totally worth it to learn how to use Core Data, and it was a lot less complicated that I originally thought. Doing it with plists would have been hell. The way they go about doing it seemed a little cryptic at first but if you just start using it you will get it. The relationships are really what is awesome about it.
A few advantages off the top of my head:
Much better memory management. With a plist you must load the entire thing into memory; with Core Data only the objects you're currently using need to be loaded. Also, once objects are loaded, they're normally placeholder "fault" objects whose property data doesn't load until you need it.
Related to the above, when you have changes, you can save only the changed objects, not the entire data set.
You can read/write your model objects directly instead of converting them to/from something like an NSDictionary.
Built-in sorting of objects when you fetch them from the data store.
Rich system of predicates for searching your data set for objects of interest.
Relationships between entities are handled directly, as properties on the related objects. With a plist you would need to do something like store an object ID for a relationship, and then look up the related object.
Optional automatic validation of property values.
Data models don't use arrays, but "to-many" relationships are modeled as sets.
It's a matter of what you're saving. For simple strings, arrays, dictionaries, it's fine to use a plist. For something more complicated (data, images, non-object information) or something with to-many relationships (think relationship between song to album, or photo to photographer), then something like a more robust solution might work better like SQLite.
CoreData is an objective-c-based wrapper around SQLite. If you think you might want to something more complicated, CoreData might be the way to go.
If you need a quick tutorial, I'd check out: http://www.raywenderlich.com/934/core-data-tutorial-getting-started
This got me going and allowed me to learn the basics the workings of CoreData.
Good luck!
I have been designing my app to store local user data which is changed / sorted and referenced regularly to be stored as global variables held by the app delegate and referenced through:
appDelegate = [[UIApplication sharedApplication]delegate]
Which seems to work though is most likely not best practice, is there any downsides to just holding the same data in NSUserDefaults, SQL Lite seems a bit heavy for my needs considering the data itself is a couple of small arrays of custom objects and is refreshed on start up and throughout the app.
Is there a general best practice for local storage, or does it really depend?
I recommend using Core Data. Although the first experience may be a little confusing, the investment will be worth it.
What you're doing is fine. A better practice would probably be to have a singleton class that contains all the related data. Then anywhere you need the day you just call [[globalData instance] arrayOfData] and have it. That way you abstract the data from your app delegate into a centralized place.
NSUserDefaults is used to store information between app launches. Use it to store settings or things that you read each time the app launches or use it to save the state of the app so a user can relaunch and be in the same place after they exited. There isn't really any noticeable performance issues unless the data you are storing is rather large.
for my needs considering the data
itself is a couple of small arrays of
custom objects and is refreshed on
start up and throughout the app.
As your current requirements are limited to small arrays and custom objects, NSUserDefaults could be used.
But while using NSUserDefault we should take care of these two facts.
1.) For custom object you will need to use Encoding Protocols for directly saving them using NSUserDeraults.
2.) NSUserDefaults some times shows strange behavior if we don't synchronize it properly. you can use its `[NSUserDefaults synchronize].
Core Data should be used when you are working many with interrelated custom objects. Because its concept of object relationship mapping and direct object management is quite good.{at lower layer it uses SQLite}.
SQLite on the other hand is relatively easy to implement and has C api for interaction with system. Here you will need to break down custom object into attributes and run queries.
I'm working on an application that has a read-only database shipped with it.
The user will run the application and be able to select a series of "favourites" from the database which will appear in there "favourites" tab bar section. I.e. storing the primary keys.
With each update to the application the read only data will potentially contain more entries or have things like spelling mistakes fixed etc.
I'm using Core Data but I'm unsure whether to use it for storing the users "favourites" as-well. As - to my way of thinking - this might cause headaches for migration. Is this the case?
Should I consider storing the "favourites" in a plist perhaps and perform some sort of query to retrieve the records? Any recommendations?
Also what internal pieces of an iphone application are kept (or can be kept) during an update?
Phew I think that's it.
Thanks for any answers you might have.
Cheers,
Matt
I'm using Core Data but I'm unsure
whether to use it for storing the
users "favourites" as-well. As - to my
way of thinking - this might cause
headaches for migration. Is this the
case?
If you're going to port the app to another platform, then Core Data is not the way to go. And since we are talking about a static database, I'd keep it simple - read it once, do what you need with it and close it and forget about it. Not like a real database where you're doing multiple GETs and some amount of additions, modifications and deletions.
Should I consider storing the
"favourites" in a plist perhaps and
perform some sort of query to retrieve
the records? Any recommendations?
Your database could be a plist too. After the user selects their favourites, you can easily store them in yet another plist. This one goes in the Documents or Prefs folder.
When you release a new app, you should probably compare the favourites with the new entries to correct any typos or other changes, if applicable.
Also what internal pieces of an iphone
application are kept (or can be kept)
during an update?
I believe that your app is replaced but your Documents and Preferences folders are kept intact.