While this isn’t specifically related to Xojo, it affects the previous RS as well, I’m looking to open a discussion with the most knowledgeable users and I think this is where I will find them.
In summary: I’ve been using Security Scoped Bookmarks to hold references for recent items and for open files, while these work they’ve lead to many issues. In comparison, had I built an app using the “Document based app” template in Xcode and Obj-C, I wouldn’t be facing the problems that I am. Apple’s NSDocument based app, automagically retains access for open documents and recent documents. Meaning the developer doesn’t even have to go through the hassle of doing anything special, it just works.
I’ve spoken to Apple engineers, I’ve built a doc based app in Obj-C and been researching every little fricking detail I can in order to understand the hidden magic that Apple uses for it’s NSDocument based apps. I’ve narrowed it down to one key object, and several processes.
NSDocumentController is the key object here from what I can understand.
NSDocumentController contains functions for storing and retrieving a recent items list and any file added to that list, has it’s access automagically retained.
NSDocumentController is also the key object when used with Lion’s WindowRestoration classes and it’s this functionality that holds on to the access of open documents.
For recent items, I was able to implement and it works beautifully. For Lion’s WindowRestoration - I keep hitting brick wall after brick wall. Documentation on how to accomplish this correctly is scarce and it seems some functionality cannot be accomplished with declares.
I believe that this issue is very important to Xojo as means that a Xojo app cannot operate as well as a Obj-C app in a Sandboxed environment.
From what I’ve been able to find it seems, that the first part is getting the OS to correctly encode certain properties of the window. Mainly it needs to encode the representedURL. It’s not difficult to specify the representedURL, but it doesn’t get encoded. So far I’ve found at least 3 things that I believe need to be set on a Window to trigger the encoding correctly.
#1 setRestorable must be True - which is a simple declare.
#2 You must set a restorable class - which is another simple declare.
#3 You must give the window a unique ID before any views are created in the window. The issue is ‘identifier’ is a variable of the window, with no getter or setter, so I’ve not been able to do this via a declare. It looks like I will have to jump in a create a plugin.
I haven’t gotten much further than that, I’ve tried creating a NSDocument and associating the two (which works, but doesn’t help). I’ve tried allocating a NSWindowController, (which works but doesn’t help).
All this is just to get the OS to encode the URL.
Even if the URL is correctly encoded, I’m not sure that a Xojo app will automagically have access to the URL, until it has been decoded correctly.
Decoding the restorable state, is a whole 'nother bag of snakes. It seems the way to do within Xojo is to add an event to the NSApplication
- (BOOL)restoreWindowWithIdentifier:(NSString *)identifier state:(NSCoder *)state completionHandler:(void (^)(NSWindow *, NSError *))completionHandler NS_AVAILABLE_MAC(10_7);
Again it can’t be done via a declare.
And even then, I’m not sure that this will help much as then your app must take over decode the data. So I’m hoping that simply by being able to correctly encode the window information (capturing the URL) this will solve the problem for Xojo users. If not then…