iOS persistante de la stratégie de stockage

Je suis de développer une application qui permettra d'enregistrer les données dans le système de fichiers local. Les données qui seront enregistrées seront la plupart du temps NSString et NSDate. Les données ne seront pas enregistrées qui, souvent, peut-être de nouvelles données seront introduites 10 fois lors d'une utilisation normale. Les données doivent également être réversible (CRUD)

Comment dois-je enregistrer ces données? Tout d'abord il est nécessaire de modéliser ces objets? Si non dois-je utiliser les listes de propriété? Ou SQLLite3?

Dois-je archiver les modèles de la classe? Utilisation SQLLite3?

EDIT: j'ai accidentellement laissé de côté certaines informations essentielles à propos de l'application. En fait mon application va avoir 2 modèles de données qui ont un agrégé de la relation. Donc mon premier modèle de données (permet de l'appeler DataA), ce qui aura un NSString et NSDate aura également une référence à la deuxième modèle de données (permet de l'appeler DataB) qui lui-même sera composé d'une NSString et un NSArray. De sorte qu'il devient un peu plus compliqué maintenant. Si un objet de DataB est supprimé, il convient bien sûr de cesser d'exister en DataA (mais le reste de DataA doit être laissé intact)

si la quantité de données n'est pas énorme, comme u est dire.. vous pouvez utiliser NSUserDefaults...Sa simple et facile à utiliser.

OriginalL'auteur Peter Warbo | 2012-01-04

Ce type de données semble être très simple à stocker et de récupérer et de ne pas avoir d'autres dépendances comme un horridly graphique d'objet complexe.

Vous devez stocker ces données dans un fichier plat ou en NSUserDefaults.

Je vais vous donner un exemple de deux, à l'aide de l'objet de l'archivage avec l'utilisation de la NSCoding protocole:

@interface ApplicationData <NSCopying, NSCoding> {}
@property (nonatomic, strong) NSDate *someDate;
@property (nonatomic, strong) NSDate *someOtherDate;
@property (nonatomic, copy) NSString *someString;
@property (nonatomic, copy) NSString *someOtherString;
@end
@implementation ApplicationData
@synthesize someDate = _someDate, someOtherDate = _someOtherDate, someString = _someString, someOtherString = _someOtherString;
- (NSArray *)keys {
static dispatch_once_t once;
static NSArray *keys = nil;
dispatch_once(&once, ^{
keys = [NSArray arrayWithObjects:@"someString", @"someOtherString", @"someDate", @"someOtherDate", nil];
});
return keys;
}
- (id) copyWithZone:(NSZone *) zone {
ApplicationData *data = [[[self class] allocWithZone:zone] init];
if(data) {
data.someString = _someString;
data.someOtherString = _someOtherString;     
data.someDate = _someDate;
data.someOtherDate = _someOtherDate;
//...
}
return data;
}
- (void) encodeWithCoder:(NSCoder *) coder {
[super encodeWithCoder:coder];
NSDictionary *pairs = [self dictionaryWithValuesForKeys:[self keys]];
for(NSString *key in keys) {
[coder encodeObject:[pairs objectForKey:key] forKey:key];
}
}
- (id) initWithCoder:(NSCoder *) decoder {
self = [super initWithCoder:decoder];
if(self) {
for(NSString *key in [self keys]) {
[self setValue:[decoder decodeObjectForKey:key] forKey:key];
}
}
return self;
}
@end

Alors, dites dans votre délégué d'application, vous pouvez faire ceci:

@interface AppDelegate (Persistence)
@property (nonatomic, strong) ApplicationData *data;
- (void)saveApplicationDataToFlatFile;
- (void)loadApplicationDataFromFlatFile;
- (void)saveApplicationDataToUserDefaults;
- (void)loadApplicationDataFromUserDefaults;
@end
@implementation AppDelegate (Persistence) 
@synthesize data;
- (NSString *)_dataFilePath {
static NSString *path = nil;
static dispatch_once_t once;
dispatch_once(&once, ^{
path = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) stringByAppendingPathComponent:@"xAppData.dat"];
});
return path;
}
- (void)loadApplicationDataFromUserDefaults {        
NSData *archivedData = [[NSUserDefaults standardUserDefaults] objectForKey:@"appData"];
self.data = [NSKeyedUnarchiver unarchiveObjectWithData:archivedData];
}
- (void)saveApplicationDataToUserDefaults {
NSData *archivedData = [NSKeyedArchiver archivedDataWithRootObject:self.data];
[[NSUserDefaults standardUserDefaults] setObject:archivedData forKey:@"appData"];
[[NSUserDefaults standardUserDefaults] synchronize];
}
- (void)loadApplicationDataFromFlatFile {
NSData *archivedData = [NSData dataWithContentsOfFile:[self _dataFilePath]];
self.data = [NSKeyedUnarchiver unarchiveObjectWithData:archivedData];
}
- (void)saveApplicationDataToFlatFile {  
NSData *archivedData = [NSKeyedArchiver archivedDataWithRootObject:self.data];
[archivedData writeToFile:[self _dataFilePath] atomically:YES];
}
@end

Avertissement: je n'ai pas testé ce code.

Merci pour vos approfondie de la réponse. En fait mon application va avoir 2 modèles de données qui ont un agrégé de la relation. Donc mon premier modèle de données (permet de l'appeler DataA), ce qui aura un NSString et NSDate aura également une référence à la deuxième modèle de données (permet de l'appeler DataB) qui lui-même sera composé d'une NSString et un NSArray. De sorte qu'il devient un peu plus compliqué maintenant. Si un objet de DataB est supprimé, il convient bien sûr de cesser d'exister en DataA.
Si c'est le cas, je vous conseille d'utiliser de Base de Données parce que ce serait la meilleure façon de faire de relation en cascade des règles et le. Il devrait être de la saleté simple à mettre en œuvre, même si je suis sceptique sur le compromis de la création d'une Base de Données de la pile juste pour le faire...
Donc en gros, ça se résume soit à l'aide de l'archivage de mes modèles de données ou de l'utilisation de Base de Données?
Yep. Je ne recommande pas sqlite directement à tous dans ce cas.
Lorsque vous avez absolument besoin de filtrer les données avec SQL et aussi besoin de la performance bosse qu'il fournit par la suppression de la Base de Données intermédiaire. Je n'ai pas rencontré une situation qui satisfait à ces conditions, j'ai donc essayer de rester loin de lui si je le peux. Pour ne pas mentionner que le sqlite3 API est une douleur royale dans le cul à traiter.

OriginalL'auteur Jacob Relkin

1

NSUserDefault est un bon choix si vous avez seulement un nombre limité de données.
Mais si vous envisagez de filtrage et de récupération, alors vous devriez jeter un oeil à la Base de Données pour stocker des objets.

Même si l'objet graphique est minime, vous gagnerez de l'objet mis en cache et de gestion gratuit gestion du undo/redo.

OriginalL'auteur Sylvain G.
1

Je vous suggère d'aller avec NSUserDefaults. C'est sûrement la meilleure approche pour stocker les informations relatives à votre application, et n'importe quelle application. De vérifier la la documentation !!

OriginalL'auteur Legolas

Vous devez vous connecter pour publier un commentaire.