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.
Related
I was wondering whether there are any other ways in swift to save data locally on device, which will be available also after app close without using NSUserDefaults.
If there are, in which cases is that specific solution preferable?
I know this is kind of general, but I know just this one way to do saving locally and from my experience, there is always more than one way to do something(unless there isn't).
Any answers would be greatly appreciated
Yes there are different ways to store data locally.
As you have mentioned one of them is
NSUserDefaults
In addition to that you can also:
Use files such as plist, JSON or your own custom format.
Use Core Data
Use SQLite
And also you can combine between those.
Here some nice post Core Data VS SQLite
Now for:
in which cases is that speciffic solution preferable
I would say that NSUserDefaults is good when you need to store some small pieces of data, for example: Numbers, Booleans, Strings.
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.
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.
If I have a large amount of information that will be randomly used while the app is being used, what is the best way to store and access that data?
The app completely relies on the static text that I have and will need to grab certain parts and concatenate them depending on what the user selects within the app.
Is it best to load it into Core Data when the app loads the first time and then check if it is loaded every time after that? If so, how?
Core Data's primary focus is not persisting data but instead on managing a complex graph of objects that contain and manipulate data. The API is intended to create the entire model layer of a Model-View-Design application.
If you have a lot of chunks of text all that need separate logic or if your app will create those chunks out of a large body of text, then core data is a good choice.
If you just have something like a very basic text editor then probably not.
Core Data is completely inappropriate for your use case.
Store your text in a .strings file and use NSLocalizedString() to access it. This will provide a convenient way to lookup text by key and make localization simple.
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.