I've got an OS X app syncing a single document through a ubiquity container back and forth to an iOS equivalent app. The iOS app receives data whenever it changes on the Mac side and sends it whenever it changes on the iOS side (so the iOS app is working all around), and the Mac app sends the data whenever it is changed on the Mac side and it receives the data when the app is launched, but it doesn't seem to be checking again for any data while it runs. I'd like it to update with any changes automatically and immediately, like the OS X "Notes" app does from changes on the iOS side.
At launch, this is the relevant function that gets called:
+(NSMutableDictionary *)getAllNotes {
if(allNotes == nil) {
allNotes = [[NSMutableDictionary alloc]initWithDictionary:[[NSUserDefaults standardUserDefaults] dictionaryForKey:kAllNotes]];
cloudDoc = [[CloudDocument alloc]initWithContentsOfURL:[self notesURL] ofType:NSPlainTextDocumentType error:nil];
[cloudDoc saveToURL:[self notesURL] ofType:NSPlainTextDocumentType forSaveOperation:NSSaveOperation error:nil];
}
return allNotes;
}
and that "CloudDocument" class (which is a subclass of NSDocument) includes:
#import "Data.h"
#implementation CloudDocument
-(NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError {
return [NSKeyedArchiver archivedDataWithRootObject:[Data getAllNotes]];
}
-(BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName error:(NSError **)outError {
NSDictionary *dict = (NSDictionary *)[NSKeyedUnarchiver unarchiveObjectWithData:(NSData *)data];
[Data didReceiveCloudData:dict];
return YES;
}
+(BOOL)autosavesInPlace {
return YES;
}
#end
which kicks it back to:
+(void)didReceiveCloudData:(NSDictionary *)d {
allNotes = [[NSMutableDictionary alloc]initWithDictionary:d];
[[NSUserDefaults standardUserDefaults] setObject:allNotes forKey:kAllNotes];
[cloudDoc updateChangeCount:NSChangeDone];
}
I think the problem is just that I don't have any part of my code that is equivalent to the phrase "check periodically to see if the ubiquity container has changed, and then do..." etc. I'm sure there's a well-known process for this (some notification event in NSDocument or something), but I've searched around and everything I find is either for iOS/UIDocuments instead of OS X/NSDocuments, or it's all theory and over my head without any tangible code samples to comb through and pick apart.
Can anyone help me out with a method for registering that an iCloud document in the ubiquity container has changed, and ideally where to put it (AppDelegate, CloudDocument.m, etc)? I only have one file syncing around, signified by the constant kAllNotes, so I don't need to track a bunch of different files or anything. I'm pretty sure I can use the code that runs at launch to do what needs to be done, I just can't figure out what to do to start the auto-syncing process.
Thank you in advance!
PS I'm still a beginner, so tutorials and code samples are much appreciated.
You're looking for NSMetadataQuery - it does a spotlight-like, continuously running search for any type of file - and is available on both iOS and OS X (indeed on iOS it can only be used for observing changes to the ubiquity container). I don't have any one link on how to use this - the Apple docs are too general to make much sense initially but do a search on 'NSMetadataQuery iCloud' and you should be sorted - there is tons of information out there on this topic.
With NSMetadataQuery you receive a notification every time something in the observed folder system changes, and it's not just applicable to UIDocument files even if a lot of examples are worried about UIDocuments.
Indeed, NSMetadataQuery it is - it feels like a hack but appears to be the only way to monitor changes to standard (non-UIDocument) files.
Here's a sample project I've compiled. It lets you upload an image from the camera roll, then monitors changes to the ubiquitous Documents folder:
https://github.com/versluis/iCloud-Images
Related
I am currently experimenting on raywenderlich's project of How To Make a Multiplayer iPhone Game Hosted on Your Own Server Part 1
at the end of the part 1 tutorial, it claims that after looking for auto-match via the game center panel, the log panel would show 2 PlayerIDs
CatRace[5407:707] didFindPlayers
CatRace[5407:707] G:1036727375
CatRace[5407:707] G:1417937643
However, when I tried to run on the iPhone Simulator and my iPhone, it always returns only 1 playerID after finished matching players.
So, I would like to know exactly how the function would return the information.
Could anyone help on this ?
Additional:
I found that the simulator and the iDevice found the player of another, but not including itself. Is it the normal case?
Already tried to put the server on to an external host. Still No luck, returning only one player in the array.
Is this function
- (void)matchmakerViewController:(GKMatchmakerViewController *)viewController didFindPlayers:(NSArray *)playerIDs
supposed to return all the players including the local player ?
Although it is so wired, I manage to manipulate the return into a new NSMUTABLEARRAY and send to the hosting server.
- (void)matchmakerViewController:(GKMatchmakerViewController *)viewController didFindPlayers:(NSArray *)playerIDs {
NSMutableArray *players = [[NSMutableArray alloc] initWithArray:playerIDs];
[players insertObject:[GKLocalPlayer localPlayer].playerID atIndex:0];
if (_state == NetworkStatePendingMatch) {
[self dismissMatchmaker];
[self sendStartMatch:players];
}
[players release];
However, I am still looking for the answer of my original question, which is the supposed return of - (void)matchmakerViewController:(GKMatchmakerViewController *)viewController didFindPlayers:(NSArray *)playerIDs
OK, so Apple brought ARC to us, which is great. After refactoring my Application to ARC almost everything works fine and it is a lot easier now to develop and maintain.
There is just one problem I still can't figure out.
My job management program shows different detail information of proposals, orders and so on in their own windows. So I have a special class where WindowControllers gets allocated and initiated with initWithWindowNibName and then the window is shown with showWindow:
DetailWindowController *proposalWindowController = [[DetailWindowController alloc] initWithWindowNibName:#"ThePorposalWindow"];
[proposalWindowController showWindow:nil];
Before ARC the Instance of the WindowController did the release like shown in the documentation:
- (void)windowWillClose:(NSNotification *)notification
{
[self autorelease];
}
But now with ARC this is not possible anymore and what makes it even worse, in my special class where the WindowController is allocated and initiated, the same windowController is released by ARC because there is no pointer to the windowController.
My idea was to copy the windowController into an mutuable array:
[proposalWindowArray addObject:proposalWindowController];
[[proposalWindowArray lastObject] showWindow:nil];
And in the windowControllers delegate method windowWillClose I post a notification to my special class:
- (void)windowWillClose:(NSNotification *)notification
{
[[NSNotificationCenter defaultCenter] postNotificationName:#"ProposalWindowWillClose" object:[[self window] windowController] userInfo:nil];
}
In my special class I listen to the notification and remove the object from the array:
- (void) proposalWindowWasClosed: (NSNotification *) notification
{
[proposalWindowArray removeObjectIdenticalTo:[notification object]];
}
It works, but I still do not believe that this is the correct way.
Does anybody has the same problem or a tip to make it better?
I'd probably use a delegate approach rather than notifications. Generally it is better to have an external object that keeps track of the open windows. Self-retaining objects, like your old system, break the basic points of object ownership and make it hard to find things (such as "give me a list of open windows"). Non-Singletons that are just "floating" out there often come back to bite you in your architecture (I've had to fix this often enough).
That said, sometimes self-ownership is at least convenient, and at worst not-the-end-of-the-world. So self-own. The only difference is that you need to do it explicitly rather than matching a leak and an over-release (which is what your old code was doing).
Create a private strong property. Assign self to it. That will create a retain loop that will keep you around until you set the property to nil.
I think your alternative approach should be correct, but I don't think you need the second notification. You should be able to do:
- (void)windowWillClose:(NSNotification *)notification
{
[proposalWindowArray removeObjectIdenticalTo:self];
}
Assuming the "proposalWindowArray" is a static NSMutableArray.
Without hacks, there is no elegant way to keep an object retained other than having a strong reference to it in some other object. For example, you could keep a static NSMutableArray/NSMutableSet, add your controller there, and remove it in windowsWillClose:. This will be shorter than posting a notification. To make this reusable, create a WindowControllerRegistry singleton with an array, where you add controllers like this one, and which will automatically listen to NSWindowWillCloseNotification and remove them from its array thus releasing ownership.
As a quick workaround, you could perform retain/autorelease calls from non-ARC file:
my_retain(self);
my_autorelease(self);
// ArcDisabled.mm
void my_retain(id obj) { [obj retain]; }
void my_autorelease(id obj) { [obj autorelease]; }
I had this same issue when I switched to ARC. Your solution works, but you're making it too complicated. You can essentially do what you were doing before by having the window release itself when it closes, but in an ARC compatible manner.
The solution is to simply create a property of your class within the class itself. For your example, in DetailWindowController, you would add the following property:
#property (strong) DetailWindowController *theWindowController;
Then when you create the window with your code above, add one line like so:
DetailWindowController *proposalWindowController = [[DetailWindowController alloc] initWithWindowNibName:#"ThePorposalWindow"];
[preferenceController setTheWindowController:proposalWindowController];
[proposalWindowController showWindow:nil];
Then finally, to have ARC release the window when it is closed like you did with the autorelease pre-ARC, in the DetailWindowController class, simply do:
- (void)windowWillClose:(NSNotification *)notification
{
// Let ARC tear this down and clean it up
[self setTheWindowController:nil];
}
eventStore=[[EKEventStore alloc] init];
EKEvent *addEvent=[EKEvent eventWithEventStore:eventStore];
addEvent.title=#"hello";
addEvent.startDate=messageDate;
addEvent.endDate=[addEvent.startDate dateByAddingTimeInterval:600];
[addEvent setCalendar:[eventStore defaultCalendarForNewEvents]];
addEvent.alarms=[NSArray arrayWithObject:[EKAlarm alarmWithAbsoluteDate:addEvent.startDate]];
[eventStore saveEvent:addEvent span:EKSpanThisEvent error:nil];
The code above works fine in ios 4.2 but not in ios 5. I have the code in applicationDidfinishingLaunching method. Due to error, black screen appears and app exits. Only recurrenceRules has changed in ios 5 and I have not made use of it. All other properties are available in superclass EKCalendarItem. I cannot test it since I have xcode 3.2 and snow leopard. I am looking to debug the line at which error occurs causing the app to quit. I doubt it is related to setCalendar or using alarms property.
The code is correct and works in iOS 5. The reason for my error was the first line
eventStore=[[EKEventStore alloc] init];
Since initializing eventstore takes some time, placing it in application launch method resulted in time out. I found it from my crash report stating:
"Elapsed application CPU time (seconds):30 seconds"
The app is supposed to launch within 10 seconds. if not time out occurs with Exception Codes: 0x8badf00d
You have to use 5th version of SDK. You can find a diff in saveEvent function:
[eventStore saveEvent:addEvent span:EKSpanThisEvent commit:YES error:nil];
It should help you.
There was a change (I believe) to the API in iOS5 that requires you to add EKAlarm objects using the addAlarm instance method.
To add an alarm to your event in iOS5:
[addEvent addAlarm:[EKAlarm alarmWithAbsoluteDate:addEvent.startDate]]
Check EKCalendarItem Class Reference for details.
Although #property(nonatomic, copy) NSArray *alarms is not specified as read only it would appear to be behaving that way.
See https://stackoverflow.com/a/7880242/816455 for more information on other iOS5 EKAlarm issues.
NaveenaRK I wasn't having any time out errors however i fixed this by doing the following.
You need to keep the eventStore in memory for the objects life time.
eventStore = [[EKEventStore alloc] init]
I initialised the event store on creating the object and released it in dealloc. The problem with setting the alarms and the "CADObjectGetInlineStringProperty" error were both fixed.
In most systems, the default behaviour for "open a new window" is that it appears at the front. This doesn't happen in Cocoa, and I'm trying to find the "correct" way to make this standard behaviour. Most things I've tried only work for a maximum of one window.
I need to open multiple windows on startup:
(N x NSDocuments (one window each)
1 x simple NSWindowController that opens a NIB file.
Things that DON'T work:
Iterate across all the NSDocuments I want to open, and open them.
What happens? ... only the "last" one that call open on comes to the front - the rest are hidden, invisible, nowhere on the screen, until you fast-switch or use the Window menu to find them.
Code:
...documents is an array of NSPersistentDocument's, loaded from CoreData...
[NSDocumentController sharedDocumentController];
[controller openDocumentWithContentsOfURL:[documents objectAtIndex:0] display:YES error:&error];
Manually invoking "makeKeyAndOrderFront" on each window, after it's opened
What happens? nothing different. But the only way I can find to get the NSWindow instance is so horribly hacky it seems totally wrong (but is mentioend in several blogs and mailing list posts)
Code:
[NSDocumentController sharedDocumentController];
NSDocument* openedDocument = [controller openDocumentWithContentsOfURL:[documents objectAtIndex:0] display:YES error:&error];
[[[[openedDocument windowControllers] objectAtIndex:0] window] makeKeyAndOrderFront:nil];
...I know I'm doing this wrong, but I can't find out why/what to do differently :(.
Something that works, usually, but not always:
As above, but just use "showWindow" instead (I took this from the NSDocument guide).
Bizarrely, this sometimes works ... even though it's the exact code that Apple claims they're calling internally. If they're calling it internally, why does it behave different if I re-invoke it after they've already done so?
[[[openedDocument windowControllers] objectAtIndex:0] showWindow:self];
You can just open all the documents without displaying and then tell the documents to show their windows:
NSArray* docs = [NSArray arrayWithObjects:#"doc1.rtf", #"doc2.rtf",#"doc3.rtf",#"doc4.rtf",nil];
for(NSString* doc in docs)
{
NSURL* url = [NSURL fileURLWithPath:[[NSHomeDirectory() stringByAppendingPathComponent:#"Documents"] stringByAppendingPathComponent:doc]];
NSError* err;
[[NSDocumentController sharedDocumentController] openDocumentWithContentsOfURL:url display:NO error:&err];
}
[[[NSDocumentController sharedDocumentController] documents] makeObjectsPerformSelector:#selector(showWindows)];
Won't this work?
For 10.6 or greater
[[NSRunningApplication currentApplication] activateWithOptions:(NSApplicationActivateAllWindows | NSApplicationActivateIgnoringOtherApps)];
This often has something to do with the app itself: your other windows are behind other apps (in particular, behind Xcode!), and would have appeared with a Hide Others command.
The solution to that problem would be that after you send showWindow to all of your windows (making sure you do the key one last), you tell the app to come forward, relative to other apps.
NSApp.activateIgnoringOtherApps(true) // Swift
or
[NSApp activateIgnoringOtherApps:YES]; // Objective-C
See also: How to bring NSWindow to front and to the current Space?
I am having a trouble try to display a NSWindow with out using Interface Builder. The initialization of the window was quite confusing since I am more familiar with iPhone (which does not have an NSWindow equivalent). So I searched Google for some code and I eventually found this:
NSRect windowRect = NSMakeRect(10.0f, 10.0f, 800.0f, 600.0f);
NSWindow *window = [[NSWindow alloc] initWithContentRect:windowRect
styleMask:( NSResizableWindowMask | NSClosableWindowMask | NSTitledWindowMask)
backing:NSBackingStoreBuffered defer:NO];
[window makeKeyAndOrderFront:nil];
So I copied that code and placed it in the applicationDidFinishLaunching and thought all would be good. But all is not good. Xcode did not display any errors (or warnings) in the Build Results. But, I do get this message in the display log:
2010-06-26 13:33:47.170 FooApp[283:a0f] Could not connect the action buttonPressed: to target of class NSApplication
I don't know how to interpret this as Google has failed me on searching for a solution on this display log error. And, as far as I can tell, I have no actions at the moment including a buttonPressed one. As a side note: I do not know if this is relevant or not, but I deleted the Main Window.xib and its accompanying property in the info.plist.
Any help would be greatly appreciated.
UPDATE: I tried doing some printf debugging (never really bothered learning NSLog) and the thing won't even printf if the thing is at the very beginning of the appliactionDidFinishLaunching or even worst, at the start of main (before the return if incase some of you are tempted to ask me if I put the printf before or after the return statement).
MainWindow.xib is part of the iphone App template, isn't it? What exactly did you delete? You still have the MainMenu.xib, right?
As you have discovered, having a nib file is not optional for a Cocoa app. You must have at least one nib (or xib, for you youngsters) and it must have a main menu in it.