Edit Programmatically plist in the App bundle at development time - ios

I have created a plist on XCode that will have a few values that I can't insert manually. So I want to add this values programmatically at development time. But it seems that I can only read the plist I can not save a plist that is on the App bundle, which makes sense at runtime.. When I will distribute my app I want everyone to have this plist file that's why I am not saving on documents or cache. How can I achieve what I want?

From http://www.karelia.com/cocoa_legacy/Foundation_Categories/NSFileManager__Get_.m (pasted below) you can build a path within the user's personal library with the -(NSString *) pathFromUserLibraryPath:(NSString *)inSubPath method found there.
For example, NSString *editedPlist = [self pathFromUserLibraryPath:#"my.plist"]; gets you the name of the modified plist within the user's library (even if that plist doesn't exist yet).
How you read/write it is according to what kind of plist you have, but you could read it into a dictionary with:
NSMutableDictionary *thePlist= [[NSMutableDictionary alloc] initWithContentsOfFile:editedPlist ];
If you are unable to read, easily detected by, for example [thePlist count] == 0, then you would instead call the same initWithContentsOfFile: initializer with a path to the template within your bundle, but you would then write the plist out to the editedPlist path so it appears in the user directory.
Here is the utility method I referenced above:
/*
NSFileManager: Get the path within the user's Library directory
Original Source: <http://cocoa.karelia.com/Foundation_Categories/NSFileManager__Get_.m>
(See copyright notice at <http://cocoa.karelia.com>)
*/
/*" Return the path in the user library path of the given sub-path. In other words, if given inSubPath is "foo", the path returned will be /Users/myUser/Library/foo
"*/
- (NSString *) pathFromUserLibraryPath:(NSString *)inSubPath
{
NSArray *domains = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask,YES);
NSString *baseDir= [domains objectAtIndex:0];
NSString *result = [baseDir stringByAppendingPathComponent:inSubPath];
return result;
}

What I would suggest is writing code that checks for the plist in the documents directory at start. If it's there, read it into memory.
If you don't find the file in the documents directory, read it from the app bundle instead. Then drop into the code that uses it from memory and writes the changed version to the documents directory.
Remember that all the objects you read from a plist file are read as immutable, even if you wrote mutable objects into the file. You have to write code that makes mutable copies of anything that you want to change. (And have to implement a mutable deep copy if you have complex structures like arrays of dictionaries that in turn contain arrays of strings.)

Related

Large files downloaded to Documents and backed up to iCloud

