iOS development--file storage for data persistence (i)

The author thinks that the greatest sorrow of the developer is that he knows how to use it but does not understand its principle. Before the code I think it is necessary to briefly explain some of the relevant knowledge points. Because the article or deep or shallow always have a suitable crowd. If a friend finds one of the incorrect points, it is appreciated. What is called data persistence:

In this case, I don't copy the abstract concept of textbooks. I think that since we have to write something out, let it be simple and clear.

To understand data persistence, it is important to know that data persistence is relative to caching, that the cache is stored in memory while the program is running, and that once the program is run, its memory is freed. The data that is cached in memory disappears as well.

Then data persistence is to solve the above problem, such as the common use: Save user-set avatar, nickname and other important information.

The solution is as follows: The data that needs to be saved during the run of the program is saved in some form (some vectors) rather than simply cached during the program's run. After this operation, the data can be read from the stored carrier again at the next run of the program, and we also implement data persistence

(The saved operation is called serialization, and the read parsing operation is called deserialization)

In short, the data is persisted by saving it in a certain form and then reading the parsing when needed.

Data storage is broadly divided into two main ways

1. File storage

Store the required data through files such as: Bin file xml file txt file, etc...

2. Database storage

Save the data to the corresponding table field in the database, the common database has SQL Server MySQL Oracle and SQLite

The following describes the format of the file storage in iOS development, and other content will be introduced in a later blog 1. File save path-application sandbox

We just talked about saving the data to a file, so there's a file where the file is saved.

In iOS, our app will package its files into a specific folder (directory), a folder called App Sandbox, each with its own app sandbox, and each sandbox is independent of each other. The reason for doing so, two words: safe. Mutual independence, That is, the program can not arbitrarily tamper with or delete the files of other programs, the browser saves the cookie file is the same, different domain names have different cookie files, and can not access other domain names related to the cookie file ... Pulled away, the interested friend expanded himself

2. Preliminary understanding of the sandbox's directory structure

1) Get the root path of our app sandbox: Nshomedirectory ()

2) Steps:

Step one: In Viewdidload: As shown, the right side is the sandbox path (copy)

Step two: Open the Finder and press the shortcut key Cmd+shift+g enter the sandbox path and return

Step three, get the sand box structure diagram

3. Application Sandbox Structure Action description

Document

Features: Saves data generated when the program runs and is automatically backed up via icloud, which is also backed up by default if the user synchronizes with itunes

Library/caches

Typically, data that can be re-downloaded or regenerated is usually a large, non-important data

Library/preferences

Save the app so preferences, such as the user chooses to remember the password. The directory is backed up by default when a user synchronizes with itunes

Tmp

Save the temporary data that is generated when the program runs, and use the completion to delete it. Be careful to delete to avoid wasting user space
Therefore, we need to store the data file in conjunction with the above listed in the directory characteristics, the corresponding data saved to the appropriate path below 4. Get path-related code: (Take documents for example)

Two different ways:

1. Stitching:

NSString HomePath = Nshomedirectory ();//Get sandbox root path

NSString documentpath = [HomePath stringbyappendingpathcomponent:@ "Documents"];

2. Search Catalog

Nsarray*patharray=nssearchpathfordirectoriesindomains (NSDocumentDirectory, Nsuserdomainmask, NO);

NSString documentpath = [Patharray objectatindexof:0];

List of properties for data storage

1). What is a property list:

The attribute list is essentially an XML-formatted suffix fame plist file (the space bar preview can see the obvious XML structure):

2). Features:

The amount of data stored is small, and by default only applies to specific objects
such as: Nsarray,nsmutablearray,nsdictionary,nsmutabledictionary,nsdata,nsmutabledata,nsstring,nsmutablestring, Nsnumber,nsdate

3). Code

Storage (archive, take nsdictionary as an example)

-(void) writedictionarytofile{//1. Initializing ObjectsNsdictionary *dic = @{                                @"name":@"Jack",                                @"Country":@" China",                                @"Province":@"Guangdong"                                }; //2. Save Path (Documents)NSString *path =[Nssearchpathfordirectoriesindomains (NSDocumentDirectory, Nsuserdomainmask, YES) firstobject]; Path= [path stringbyappendingpathcomponent:@"testdic.plist"]; //3 Saving Files[dic Writetofile:path atomically:yes];}

After the program runs we find the created file and open the effect:

Read (solution) code:

-(void) readdictionaryfromfile{    //1. Get path    nsstring *path =    [ Nssearchpathfordirectoriesindomains (NSDocumentDirectory,     nsuserdomainmask, YES) firstobject];     = [path stringbyappendingpathcomponent:@ "testdic.plist"];      // 2. Reading data    from a file Nsdictionary *dic = [nsdictionary Dictionarywithcontentsoffile:path];         NSLog (@ "%@", DIC);}

(breakpoint):

At this point we have implemented data storage and reading, but only to the system default supported objects, in real-world development we often need to file custom objects. Limited space, the next blog to continue

iOS development--file storage for data persistence (i)