Package apple.uikit

Class UIDocument

    • Constructor Detail

      • UIDocument

        protected UIDocument​(org.moe.natj.general.Pointer peer)

    • Method Detail

      • accessInstanceVariablesDirectly

        public static boolean accessInstanceVariablesDirectly()

      • allocWithZone

        public static java.lang.Object allocWithZone​(org.moe.natj.general.ptr.VoidPtr zone)

      • automaticallyNotifiesObserversForKey

        public static boolean automaticallyNotifiesObserversForKey​(java.lang.String key)

      • cancelPreviousPerformRequestsWithTarget

        public static void cancelPreviousPerformRequestsWithTarget​(java.lang.Object aTarget)

      • cancelPreviousPerformRequestsWithTargetSelectorObject

        public static void cancelPreviousPerformRequestsWithTargetSelectorObject​(java.lang.Object aTarget,
                                                                         org.moe.natj.objc.SEL aSelector,
                                                                         java.lang.Object anArgument)

      • classFallbacksForKeyedArchiver

        public static NSArray<java.lang.String> classFallbacksForKeyedArchiver()

      • classForKeyedUnarchiver

        public static org.moe.natj.objc.Class classForKeyedUnarchiver()

      • debugDescription_static

        public static java.lang.String debugDescription_static()

      • description_static

        public static java.lang.String description_static()

      • hash_static

        public static long hash_static()

      • instanceMethodSignatureForSelector

        public static NSMethodSignature instanceMethodSignatureForSelector​(org.moe.natj.objc.SEL aSelector)

      • instancesRespondToSelector

        public static boolean instancesRespondToSelector​(org.moe.natj.objc.SEL aSelector)

      • isSubclassOfClass

        public static boolean isSubclassOfClass​(org.moe.natj.objc.Class aClass)

      • keyPathsForValuesAffectingValueForKey

        public static NSSet<java.lang.String> keyPathsForValuesAffectingValueForKey​(java.lang.String key)

      • new_objc

        public static java.lang.Object new_objc()

      • resolveClassMethod

        public static boolean resolveClassMethod​(org.moe.natj.objc.SEL sel)

      • resolveInstanceMethod

        public static boolean resolveInstanceMethod​(org.moe.natj.objc.SEL sel)

      • setVersion_static

        public static void setVersion_static​(long aVersion)

      • superclass_static

        public static org.moe.natj.objc.Class superclass_static()

      • version_static

        public static long version_static()

      • accommodatePresentedItemDeletionWithCompletionHandler

        public void accommodatePresentedItemDeletionWithCompletionHandler​(NSFilePresenter.Block_accommodatePresentedItemDeletionWithCompletionHandler completionHandler)
        Description copied from interface: NSFilePresenter
        Given that something in the system is waiting to delete the presented file or directory, do whatever it takes to ensure that the deleting will succeed and that the receiver's application will behave properly when the deleting has happened, and then invoke the completion handler. If successful (including when there is simply nothing to do) pass nil to the completion handler, or if not successful pass an NSError that encapsulates the reason why preparation failed. Implementations of this method must always invoke the completion handler because other parts of the system will wait until it is invoked or until the user loses patience and cancels the waiting. For example, NSDocument has an implementation of this method that closes the document. That way if the document is in the trash and the user empties the trash the document is simply closed before its file is deleted. This means that emptying the trash will not fail with an alert about the file being "in use" just because the document's file is memory mapped by the application. It also means that the document won't be left open with no document file underneath it. A shoebox application would only implement this method to be robust against surprising things like the user deleting its data directory while the application is running. The file coordination mechanism does not always send -relinquishPresentedItemToReader: or -relinquishPresentedItemToWriter: to your NSFilePresenter before sending this message. For example, other process' use of -[NSFileCoordinator prepareForReadingItemsAtURLs:options:writingItemsAtURLs:options:error:byAccessor:] can cause this to happen.
        Specified by:
        accommodatePresentedItemDeletionWithCompletionHandler in interface NSFilePresenter

      • accommodatePresentedSubitemDeletionAtURLCompletionHandler

        public void accommodatePresentedSubitemDeletionAtURLCompletionHandler​(NSURL url,
                                                                      NSFilePresenter.Block_accommodatePresentedSubitemDeletionAtURLCompletionHandler completionHandler)
        Description copied from interface: NSFilePresenter
        Given that something in the system is waiting to delete a file or directory contained by the directory, do whatever it takes to ensure that the deleting will succeed and that the receiver's application will behave properly when the deleting has happened, and then invoke the completion handler. If successful (including when there is simply nothing to do) pass nil to the completion handler, or if not successful pass an NSError that encapsulates the reason why preparation failed. Implementations of this method must always invoke the completion handler because other parts of the system will wait until it is invoked or until the user loses patience and cancels the waiting. The file coordination mechanism does not always send -relinquishPresentedItemToReader: or -relinquishPresentedItemToWriter: to your NSFilePresenter before sending this message. For example, other process' use of -[NSFileCoordinator prepareForReadingItemsAtURLs:options:writingItemsAtURLs:options:error:byAccessor:] can cause this to happen.
        Specified by:
        accommodatePresentedSubitemDeletionAtURLCompletionHandler in interface NSFilePresenter

      • autosaveWithCompletionHandler

        public void autosaveWithCompletionHandler​(UIDocument.Block_autosaveWithCompletionHandler completionHandler)
        Clients should not need to call this method directly. It exists as an override point for subclasses that want to do special things with autosaving. The default implementation of this method invokes [self hasUnsavedChanges] and, if that returns YES, invokes [self saveToURL:[self fileURL] forSaveOperation:UIDocumentSaveForOverwriting completionHandler:completionHandler].

      • changeCountTokenForSaveOperation

        public java.lang.Object changeCountTokenForSaveOperation​(long saveOperation)
        Change count tokens can be used to encapsulate the record of document changes being made in a particular save. Subclasses that don't register changes via -updateChangeCount: or by using the undoManager should implement these methods to determine if the model has new unsaved changes at the end of a save. -changeCountTokenForSaveOperation: is called at the beginning of a save operation and the token returned is passed to -updateChangeCountWithToken:forSaveOperation: at the conclusion of a save. The default implementation of updateChangeCountWithToken:forSaveOperation: calls [self updateChangeCount:UIDocumentChangeCleared] if no changes are made during the save.

      • closeWithCompletionHandler

        public void closeWithCompletionHandler​(UIDocument.Block_closeWithCompletionHandler completionHandler)
        Close the document. The default implementation calls [self autosaveWithCompletionHandler:completionHandler] which will save if [self hasUnsavedChanges] returns YES.

      • contentsForTypeError

        public java.lang.Object contentsForTypeError​(java.lang.String typeName,
                                             org.moe.natj.general.ptr.Ptr<NSError> outError)
        Typical subclasses will implement this method and return an NSFileWrapper or NSData encapsulating a snapshot of their data to be written to disk during saving. Subclasses that return something other than a valid NSFileWrapper or NSData instance, or don't override this method must override one of the writing methods in the Advanced Saving section to write data to disk.

      • disableEditing

        public void disableEditing()
        Subclasses should override these methods so that they do not allow the user to edit the document between calls to -disableEditing and -enableEditing. UIKit will call -disableEditing when it is unsafe to make changes to the document, such as during a close or revert, and call -enableEditing when it is safe again. The default implementation of these methods do nothing.

      • documentState

        public long documentState()

      • enableEditing

        public void enableEditing()

      • fileAttributesToWriteToURLForSaveOperationError

        public NSDictionary<?,​?> fileAttributesToWriteToURLForSaveOperationError​(NSURL url,
                                                                               long saveOperation,
                                                                               org.moe.natj.general.ptr.Ptr<NSError> outError)
        Called by -saveToURL: before executing asynchronous writing to get a dictionary of attributes understood by NSFileManager for writing to the file. The attributes are passed to -writeContents:andAttributes:safelyToURL:forSaveOperation:error: for writing to the file

      • fileModificationDate

        public NSDate fileModificationDate()
        The last known modification date of the document's on-disk representation. Updated by openWithCompletionHandler:, revertToContentsOfURL:, and saveToURL: and will return nil if none of these has completed successfully at least once.

      • fileNameExtensionForTypeSaveOperation

        public java.lang.String fileNameExtensionForTypeSaveOperation​(java.lang.String typeName,
                                                              long saveOperation)
        For a specified type, and a particular kind of save operation, return a file name extension that can be appended to a base file name.

      • fileType

        public java.lang.String fileType()
        The file's UTI. Derived from the fileURL by default.

      • fileURL

        public NSURL fileURL()
        UIKit may call these methods on background threads, so subclasses that override them must have thread safe implementations. These values will be set by UIKit before the completion handlers to the opening, reverting, and saving methods are called. Clients that wish to access these properties outside of an open, save, or revert completion handler and wait for any pending file operations should wrap the accesses in -performAsynchronousFileAccessUsingBlock:

      • finishedHandlingErrorRecovered

        public void finishedHandlingErrorRecovered​(NSError error,
                                           boolean recovered)
        Called when handling of an error (including any user interaction) is complete. Subclasses only need to call this method if they override -handleError:userInteractionPermitted: and do not call super. If overridden, subclasses must call super

      • handleErrorUserInteractionPermitted

        public void handleErrorUserInteractionPermitted​(NSError error,
                                                boolean userInteractionPermitted)
        Called by the default implementations of -openWithCompletionHandler: and -saveToURL:forSaveOperation:completionHandler:. Subclasses should call -handleError:userInteractionPermitted: with any errors that arise from direct calls to the advanced reading and writing methods that return NSErrors by indirection. Notes for overriding: 1. Subclasses that do not call super are responsible for calling -finishedHandlingError: when done with the error (i.e. when the app will not require any additional user feedback from the error). 2. Subclasses that do not call super are also responsible for implementing -userInteractionNoLongerPermittedForError: to wrap up error handling immediately when required. 3. If the userInteractionPermitted flag is NO, you should immediately handle the error and call [self finishedHandlingError:] within the context of -handleError:userInteractionPermitted:

      • hasUnsavedChanges

        public boolean hasUnsavedChanges()
        Subclasses should generally not need to override this. Instead they should use the undoManager or call -updateChangeCount: every time they get a change and UIKit will calculate -hasUnsavedChanges automatically. The default implementation of -autosaveWithCompletionHandler: initiates a save if [self hasUnsavedChanges] is YES.

      • initWithFileURL

        public UIDocument initWithFileURL​(NSURL url)
        The designated initializer. Passing an empty URL will cause this method to throw an NSInvalidArgumentException.

      • loadFromContentsOfTypeError

        public boolean loadFromContentsOfTypeError​(java.lang.Object contents,
                                           java.lang.String typeName,
                                           org.moe.natj.general.ptr.Ptr<NSError> outError)
        Typical subclasses will implement this method to do reading. UIKit will pass NSData typed contents for flat files and NSFileWrapper typed contents for file packages. typeName is the UTI of the loaded file.

      • localizedName

        public java.lang.String localizedName()
        The default implementation derives the name from the URL. Subclasses may override to provide a custom name for presentation to the user, such as in error strings.

      • openWithCompletionHandler

        public void openWithCompletionHandler​(UIDocument.Block_openWithCompletionHandler completionHandler)
        Subclassing this method without calling super should be avoided. Subclassers who don't call super must use NSFileCoordinator for coordinated reading themselves. Open the document located by the fileURL. This will call readFromURL:error: on a background queue and then invoke the completionHandler on the current dispatch queue when openWithCompletionHandler: is invoked.

      • performAsynchronousFileAccessUsingBlock

        public void performAsynchronousFileAccessUsingBlock​(UIDocument.Block_performAsynchronousFileAccessUsingBlock block)
        The default implementations of saveToURL: and openWithCompletionHandler: both use this to serialize file access. Direct calls to reading and writing methods should use this method to serialize file access on a background queue.

      • presentedItemDidChange

        public void presentedItemDidChange()
        Description copied from interface: NSFilePresenter
        Be notified that the file or file package's contents or attributes have been been written to. Because this method may be be invoked when the attributes have changed but the contents have not, implementations that read the contents must use modification date checking to avoid needless rereading. They should check that the modification date has changed since the receiver most recently read from or wrote to the item. To avoid race conditions, getting the modification date should typically be done within invocations of one of the -[NSFileCoordinator coordinate...] methods. For example, NSDocument implements this method to react to both contents changes (like the user overwriting the document file with another application) and attribute changes (like the user toggling the "Hide extension" checkbox in a Finder info panel). It uses modification date checking as described above. Not all programs use file coordination. Your NSFileProvider may be sent this message without being sent -relinquishPresentedItemToWriter: first. Make your application do the best it can in that case.
        Specified by:
        presentedItemDidChange in interface NSFilePresenter

      • presentedItemDidGainVersion

        public void presentedItemDidGainVersion​(NSFileVersion version)
        Description copied from interface: NSFilePresenter
        Be notified that something in the system has added, removed, or resolved a version of the file or file package. For example, NSDocument has implementations of these methods that help decide whether to present a versions browser when it has reacquired after relinquishing to a writer, and to react to versions being added and removed while it is presenting the versions browser.
        Specified by:
        presentedItemDidGainVersion in interface NSFilePresenter

      • presentedItemDidMoveToURL

        public void presentedItemDidMoveToURL​(NSURL newURL)
        Description copied from interface: NSFilePresenter
        Be notified that the file or directory has been moved or renamed, or a directory containing it has been moved or renamed. A typical implementation of this method will cause subsequent invocations of -presentedItemURL to return the new URL. The new URL may have a different file name extension than the current value of the presentedItemURL property. For example, NSDocument implements this method to handle document file moving and renaming. A shoebox application would only implement this method to be robust against surprising things like the user moving its data directory while the application is running. Not all programs use file coordination. Your NSFileProvider may be sent this message without being sent -relinquishPresentedItemToWriter: first. Make your application do the best it can in that case.
        Specified by:
        presentedItemDidMoveToURL in interface NSFilePresenter

      • presentedItemOperationQueue

        public NSOperationQueue presentedItemOperationQueue()
        Description copied from interface: NSFilePresenter
        The operation queue in which all of the other NSFilePresenter messages except -presentedItemURL will be sent to the receiver. Implementations of this method must be prepared to be invoked by Cocoa in any queue, at any time, including from within invocations of NSFileCoordinator methods. A nil value is not valid. For example, NSDocument has a -presentedItemOperationQueue method that returns a private queue. In very simple cases you can return [NSOperationQueue mainQueue], but doing so is often an invitation to deadlocks.
        Specified by:
        presentedItemOperationQueue in interface NSFilePresenter

      • presentedItemURL

        public NSURL presentedItemURL()
        Description copied from interface: NSFilePresenter
        The NSURL that locates the file or directory that the receiver is presenting to the user. Implementations of this method must be prepared to be invoked by Cocoa in any queue, at any time, including from within invocations of NSFileCoordinator methods. A nil value is valid and means that the presented item does not exist yet. An NSFilePresenter with a nil presentedItemURL will be asked for its presentedItemURL again when coordinated file access on behalf of that NSFilePresenter completes, in case the presented item was just created. For example, NSDocument has a -presentedItemURL method that usually returns [self fileURL]. In a shoebox application that stores the user's data in files somewhere on the user's computer you can implement this method to specify the directory that contains those files.
        Specified by:
        presentedItemURL in interface NSFilePresenter

      • presentedSubitemAtURLDidMoveToURL

        public void presentedSubitemAtURLDidMoveToURL​(NSURL oldURL,
                                              NSURL newURL)
        Description copied from interface: NSFilePresenter
        Be notified that a file or directory contained by the directory has been moved or renamed. If this method is not implemented but -presentedItemDidChange is, and the directory is actually a file package, then the file coordination machinery will invoke -presentedItemDidChange instead. Not all programs use file coordination. Your NSFileProvider may be sent this message without being sent -relinquishPresentedItemToWriter: first. Make your application do the best it can in that case.
        Specified by:
        presentedSubitemAtURLDidMoveToURL in interface NSFilePresenter

      • presentedSubitemDidAppearAtURL

        public void presentedSubitemDidAppearAtURL​(NSURL url)
        Description copied from interface: NSFilePresenter
        Be notified that a file or directory contained by the directory has been added. If this method is not implemented but -presentedItemDidChange is, and the directory is actually a file package, then the file coordination machinery will invoke -presentedItemDidChange instead. Not all programs use file coordination. Your NSFileProvider may be sent this message without being sent -relinquishPresentedItemToWriter: first. Make your application do the best it can in that case.
        Specified by:
        presentedSubitemDidAppearAtURL in interface NSFilePresenter

      • presentedSubitemDidChangeAtURL

        public void presentedSubitemDidChangeAtURL​(NSURL url)
        Description copied from interface: NSFilePresenter
        Be notified that the contents or attributes of a file or directory contained by the directory have been been written to. Depending on the situation the advice given for -presentedItemDidChange may apply here too. If this method is not implemented but -presentedItemDidChange is, and the directory is actually a file package, then the file coordination machinery will invoke -presentedItemDidChange instead. Not all programs use file coordination. Your NSFileProvider may be sent this message without being sent -relinquishPresentedItemToWriter: first. Make your application do the best it can in that case.
        Specified by:
        presentedSubitemDidChangeAtURL in interface NSFilePresenter

      • readFromURLError

        public boolean readFromURLError​(NSURL url,
                                org.moe.natj.general.ptr.Ptr<NSError> outError)
        Direct calls to this method should not be necessary for typical subclasses where the entire file is read during opening. If direct calls are used, the client must use NSFileCoordinator API to ensure coordinated reads and performAsynchronousFileAccessUsingBlock: to serialize with any active writes. Default implementation calls [self loadFromContents:ofType:error:] on the queue that called openWithCompletionHandler:, or the main queue if called directly, with NSData or NSFileWrapper contents.

      • revertToContentsOfURLCompletionHandler

        public void revertToContentsOfURLCompletionHandler​(NSURL url,
                                                   UIDocument.Block_revertToContentsOfURLCompletionHandler completionHandler)
        Discard all unsaved document modifications and replace the document's contents by reading a file or file package located by a URL. Default implementation calls [self disableEditing] in the beginning and [self enableEditing] on completion to indicate that the document should not accept changes from the user while this is happening. The default implementation also calls [self openWithCompletionHandler:] after updating the fileURL. Subclasses that override this method must call super or use NSFileCoordinator directly to initiate a coordinated read.

      • savePresentedItemChangesWithCompletionHandler

        public void savePresentedItemChangesWithCompletionHandler​(NSFilePresenter.Block_savePresentedItemChangesWithCompletionHandler completionHandler)
        Description copied from interface: NSFilePresenter
        Given that something in the system is waiting to read from the presented file or directory, do whatever it takes to ensure that the contents of the presented file or directory is completely up to date, and then invoke the completion handler. If successful (including when there is simply nothing to do) pass nil to the completion handler, or if not successful pass an NSError that encapsulates the reason why saving failed. Implementations of this method must always invoke the completion handler because other parts of the system will wait until it is invoked or the user loses patience and cancels the waiting. If this method is not implemented then the NSFilePresenter is assumed to be one that never lets the user make changes that need to be saved. For example, NSDocument has an implementation of this method that autosaves the document if it has been changed since the last time it was saved or autosaved. That way when another process tries to read the document file it always reads the same version of the document that the user is looking at in your application. (WYSIWGCBF - What You See Is What Gets Copied By Finder.) A shoebox application would also implement this method. The file coordination mechanism does not always send -relinquishPresentedItemToReader: or -relinquishPresentedItemToWriter: to your NSFilePresenter before sending this message. For example, other process' use of -[NSFileCoordinator prepareForReadingItemsAtURLs:options:writingItemsAtURLs:options:error:byAccessor:] can cause this to happen.
        Specified by:
        savePresentedItemChangesWithCompletionHandler in interface NSFilePresenter

      • saveToURLForSaveOperationCompletionHandler

        public void saveToURLForSaveOperationCompletionHandler​(NSURL url,
                                                       long saveOperation,
                                                       UIDocument.Block_saveToURLForSaveOperationCompletionHandler completionHandler)
        Subclassing this method without calling super should be avoided. Subclassers who don't call super must use NSFileCoordinator for coordinated writing themselves. The default implementation of this method invokes [self contentsOfType:error:] synchronously on the calling queue, and then invokes [self writeContents:andAttributes:safelyToURL:ForSaveOperation:completionHandler:] on a background queue. The completion handler is executed on the calling queue.

      • savingFileType

        public java.lang.String savingFileType()
        The default implementation returns the current file type. saveToURL: will save to an extension based on this type so subclasses can override this to allow moving the document to a new type.

      • setFileModificationDate

        public void setFileModificationDate​(NSDate value)
        The last known modification date of the document's on-disk representation. Updated by openWithCompletionHandler:, revertToContentsOfURL:, and saveToURL: and will return nil if none of these has completed successfully at least once.

      • setUndoManager

        public void setUndoManager​(NSUndoManager value)
        The document's undo manager. Setting the undo manager also registers the document as an observer of various NSUndoManager notifications so that -updateChangeCount: is invoked as undoable changes are made to the document. Asking for the undo manager creates a default one if one is not already set. Typically, when a subclass sets the undoManager, it does not need to override -hasUnsavedChanges or call updateChangeCount: manually.

      • setUserActivity

        public void setUserActivity​(NSUserActivity value)

      • undoManager

        public NSUndoManager undoManager()
        The document's undo manager. Setting the undo manager also registers the document as an observer of various NSUndoManager notifications so that -updateChangeCount: is invoked as undoable changes are made to the document. Asking for the undo manager creates a default one if one is not already set. Typically, when a subclass sets the undoManager, it does not need to override -hasUnsavedChanges or call updateChangeCount: manually.

      • updateChangeCount

        public void updateChangeCount​(long change)
        Record the fact that a change affecting the value returned by -hasUnsavedChanges has occurred. Subclasses should not need to call this if they set the undoManager.

      • updateChangeCountWithTokenForSaveOperation

        public void updateChangeCountWithTokenForSaveOperation​(java.lang.Object changeCountToken,
                                                       long saveOperation)

      • updateUserActivityState

        public void updateUserActivityState​(NSUserActivity userActivity)

      • userInteractionNoLongerPermittedForError

        public void userInteractionNoLongerPermittedForError​(NSError error)
        UIKit calls this method when it is no longer safe to proceed without immediately handling the error, such as when the app is being suspended. Subclasses must immediately wrap up error handling (including dismissing any interactive UI) and call [self finishedHandlingError:] before returning. It is only necessary to override this method if you override -handleError:userInteractionPermitted: without calling super

      • writeContentsAndAttributesSafelyToURLForSaveOperationError

        public boolean writeContentsAndAttributesSafelyToURLForSaveOperationError​(java.lang.Object contents,
                                                                          NSDictionary<?,​?> additionalFileAttributes,
                                                                          NSURL url,
                                                                          long saveOperation,
                                                                          org.moe.natj.general.ptr.Ptr<NSError> outError)
        This method is responsible for doing document writing in a way that minimizes the danger of leaving the disk to which writing is being done in an inconsistent state in the event of an application crash, system crash, hardware failure, power outage, etc. Because it does several different things, and because the things are likely to change in future releases of iOS, it's probably not a good idea to override this method without invoking super.

      • writeContentsToURLForSaveOperationOriginalContentsURLError

        public boolean writeContentsToURLForSaveOperationOriginalContentsURLError​(java.lang.Object contents,
                                                                          NSURL url,
                                                                          long saveOperation,
                                                                          NSURL originalContentsURL,
                                                                          org.moe.natj.general.ptr.Ptr<NSError> outError)
        Called by -writeContents:andAttributes:safelyToURL:forSaveOperation:error: to write the data to disk. Override point for subclasses that need access to the on-disk representation of the document while saving.

      • observedPresentedItemUbiquityAttributes

        public NSSet<java.lang.String> observedPresentedItemUbiquityAttributes()
        Description copied from interface: NSFilePresenter
        The set of ubiquity attributes, which the receiver wishes to be notified about when they change for presentedItemURL. Valid attributes include only NSURLIsUbiquitousItemKey and any other attributes whose names start with "NSURLUbiquitousItem" or "NSURLUbiquitousSharedItem". The default set, in case this property is not implemented, includes of all such attributes. This property will normally be checked only at the time addFilePresenter: is called. However, if presentedItemURL is nil at that time, it will instead be checked only at the end of a coordinated write where presentedItemURL became non-nil. The value of this property should not change depending on whether presentedItemURL is currently ubiquitous or is located a ubiquity container. For example, NSDocument implements this property to always return NSURLIsUbiquitousItemKey, NSURLUbiquitousItemIsSharedKey, and various other properties starting with "NSURLUbiquitousSharedItem". It needsto be notified about changes to these properties in order to implement support for ubiquitous and shared documents.
        Specified by:
        observedPresentedItemUbiquityAttributes in interface NSFilePresenter

      • presentedItemDidChangeUbiquityAttributes

        public void presentedItemDidChangeUbiquityAttributes​(NSSet<java.lang.String> attributes)
        Description copied from interface: NSFilePresenter
        Be notified that the presented file or file package's ubiquity attributes have changed. The possible attributes that can appear in the given set include only those specified by the receiver's value for observedPresentedItemUbiquityAttributes, or those in the default set if that property is not implemented. Note that changes to these attributes do not normally align with -presentedItemDidChange notifications.
        Specified by:
        presentedItemDidChangeUbiquityAttributes in interface NSFilePresenter

      • relinquishPresentedItemToReader

        public void relinquishPresentedItemToReader​(NSFilePresenter.Block_relinquishPresentedItemToReader reader)
        Description copied from interface: NSFilePresenter
        Given that something in the system is waiting to read from the presented file or directory, do whatever it takes to ensure that the application will behave properly while that reading is happening, and then invoke the completion handler. The definition of "properly" depends on what kind of ownership model the application implements. Implementations of this method must always invoke the passed-in reader block because other parts of the system will wait until it is invoked or until the user loses patience and cancels the waiting. When an implementation of this method invokes the passed-in block it can pass that block yet another block, which will be invoked in the receiver's operation queue when reading is complete. A common sequence that your NSFilePresenter must handle is the file coordination mechanism sending this message, then sending -savePresentedItemChangesWithCompletionHandler:, and then, after you have invoked that completion handler, invoking your reacquirer.
        Specified by:
        relinquishPresentedItemToReader in interface NSFilePresenter

      • relinquishPresentedItemToWriter

        public void relinquishPresentedItemToWriter​(NSFilePresenter.Block_relinquishPresentedItemToWriter writer)
        Description copied from interface: NSFilePresenter
        Given that something in the system is waiting to write to the presented file or directory, do whatever it takes to ensure that the application will behave properly while that writing is happening, and then invoke the completion handler. The definition of "properly" depends on what kind of ownership model the application implements. Implementations of this method must always invoke the passed-in writer block because other parts of the system will wait until it is invoked or until the user loses patience and cancels the waiting. When an implementation of this method invokes the passed-in block it can pass that block yet another block, which will be invoked in the receiver's operation queue when writing is complete. A common sequence that your NSFilePresenter must handle is the file coordination mechanism sending this message, then sending -accommodatePresentedItemDeletionWithCompletionHandler: or -savePresentedItemChangesWithCompletionHandler:, and then, after you have invoked that completion handler, invoking your reacquirer. It is also common for your NSFilePresenter to be sent a combination of the -presented... messages listed below in between relinquishing and reacquiring.
        Specified by:
        relinquishPresentedItemToWriter in interface NSFilePresenter