I have an iOS app in the app store that can download relatively large files that need to stay on the device for offline use. Those files are currently stored in the app's Documents folder but I'm just now reading that the Documents folder is backed up and should really only be used for user-generated content. This Apple technical Q&A states that the NSURLIsExcludedFromBackupKey should be set to prevent backup. This states that an app's /Library/Caches is the right place to put these kinds of files although further reading suggests that the folder may be cleared when the device is low on storage which is unacceptable for this app. I believe /Library/Application Support/ is then the best location for them -- does this sound right?
Unfortunately, this mistake got through the app review process. What are some best practices for fixing this now that people are using the app and already have some files persisted to the Documents folder and to their backups? It seems I need to move all the existing files and set their NSURLIsExcludedFromBackupKey on app update. How do I guarantee that this is done exactly once and that it isn't interrupted? Is moving the files out of the Documents folder important or could I leave them there? Will changing the files' backup status remove them from existing backups?
I'm using Swift 2.1.1 and targeting iOS 8.0+.
As stated in the technical Q&A, you best bet could be create a subdirectory in the Documents, and exclude that subdirectory once.
I don't believe you can write a 'do it once and be sure it is done' routine, since you can't guarantee your app doesn't crash while it is running. You certainly could set a completion flag when you are sure it is done so that once it is done you don't have to run it again.
Exclude your directory from backup, not the individual files.
From Xcode:
You can use this property to exclude cache and other app support files which are not needed in a backup. Some operations commonly made to user documents cause this property to be reset to false; consequently, do not use this property on user documents.
Here is the strategy I have used with good results
(sorry, its in objective-c -- I'm not a swift guy. Hopefully it will give you the idea):
- (BOOL)moveAllFiles{
// Searches through the documents directory for all files ending in .data
BOOL success = true;
NSString *myNewLocation = #"/store/my/files/here/now";
// Get the documents directory
NSArray *documentDirectories = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentDirectory = [documentDirectories objectAtIndex:0];
// Get all files ending in .data (whatever your file type is)
NSArray *dataFilesArray = [NSArray arrayWithArray:[NSBundle pathsForResourcesOfType:#"data" inDirectory:documentDirectory]];
// If you have multiple resource types, use this line once each for each resource type, then append the arrays.
// Iterate the found files
NSString *fileName = [NSString string];
for (int i=0; i<[dataFilesArray count]; i++) {
fileName = [[dataFilesArray objectAtIndex:i] lastPathComponent];
// Move file, set success to false if unsuccessful move
if (![[NSFileManager defaultManager] moveItemAtPath:[dataFilesArray objectAtIndex:i]
toPath:[myNewLocation stringByAppendingPathComponent:fileName]
error:nil]) {
success = false; // Something went wrong
}
}
return success;
}
Now use the value of success to set a key in the user defaults file. Check for that key on startup. If it is false (or absent), run this routine (again).
This example is with file paths. You can do the same thing with file URLs if you wish.

How can I change .plist entries based on my Scheme?

I have some App-Info.plist entries that need to change based on my environment. When I'm doing developmental work, they need to be one set of values, vs QA vs Production.
What would be nice is if I could simply have a script or something that runs based on the Scheme used to do the compilation.
Is this possible?
You can do it by performing some extra steps:
Duplicate [AppName]-Info.plist file by any name. Example: [AppName]-Info-dev.plist or [AppName]-Info-staging.plist etc
Map newly created .plist file in App's Target Settings. Get idea from following screenshot:
At the end, if you want to get some entry from .plist file then you need to get it like: [[[NSBundle mainBundle] infoDictionary] objectForKey:#"baseUrl"]
Project setting will automatically pick correct .plist file and give you required value.
I think msmq's answer is valid, but you should be a little careful about using the main info.plist this way. Doing that suggests that all your versions of info.plist are almost identical, except for a couple of differences. That's a recipe for divergence, and then hard-to-debug issues when you want to add a new URI handler or background mode or any of the other things that might modify info.plist.
Instead, I recommend you take the keys that vary out of the main info.plist. Create another plist (say "Config.plist") to store them. Add a Run Script build phase to copy the correct one over. See the Build Settings Reference for a list of variables you can substitute. An example script might be:
cp ${SOURCE_ROOT}/Resources/Config-${CONFIGURATION}.plist ${UNLOCALIZED_RESOURCES_FOLDER_PATH}/Config.plist
Then you can read the file using something like this (based on Read in the Property List):
NSString *baseURL;
NSString *path = [[NSBundle mainBundle] pathForResource:#"Config" ofType:#"plist"];
NSData *plistXML = [[NSFileManager defaultManager] contentsAtPath:plistPath];
NSString *errorDesc = nil;
NSDictionary *dict = (NSDictionary *)[NSPropertyListSerialization
propertyListFromData:plistXML
mutabilityOption:NSPropertyListImmutable
format:NULL
errorDescription:&errorDesc];
if (dict != nil) {
baseUrl = dict[#"baseURL"];
} else {
NSAssert(#"Could not read plist: %#", errorDesc); // FIXME: Return error
}
There are other solutions of course. I personally generally use the preprocessor for this kind of problem. In my build configuration, I would set GCC_PREPROCESSOR_DEFINITIONS to include BaseURL=... for each build configuration and then in some header I would have:
#ifndef BaseURL
#define BaseURL #"http://default.example.com"
#endif
The plist way is probably clearer and easier if you have several things to set, especially if they're long or complicated (and definitely if they would need quoting). The preprocessor solution takes less code to process and has fewer failure modes (since the strings are embedded in the binary at compile time rather than read at runtime). But both are good solutions.
You can add a User-Defined-Setting in Xcode>Build-Settings, add its values according to all the schemes listed there. And then simply use that as a variable in Info plist file. That should work just fine.
This way you can avoid creating duplicate plist files, just for the sake of one or two different properties.

SpriteKit .plist problems xcode 6

I'm working on a game that requires the use of a plist. I set up the plist correctly, or at least I hope, as I've been using this method to set up plists all of the time. The problem though, is that in this case it is like the plist is not even recognized. Here are the contents of my plist:
The 'yo' key and value are debug values that I used to see if the plist was even being recognized. Here is my code:
-(NSString *)docsDir{
return [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
}
-(void)UpdatePlist{
listPath = [[self docsDir] stringByAppendingPathComponent:#"details.plist"];
self.savedData = [NSMutableDictionary dictionaryWithContentsOfFile:listPath];
unsigned long storedHighScore = [[self.savedData valueForKey:#"High Score"] unsignedLongValue];
NSLog(#"%#",[[self.savedData valueForKey:#"yo"] stringValue]);
NSLog(#"Here");
if (score>storedHighScore) {
[self.savedData setValue:[NSNumber numberWithUnsignedLong:score] forKey:#"High Score"];
NSLog(#"YO %lu",[[self.savedData valueForKey:#"High Score"] unsignedLongValue]);
}
[self.savedData writeToFile:listPath atomically:YES];
}
The problem stems from the code or my declaration of the plist I'm assuming. All of the NSLogs execute, as expected, but my log file is even more interesting:
Even the test string does not get returned and gets treated as null. At this point I'm assuming something is wrong with the plist, and yes, I can assure you that the name of the plist is indeed details.plist.
Where is this plist? When/how is it initially written to the documents directory?
The documents directory is the one into which files are copied from iTunes. So if you put this file into your app's Resources, it will not end up in documents.
When the plist doesn't exist, -dictionaryWithContentsOfFile: will return nil. Calling -objectForKey: or -stringValue on nil returns nil again. So if the file doesn't exist, self.savedData will be set to nil. Calling -writeToFile:atomically: on nil also is a No-op. So the code you posted will never create the plist if it is not already there.
Have you tried stepping through this code in the debugger? Click the gutter to the left of the -dictionaryWithContentsOfFile:-line and see what self.savedData is set to?

Transfer Highscores and Data

I'm writing a game write now which involves saving highscores and basic data such as "soundeffects on" and "music on" onto a plist file.
However, when in the future, I need to update my game and upload a new version of the app onto users' iphones/ipods, how will the highscores be retained? Is there a way to save specific plist files while overwriting others? Thanks in advance!
EDIT:
Is there any way to overwrite PART of a plist or merge an existing plist with a new one?
If you're putting these plists in the documents directory, there's nothing further you need to do. These files are all retained when your app is upgraded. You get the documents directory like this:
+ (NSString*) documentsPath
{
NSArray* sysPaths = NSSearchPathForDirectoriesInDomains( NSDocumentDirectory, NSUserDomainMask, YES );
return [sysPaths objectAtIndex:0];
}

Can a plist file be too big?

I'm working on a reference app that loads a plist file that can be searched.
The plist file is about 6kb with about 600 entries.
I have been working with the simulator and all works ok, however when I load it onto a device none of the data is there. Just an empty table.
I think the file may be too big because I can load a plist with 20 entries and it loads fine on the device.
If the file was too large wouldn't the whole app just crash?
Does anyone have any suggestions?
This is how I load my plist file
NSString* myFile = [[NSBundle mainBundle] pathForResource:#"myPlistFile" ofType:#"plist"];
array = [[NSMutableArray alloc] initWithContentsOfFile:myFile];
What it sounds like to me is that either your plist isn't even getting copied at all onto the device, or you're using case-sensitive file naming.
First see if the file exists at all:
NSString *myFilePath = [[NSBundle mainBundle] pathForResource:#"myPlistFile" ofType:#"plist"];
BOOL exists = [[NSFileManager defaultManager] fileExistsAtPath:myFilePath];
Check that boolean (using the debugger or by logging, either way). If the file exists, then I suspect that you're using a wrong case when trying to access the filename. Filenames are case-sensitive on iOS devices, unlike the Simulator. For example, lets say your plist was named myAwesomeStuff.plist. If you tried to access myawesomestuff.plist on the Simulator, it would work just fine. Not so on the device. Make sure you are using the correct case on your file names.

Resources