iOS developer of how to keep some data after a user deletes application

In the development process, we sometimes delete some of the information stored in the user when installing the application in use when the user next time, this time we can use UIPasteboard use FindUIPasteboard and shear Keychain keychain version

Cut version of the
cut version is divided into the following two
UIPasteboardNameGeneral and UIPasteboardNameFind
both of which are system-level data can be retained after the application delete

Development, we often use the Find UIPasteboard UIPasteboard to save some data after users delete the application you want to keep, such as UUID, user name, password, etc.
Here is a code save uuid to UIPasteboard
create UDID

+ (NSString*) _uuidCreateNewUDID {
NSString* _openUDID = nil;

CFUUIDRef uuid = CFUUIDCreate(kCFAllocatorDefault);
CFStringRef cfstring = CFUUIDCreateString(kCFAllocatorDefault, uuid);
const char *cStr = CFStringGetCStringPtr(cfstring, CFStringGetFastestEncoding(cfstring));
unsigned char result[16];
CC_MD5(cStr, (unsigned int)strlen(cStr), result);
CFRelease(uuid);

_openUDID = [NSString stringWithFormat:
@"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%08x",
result[0], result[1], result[2], result[3],
result[4], result[5], result[6], result[7],
result[8], result[9], result[10], result[11],
result[12], result[13], result[14], result[15],
(unsigned int)(arc4random() % NSUIntegerMax)];

CFRelease(cfstring);

_openUDID return;
}

saved to the clipboard UDID

NSString *openudid = [self _uuidCreateNewUDID];
NSString *checkOpenUDID = [openudid stringByAppendingFormat:kOpenUDIDAdd, nil];

//先把UDID存入字典
NSMutableDictionary *localDict = [NSMutableDictionary dictionaryWithCapacity:2];
[localDict setObject:openudid forKey:kOpenUDIDKey];
[localDict setObject:[checkOpenUDID md5] forKey:kCheckOpenUDIDKey];

// synchronization data to the clipboard
UIPasteboard slotPB * = [UIPasteboard pasteboardWithName: Create kOpenUDIDPB: YES];
// set to permanent preservation
[slotPB setPersistent: YES];
// dictionary into the shear plate
[slotPB setData: [NSKeyedArchiver archivedDataWithRootObject: localDict] forPasteboardType: kOpenUDIDDict] ;

Note: users using the product we found that when the user closes the limit ad tracking privacy inside, and then the user deletes the application at the same time, cut version of the data will be cleared (it is also possible because the hard disk capacity tense went back to clear)

Keychain keychain
iOS save the keychain service provides a secure private information (passwords, serial numbers, certificates, etc.) manner. Ios Each program has a separate keychain storage. Starting ios 3.0, cross-program sharing keychain feasible.
Here is implemented using keychain access user name and password.
Apple already have an existing class encapsulates a good keychain, KeychainItemWrapper.h and KeychainItemWrapper.m files can be found in instances where GenericKeychain.
But here I just need to access user name and password, you do not have classes provided by Apple, and write their own classes to implement a simple enough.

KeychainManager.h

#import <Foundation/Foundation.h>

KeychainManager @interface: the NSObject
+ (KeychainManager *) default;
// keychain The dictionary storage objects
- (void) Save: (NSString *) Data-Service: (ID) Data;
// read the object in accordance with keychain dictionary
- (the above mentioned id) the Load: (NSString *) Service;
// delete the data in the keychain
- (void) the delete: (NSString *) Service;
@end

KeychainManager.m

#import "KeychainManager.h"

@implementation KeychainManager
+(KeychainManager*)default
{
static KeychainManager *keychainManager = nil;
if(keychainManager == nil)
{
keychainManager = [[KeychainManager alloc] init];
}
return keychainManager;
}
- (NSMutableDictionary *)getKeychainQuery:(NSString *)service {
return [NSMutableDictionary dictionaryWithObjectsAndKeys:
(id)kSecClassGenericPassword,(id)kSecClass,
service, (id)kSecAttrService,
service, (id)kSecAttrAccount,
(id)kSecAttrAccessibleAfterFirstUnlock,(id)kSecAttrAccessible,
nil];
}

- (void)save:(NSString *)service data:(id)data {
//Get search dictionary
NSMutableDictionary *keychainQuery = [self getKeychainQuery:service];
//Delete old item before add new item
SecItemDelete((CFDictionaryRef)keychainQuery);
//Add new object to search dictionary(Attention:the data format)
[keychainQuery setObject:[NSKeyedArchiver archivedDataWithRootObject:data] forKey:(id)kSecValueData];
//Add item to keychain with the search dictionary
SecItemAdd((CFDictionaryRef)keychainQuery, NULL);
}

- (id)load:(NSString *)service {
id ret = nil;
NSMutableDictionary *keychainQuery = [self getKeychainQuery:service];
//Configure the search setting
//Since in our simple case we are expecting only a single attribute to be returned (the password) we can set the attribute kSecReturnData to kCFBooleanTrue
[keychainQuery setObject:(id)kCFBooleanTrue forKey:(id)kSecReturnData];
[keychainQuery setObject:(id)kSecMatchLimitOne forKey:(id)kSecMatchLimit];
CFDataRef keyData = NULL;
if (SecItemCopyMatching((CFDictionaryRef)keychainQuery, (CFTypeRef *)&keyData) == noErr) {
@try {
ret = [NSKeyedUnarchiver unarchiveObjectWithData:(__bridge NSData *)keyData];
} @catch (NSException *e) {
NSLog(@"Unarchive of %@ failed: %@", service, e);
} @finally {
}
}
if (keyData)
CFRelease(keyData);
return ret;
}

