CoreData: Ubiquity: Invalid option: the value for NSPersistentStoreUbiquitousContentNameKey should not contain periods: com.YashwantChauhan.Outis
-PFUbiquitySwitchboardEntryMetadata setUseLocalStorage:: CoreData: Ubiquity: mobile~20BF44C9-C39F-48DC-A8A1-B45FC82C7E20:com.YashwantChauhan.Outis
I have a problem with syncing with iCloud. These two errors above are thrown at me. I don't know what's the problem, I setup the Entitlements file, and set the Ubiquity Container to com.YashwantChauhan.Outis.
I start the CoreData stack using MagicalRecord's method:
[MagicalRecord setupCoreDataStackWithiCloudContainer:#"N6TU2CB323.com.YashwantChauhan.Outis" localStoreNamed:#"Model.sqlite"];
But that shouldn't even matter since MagicalRecord just simplifies CoreData methods.
Help much appreciated.
Ok update:
-[NSFileManager URLForUbiquityContainerIdentifier:]: An error occurred while getting ubiquity container URL: Error
Domain=LibrarianErrorDomain Code=11 "The operation couldn’t be
completed. (LibrarianErrorDomain error 11 - The requested container
identifier is not permitted by the client's
com.apple.developer.ubiquity-container-identifiers entitlement.)"
UserInfo=0x15e0d8a0 {NSDescription=The requested container identifier
is not permitted by the client's
com.apple.developer.ubiquity-container-identifiers entitlement.}
This is the latest error message I got, I realize this differs from the question's initial error but it so turns out that the old message was some kind of strange bug of sorts. I tried #Rauru Ferro's solution by removing the periods from my Ubiquity Container identifier. I knew that this wouldn't work because the requirements for the identifier is to contain periods, but then when I put the periods back in, it spat the error message above. Which makes more a lot more sense than not using periods. We all know that we do.
I also found this handy code snippet that can actually checks my Ubiquity Container identifier by fetching it. Useful snippet to quickly check if you have any problems with it.
NSString *containerId = #"com.YashwantChauhan.Outis";
NSFileManager *fileManager = [NSFileManager defaultManager];
NSURL *iCloudURL = [fileManager URLForUbiquityContainerIdentifier:containerId];
NSLog(#"%#", [iCloudURL absoluteString]);
Another update: By the looks of it, this stupid NSPersistentStoreUbiquitousContentNameKey should not contain periods is a whole mess. If NSPersistentStoreUbiquitousContentNameKey is created like some kind of folder (Tutorial), then the requirement is that there is no . infront of the name, like .com.YashwantChauhan.Outis but that is not the case. I am starting to go mad here! There is no problem with the Entitlements file and there is nothing with fetching the iCloud container ID in MagicalRecord. I am starting to think this is an internal problem with setting up iCloud in Xcode 5, but of course I don't know. With this said, I might just be loosing my mind over something trivial or something that will actually cause a headache for other people.
Can anybody post their Entitlements file so I can verify how an actual working version looks like. Redacted of course. Thank you!
refer
https://forums.pragprog.com/forums/252/topics/12315
Quoting the response:
This was changed recently (Mavericks). Fortunately for you, since you are just now adding iCloud, the impact is minimal.
You need to change the following line of code:
[options setValue:[[NSBundle mainBundle] bundleIdentifier] forKey:NSPersistentStoreUbiquitousContentNameKey];
To something else. What is that something else? I would recommend something descriptive to your application. I have been using class name like structures recently. So I would change it to be the name of your app perhaps or simply “DataStorage”.
The name is unique to your application so the actual value is not important as long as it is understood by you.
So I changed my code below...
options = [NSDictionary dictionaryWithObjectsAndKeys:
[NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption, // Key to automatically attempt to migrate versioned stores
[NSNumber numberWithBool:YES], NSInferMappingModelAutomaticallyOption, // Key to attempt to create the mapping model automatically
#"TrafficCamNZ_DataStore", NSPersistentStoreUbiquitousContentNameKey, // Option to specify that a persistent store has a given name in ubiquity.
cloudURL, NSPersistentStoreUbiquitousContentURLKey, // Option to specify the log path to use for ubiquitous content logs.
nil];
Refer the line that says TrafficCamNZ_DataStore
it previously had TrafficCamNZ.DataStore
David
I am using a shared container and just had the same error warning popping up. I could fix it by replacing all occurrences of varying cloud identifier strings like:
"$(TeamIdentifierPrefix)com.mydomain.myapp" and
"com.mydomain.myapp" and
"ABCDEF0123.com.mydomain.myapp"
with just this one explicit cloud container string:
"ABCDEF0123.com.mydomain.myapp"
I guess that at some point, Xcode must have updated the entitlements and re-inserted the "$(TeamIdentifierPrefix)", which was wrong due to the shared container. Also, I had forgotten the identifer in code, just like you seemed to have:
NSString *containerId = #"com.YashwantChauhan.Outis";
that should probably be something like:
NSString *containerId = #"ABCDEF01234.com.YashwantChauhan.Outis";
I had the same issue and I am not sure what the issue is or why it is there.
From what I am reading we should be able to use the dots in the containerId.
However, for me it started working by replacing the dots in the containerId with tildes:
i.e.:
NSString *containerId = #"N6TU2CB323~com~YashwantChauhan~Outis";
instead of:
NSString *containerId = #"N6TU2CB323.com.YashwantChauhan.Outis";
Try to use comYashwantChauhanOutis, without the two points.
Related
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.
I'm building an IOS app and using parse.com as a backend. All of a sudden, today I am getting this error - Error: File name must be a string without any other explanation. I'm certain the file name that I am using is a string. I haven't changed any of the Native IOS code so it must be a new Parse issue. The only difference - today I updated my account to the new pricing model on Parse, wondering if that's related?
// Code snippet
NSString *fileName = #"test.mov"; // Also tried just #"test"
PFFile *file = [PFFile fileWithName:fileName data:fileData]; // NSData - 286553 bytes
[file saveInBackgroundWithBlock:^(BOOL succeeded, NSError *error) {
// Break point right here - this is where the error occurs.
NEWS:
ALL should go to: https://developers.facebook.com/bugs/622479264497355/?comment_id=1426426400945705
And post your account email to Hector Ramos.
Update2:
This has been fixed and is preparing for a deploy.
The problem is: Basically, if you are currently using LESS than 1GB of data storage (for example, I'm using 679MB), instead of correctly calculating that I'm using (679 / (1024MB * 20)) = 3.3% of the quota, its calculating it as 679/20, which gets the result of 3395%. Parse, if you see this, PLEASE... its really just a few lines of code.. please resolve this ASAP!
This was an internal error and has been resolved. Parse posted an incident report here.
EDIT: As several people have pointed out, the error is still present even though Parse claims it has been resolved. Hrmmmmmm...
I was developing an app, at some stage this error came out:
-[__NSArrayM popObjectForKey:]: unrecognized selector sent to instance
I've undone the latest edits to see what was wrong...but the error was still there.
So I've undone even more edits, but the error was still there.
Tried to delete and add back the framework where I thought the error could come from, error still there. (it's KinveyKit framework)
Tried to substitute the line of code where the app would throw the error with another one that was surely working: even that one was throwing the error.
I downloaded an older Git of the app (that was definitely working a few days ago) on a different folder, run that and: same error.
Uninstalled and reinstalled Xcode: error still there.
But: if I run other apps with similar code, nothing goes wrong.
Does anybody have any idea?
I post here the code, that throws me the error, just to give you an idea...but I don't think there's anything wrong in the code since it's always been working before.
.h
#property (strong, nonatomic) KCSAppdataStore *store;
.m
- (void)viewDidLoad
{
...
_store = [KCSAppdataStore storeWithOptions:#{ KCSStoreKeyCollectionName : #"AnEntity",
KCSStoreKeyCollectionTemplateClass : [AnEntity class]}];
[_store queryWithQuery:[KCSQuery query]
withCompletionBlock:^(NSArray *objectsOrNil1, NSError *errorOrNil) { ... }];
...
}
Cool -- being sarcastic
I spent the afternoon rebuilding the app from a new project, copy pasting the code...
Now I opened the older one once again, tried to run it just...just to try once again, knowing it would crash cause I haven't change a word it already crashed every other time I tried earlier this morning, and.... surprise: runs again. No errors.
-.-'' Solution to my question then? No idea. Still thinking it was some cache problem that eventually got solved through out the day but not while I was trying to solve it.
If anybody has had similar experiences or has some further idea, feel free to add something, always good to be prepared for next time something like this happens.
I had a similar issue that appeared to be caused by a corrupted KCSUser object written to the keychain. The popObjectForKey method appears to get called any time you call [KCSUser activeUser]. I was able to get this fixed by adding the code below first thing in application DidFinishLaunchingWithOptions:. Be sure you aren't calling [KCSUser activeUser] at any point before the following code has a chance to run.
NSArray *secItemClasses = #[(__bridge id)kSecClassGenericPassword,
(__bridge id)kSecClassInternetPassword,
(__bridge id)kSecClassCertificate,
(__bridge id)kSecClassKey,
(__bridge id)kSecClassIdentity];
for (id secItemClass in secItemClasses) {
NSDictionary *spec = #{(__bridge id)kSecClass: secItemClass};
SecItemDelete((__bridge CFDictionaryRef)spec);
}
This appears to clear/reset the keychain. After you run it once, remove it and you app should operate normally.
Does anyone know what happens if you try to save to core data, but there is not enough disk space left?
I'm assuming the save operation generates an NSError of some kind? How would you tell it was a disk space error not some other error during disk write?
After a few hours of trying to fill up the disk, I've found that the error you get is:
NSSQLiteErrorDomain = 13;
NSUnderlyingException = "error during SQL execution : database or disk is full";
It is rather difficult to get this error:
iOS devices claim to be full before they really are. I managed to squeeze an extra 206MB onto an iPod that claimed to have 0 bytes free.
As the device fills up, it automatically starts deleting caches and other temporary files.
This seems to be a poor choice by the CoreData developers when implementing their Error handling API. instead of defining a NSCoreDataErrorDomain they're overloading NSCocoaErrorDomain and passing up SQLite error codes defined here.
You can find out the error by querying the NSError instance and parsing the result for the error domain involved. One of these domains probably has the error code you are looking for:
// Predefined domain for errors from most AppKit and Foundation APIs.
FOUNDATION_EXPORT NSString *const NSCocoaErrorDomain;
// Other predefined domains; value of "code" will correspond to preexisting values in these domains.
FOUNDATION_EXPORT NSString *const NSPOSIXErrorDomain;
FOUNDATION_EXPORT NSString *const NSOSStatusErrorDomain;
FOUNDATION_EXPORT NSString *const NSMachErrorDomain;
I'm trying to load a file into a string. Here is the code I'm using:
NSError *error = nil;
NSString *fullPath = [[NSBundle mainBundle] pathForResource:filename
ofType:#"html"];
NSString *text = [NSString stringWithContentsOfFile:fullPath
encoding:NSUTF8StringEncoding
error:&error];
When passed in #"about" as the filename, it works absolutely fine, showing the code works.
When passed in #"eula" as the filename, it fails with 'Cocoa error 258', which translates to NSFileReadInvalidFileNameError. However, if I swap the contents of the files over but keep the names the same, the other file fails proving there is nothing wrong with the filename, it's something to do with the content.
The about file is fairly simple HTML but the eula file is a massive mess exported from Word by the legal department.
Does anyone know of anything inside a HTML file that could cause this error to be raised?
Much thanks,
Sam
I've just spent 45 minutes with this problem, only in my case the solution was stupid and the problem slightly different.
I had a file called Playlist.txt in my resources directory. It was loading just fine.
The file was modified at one point, from within XCode.
The file stopped loading properly, with the same error as above. However, it had never been moved nor had its encoding type been changed.
I did a command-I (Get Info) on the file in the XCode directory, it told me it was UTF-8 (as expected).
I tried the "usedEncoding" way of reading files, no dice. Same error, encoding was return null.
Finally, I erased the file from XCode, dragged it in again, and did a Clean All. That fixed the problem.
This is not the first time that XCode magically caching things (incorrectly) has caused me hours and hours of wasted time. If you have an error like this which doesn't make sense, try removing and replacing files and cleaning all targets.
The error is almost certainly that your file is not in UTF-8, but you're right, that does sound like a bug in the error report.
Open the eula file up with BBEdit (or the free TextWrangler) and see what encoding it uses. Change the encoding to UTF-8 and save it. Diff the two files to see what differences have appeared. Replace the original file with the new one (fixing any glitches).
If that resolves the problem, then use the Apple Bug Reporter to report the bug in the error report.
I had the same error with you ,use file name with
[[NSBundle mainBundle] pathForResource:#"pageList" ofType:#"txt"]] good luck!
The most likely reason that +stringWithContentsOfFile:encoding:error: would fail in this case would be if you provided the wrong encoding. Are you sure that your #"eula" file is UTF8 encoded?
If you're unsure about the encoding of the file, you could always try +stringWithContentsOfFile:usedEncoding:error: instead and see if it works and what encoding it comes up with.
Don't know if this is your problem, but I just had a similar thing (stringWithContentsOfFile, no JSON), and the problem was that the file had CRLF (windows) line-endings and Western-whatever-it's-called encoding. I used SubEthaEdit to convert to LF and UTF-8, and everything works fine.
I ran into the same error.
When I played around a bit, it appeared that I was not including the file in copy bundle resources of the target.
I did that and it worked fine.
But, have to say -- error is quite misleading for such a simple cause. Just a bad guess from Xcode