Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best method to store data for an iOS app? [closed]

Tags:

ios

swift

store

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?

like image 301
Ari Avatar asked Jul 07 '18 04:07

Ari


People also ask

Where do iOS apps store data?

iOS apps store data locally in different ways like plist(similar to shared_pref in android), NSUserDefaults, Core data(sqlite), Keychain. Theses files can be found using any file explorer utility under the application folder.

How do you store sensitive information in your iOS app?

In Order to save our apps sensitive data, we should use Security services provided by Apple. Keychain Services API helps you solve these problems by giving your app a way to store the small amount of user data in an encrypted database called the keychain.


1 Answers

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.

like image 189
Caleb Avatar answered Oct 12 '22 21:10

Caleb