问题
I would like to develop a stock/item inventory app as I progress through learning swift. It would basically be something that has, Item Name, Quantity, and Location.
eg.
Lightbulbs, 25, Work Van
Switches, 6, Warehouse
When the user inputs this data and presses a button, whats the best method of storing this data and retrieving it later. I know I could append this to an array and display the array, but what if the app closes?
Should I be looking at learning database storage? Can I save data to the phone?
回答1:
If the data you want to store is very little and not sensitive, you can use UserDefaults For example, user's name, their age etc.
For Large amounts of data you should use Core Data, its a good and an easy way to manage your objects. For example, you have 1000 items, each with a property, you can basically use core data for that. It is pretty straightforward as how to create Managed Objects, store them and how to later retrieve them using queries.
Basically when you configure your project with core data, project creates an sqlite file attached to your project.
There are many tutorials on how to get started with Core Data, if you have an average experience with iOS, it will be a piece of cake for ya.
Here's a nice tutorial that will help you setup core data in your project:
https://www.raywenderlich.com/173972/getting-started-with-core-data-tutorial-2
回答2:
whats the best method of storing this data and retrieving it later.
The best method will depend on a bunch of factors, like:
- How many records do you want to save?
- Do you need to sync this data with a server?
- How much does performance matter?
- How much do you know about storing data using Swift and iOS?
- How likely is it that the data you want to save will change?
The answers to all of those questions are likely to change over time, as you learn more and make more progress on the app and perhaps come to understand the users' needs more. So the best method for saving data is to build something that will let you easily change or even replace the data storage system without requiring changes through the rest of the app.
In other words, you need to define an interface for your data storage needs. The interface is like a fence, with the actual data storage on one side, and the rest of the app (user interface, networking, etc.) on the other.
Having a clear interface to your data storage system will let you get your app up and running quickly with the simplest data storage system that could possibly work. You can store your data as an array of dictionaries, for example, write it all out to a property list using the Array method write(to:atomically:), and read it back using init(contentsOf:). So far, you've only described a need for a single kind of record, with each record having only a few fields. Storing the data in an array and writing it to a property list will work fine for hundreds, maybe thousands of entries; you'll likely have you rethink your user interface before you have a real need to rewrite your data storage system, because nobody likes to scroll through a list of hundreds of items.
As your app evolves and you discover that you don't want to keep all the data into memory at once, or you'd like to ship some data with the app and keep that separate from the data the user enters, or you'd like to speed up your data storage, you can write a new data storage system that conforms to the same interface. Then you can swap the new system in without affecting the rest of the app. So you can switch up to using something fancy like Core Data, or you can implement server-based storage, without having to rewrite big chunks of your app.
Creating a clear interface for your data storage system will also make it easy to write a set of unit tests that ensure that your data storage system does exactly what it's supposed to do and doesn't break. And having a set of unit tests will make it easy to ensure that a future version of your data storage system is as correct as the one it replaces.
Some others here have suggested using Core Data. Core Data is great, but using it is a lot more complicated than just reading your data from a file and writing it back when you're done. The difference between using an array to store your data and using Core Data to do it is very like the difference between a text file and a relational database. Core Data is an object graph manager: it can store many of different types of objects and the relationships between them, and it can store many thousands of all those objects and access them very quickly. When you start to keep track of images of the items in the inventory, the suppliers each of the items comes from, the customers who buy the items, the prices the items are bought and sold for, etc., Core Data will really simplify the task of managing all that data. But trying to learn and use Core Data now, while your needs are very simple, and while you're also trying to learn a new language, will slow you way down without any real benefit. Remember the KISS principle and start simple, but in a way that makes it easy to evolve.
回答3:
You can use either of the methods below depending on your exact requirement.
- Core data: You can find a tutorial here.
- Using a SQLite DB: You can find a tutorial here.
- If it is simple and does not require to store a lot of information, then you can even use the file system to store data. Even PLists are possible.
回答4:
For a single user who just logs in then you can store it in UserDefaults. But if you have to manage a list of users then use Core Data.
回答5:
There is a huge difference between these two. SQLLite is a database itself like we have MS SQL Server.
However CoreData is an ORM (Object Relational Model) which creates a layer between the database and the UI. It speeds-up the process of interaction as we dont have to write queries, just work with the ORM and let ORM handles the backend. For save or retrieval of large data, I recommend to use Core Data because of its abilities to handle the less processing speed of device.
As a result:
SQLite:
- Have Data Constrains feature.
- Operates on data, stored on disk.
- Can Drop table and Edit data without loading them in memory.
- Slow as compared to core data.
- You can use SQL for complex data structure
Core Data:
Don't have Data Constraints,if required need to implement by business logic.
Operates on in memory.(data needs to be loaded from disk to memory)
Need to load entire data if we need to drop table or update.
Fast in terms of record creation.(saving them may be time consuming)
No sql for this. Just load data to array and use in that array.
In my opinion; IF you need several data which settings of your app, or user authentication info or similar works use CoreData
If you have big data to storage, you need to select one of many data records use SQLLite.
Hope It helps.
来源：https://stackoverflow.com/questions/51219869/best-method-to-store-data-for-an-ios-app