- (void)delete:(NSString *)service {
NSMutableDictionary *keychainQuery = [self getKeychainQuery:service];
SecItemDelete((CFDictionaryRef)keychainQuery);
}
@end

在app delegate的使用

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
KeychainManager *manager = [KeychainManager default];

NSString *data = [manager load:@"myName"];
if (data == nil) {
NSLog(@"Save");
NSString *dataString = @"我是谁";
[manager save:@"myName" data:dataString];
}
NSLog(@"data = %@",data);

YES return;
}

run the app you will find Save only the first time you run the app when printing, if you are running after you delete the app, it will not erase the data
--------------- ------
Disclaimer: this article is CSDN blogger original article "chris-gardner", following the CC 4.0 by-sa copyright agreement, reproduced, please attach the original source link and this statement.
Original link: https: //blog.csdn.net/u014410695/article/details/50623591

Reserves the OS App upgrade file

 

There is such a problem, a large number of users to download data iOS devices, stored locally on the device, if the user upgrades the application itself, these files are still there.

Find some instructions on the official explanation and Stackflow

Where You Should Put Your App’s Files

To prevent the syncing and backup processes on iOS devices from taking a long time, be selective about where you place files inside your app’s home directory. Apps that store large files can slow down the process of backing up to iTunes or iCloud. These apps can also consume a large amount of a user's available storage, which may encourage the user to delete the app or disable backup of that app's data to iCloud. With this in mind, you should store app data according to the following guidelines:

  • Put user data in the <Application_Home>/Documents/. User data is any data that cannot be recreated by your app, such as user documents and other user-generated content.

  • Handle support files—files your application downloads or generates and can recreate as needed—in one of two ways:

    • In iOS 5.0 and earlier, put support files in the <Application_Home>/Library/Caches directory to prevent them from being backed up

    • In iOS 5.0.1 and later, put support files in the <Application_Home>/Library/Application Support directory and apply thecom.apple.MobileBackup extended attribute to them. This attribute prevents the files from being backed up to iTunes or iCloud. If you have a large number of support files, you may store them in a custom subdirectory and apply the extended attribute to just the directory.

  • Put data cache files in the <Application_Home>/Library/Caches directory. Examples of files you should put in this directory include (but are not limited to) database cache files and downloadable content, such as that used by magazine, newspaper, and map apps. Your app should be able to gracefully handle situations where cached data is deleted by the system to free up disk space.

  • Put temporary data in the <Application_Home>/tmp directory. Temporary data comprises any data that you do not need to persist for an extended period of time. Remember to delete those files when you are done with them so that they do not continue to consume space on the user’s device.

In other words, those general content downloaded from the Internet, including magazines, newspapers, video or something, should be placed <Application_Home> / Library / Caches directory

<Application_Home>/Library/

This directory is the top-level directory for files that are not user data files. You typically put files in one of several standard subdirectories but you can also create custom subdirectories for files you want backed up but not exposed to the user. You should not use this directory for user data files.

The contents of this directory (with the exception of the Caches subdirectory) are backed up by iTunes.

For additional information about the Library directory, see “The Library Directory Stores App-Specific Files.”

Library contents of that directory will be backed up by iTunes, except Caches directory, that is to say the network to download content files placed here will not be backed up,

 

Caches

Use this directory to write any app-specific support files that your app can re-create easily. Your app is generally responsible for managing the contents of this directory and for adding and deleting files as needed.

In iOS 2.2 and later, the contents of this directory are not backed up by iTunes. In addition, iTunes removes files in this directory during a full restoration of the device.

On iOS 5.0 and later, the system may delete the Caches directory on rare occasions when the system is very low on disk space. This will never occur while an app is running. However, you should be aware that iTunes restore is not necessarily the only condition under which the Caches directory can be erased.

The above written more clearly, under Library / Caches directory, under normal circumstances is not removed, I understand, but also proved that stackoverflow users, application upgrades, they also will not be deleted, in fact, the specific application upgrades system operation is such that:

 

Files Saved During Application Updates When a user downloads an application update, iTunes installs the update in a new application directory. It then moves the user’s data files from the old installation over to the new application directory before deleting the old installation. Files in the following directories are guaranteed to be preserved during the update process:

  • Application_Home/Documents
  • Application_Home/Library

Although files in other user directories may also be moved over, you should not rely on them being present after an update.

系统先新建一个应用目录,然后安装一个新版本应用,然后再把旧版本的应用数据拷贝过来,然后再删除旧版本的应用安装目录。

最后注意一下,Library/Caches目录下的数据虽然在一般情况下不会被删除,但是在系统恢复和其他一些罕见的情况下(比如非常底的磁盘空间条件下有可能)会被清除,所以你的程序每次都要检查一些,这些文件都还在不在了,不在的话只能重新下了。

Application_Home/Library/Caches Use this directory to write any application-specific support files that you want to persist between launches of the application or during application updates. Your application is generally responsible for adding and removing these files. It should also be able to re-create these files as needed because iTunes removes them during a full restoration of the device. In iOS 2.2 and later, the contents of this directory are not backed up by iTunes.

 

参考连接:http://stackoverflow.com/questions/7155964/will-application-home-library-caches-be-clear-on-app-update/7277797#7277797

File System Programming Guide

https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1

 

转:https://blog.csdn.net/messyhari/article/details/50481356

 

Guess you like

Origin www.cnblogs.com/xiaoshen666/p/11355888.html