SyncServer

The singleton for this class.

Enable reporting of only events desired by the client app.

The delegate enables operations such as file downloads & conflict resolution.

Put a call to this in your AppDelegate or other place early in the launch sequence of your app.

For dealing with background uploading/downloading. Call this from the same named delegate method in your AppDelegate.

Enqueue a local immutable file for subsequent upload.

Immutable files are assumed to not change (at least until after the upload has completed). This immutable characteristic is not enforced by this class but needs to be enforced by the caller of this class.

This operation survives app launches, as long as the call itself completes.

If there are contents with the same uuid, which have been enqueued for upload (file upload or appMetaData upload) but not yet sync‘ed, they will be replaced by this upload request. That is, if you want to do both a file upload and an appMetaData upload in the same sync, then set the SyncAttributes with the appMetaData, and use one of the file upload operations.

This operation does not access the server, and thus runs quickly and synchronously.

You can only set the fileGroupUUID (in the SyncAttributes) when the file is first uploaded.

When uploading a file for the 2nd or more time (multi-version upload):

1. the 2nd and following updates must have the same mimeType as the first version of the file.
2. If the attr.appMetaData is given as nil, and an earlier version had non-nil appMetaData, then the nil appMetaData is ignored– i.e., the existing app meta data is not set to nil.

The sharingGroupUUID (in the SyncAttributes) for a series of files up until a sync() operation must be the same. If you want to change to dealing with a different sharing group, you must call sync().

A single file (a single fileUUID) can only be stored in a single sharingGroupUUID. It is an error to attempt to upload the same fileUUID to a different sharingGroupUUID.

Warning: If you indicate that the mime type is text/plain, and you are using Google Drive and the text contains unusual characters, you may run into problems– e.g., downloading the files may fail.

A copy of the file is made, and that is used for uploading. The caller can then change their original and it doesn’t affect the upload. The copy is removed after the upload completes. This operation proceeds like uploadImmutable otherwise.

Enqueue an upload of changed app meta data for an existing file.

Like the other uploads above:

1. This operation survives app launches, as long as the call itself completes,
2. This operation does not access the server, and thus runs quickly and synchronously, and
3. If there is a file with the same uuid, which has been enqueued for upload (file contents or appMetaData) but not yet sync‘ed, it will be replaced by this upload request.

This method enqueues an upload deletion operation. The operation persists across app launches. It is an error to try again later to upload, or delete the file referenced by this UUID. You can only delete files that are already known to the SyncServer (e.g., that you’ve uploaded).

If there is a file with the same uuid, which has been enqueued for upload but not yet sync‘ed, it will be removed.

This operation does not access the server, and thus runs quickly and synchronously.

This operation undoes its work if it throws an error.

As above, but you can give multiple UUIDs.

Enqueue sharing group creation operation. The current queue of upload operations must be empty (e.g., you must have done a sync operation).

Enqueue request to update the given sharing group. If there is a sharing group update operation queued already (and unsynced), it will be removed and this will replace that. I.e., multiple sharing group updates result in the last update being applied.

Enqueue request to remove the current user from the given sharing group. Since this is removing the user from the sharing group: (a) The current queue of upload operations must be empty (e.g., you must have done a sync operation), and (b) you must do a sync() operation immediately after this call. I.e., it’s an error to queue further operations for the same sharing group.

Are there operation uploads pending? Pending uploads are those that were enqueued and committed with a sync. This includes file uploads, groups, and deletions.

The sharing groups that the user is currently a member of, and known to the server. syncNeeded in sharing groups will be non-nil.

Operates in one of two modes:

1) If you give a non-nil sharingGroupUUID, if no other sync is taking place, this will asynchronously do pending downloads, file uploads, and upload deletions for the given sharing group. If there is a sync currently taking place (for any sharing group), this closes the collection of uploads/deletions queued (if any) for the sharingGroupUUID, and will wait until after the current sync is done, and try again. Also synchronizes the sharingGroups property with the server.

In this case you can also give reAttemptGoneDownloads = true, which will reattempt downloads for files previously marked as gone. See SyncAttributes.

You can also give pushNotificationMessage in this case, which will be sent to all other users in the sharing group as a push notification.

2) If you give a nil-sharingGroupUUID, only synchronizes the sharingGroups property. Doesn’t do pending downloads or uploads etc. And doesn’t close a collection of queued operations (reAttemptGoneDownloads ignored in this case).

If a stopSync is currently pending, then this call will be ignored.

If there is no network connection, the sync will be attempted next time the app is in the foreground and there is a network connection.

Non-blocking in all cases.

Is there a sync operation in progress?

Stop an ongoing sync operation. This will stop the operation at the next natural stopping point. E.g., after a next download completes. No effect if no ongoing sync operation. Any delayed sync(s) are cancelled.

Operates synchronously and quickly. A file must have already been uploaded (or downloaded) for you to be able to get its attributes. It is an error to call this for a file UUID that doesn’t yet exist, or for one that has already been deleted.

Use this to request the re-download of a file, on a subsequent sync with the relevant sharing group UUID. E.g., for when a file could not be read due to some kind of corruption. Requests to download a file that is already gone are ignored. Use the reAttemptGoneDownloads flag of the sync method instead. Note that this is a request for download because normal sync operations can take priority. E.g., it is possible that the file might be deleted by a server download deletion before this request gets a chance to operate.

The type of reset to perform with a call to reset.

Does a reset of local (not server) tracking data.

Doesn’t sign the user out or require that the user is signed in.

This method may only be called when the client is not doing any sync operations.

Logs information about all tracking internal meta data.

Return result from localConsistencyCheck.

Performs a similar operation to a file system consistency or integrity check. Only operates if not currently synchronizing. Suitable for running at app startup.

This is intended for development/debug only. This enables you do a consistency check between your local files and SyncServer meta data. Does a sync first to ensure files are synchronized.