Current File Upload Functionality is not flexible enough to implement Wifi-only Instant Upload

[Jon-Schneider]

Because this is such a huge change to the app, I think this is something that should be discussed as a group rather than me just going and implementing it. You all have most of the knowledge about how the upload system currently works while I have only a few hours of research and maybe ten hours working on the Instant Upload feature. In addition, redoing core uploading is a task so big it would take me a considerable amount of time by myself and I'm not going to have a lot of free time to do Open Source work for the next few months.

For Wifi Instant Upload I need an upload system with the following attributes:

• Initiating an upload returns an upload task object reference that I can use to cancel uploads (necessary for canceling wifi uploads in progress when devices go off wifi)
• A way to access upload tasks from the app's last session when the app reopens (necessary to cancel in-progress upload tasks that should be wifi-only if the app is reopened while not on Wifi). Possible options off the top of my head are just looping through upload tasks and: 1) checking filename/path combination from a task with a record of upload tasks held by InstantUpload, or 2) letting the class that initiates an upload attach a unique string identifier to each download task (preferable)
• Upload tasks need to offer a delegate (or registered block) callback the class initiating an upload can respond to when an upload succeeds or fails (so the Instant Upload manager can update the last upload date).

Also, ideally uploads will retain the current serial (one upload at a time) behavior and upload files in the order they are sent to the uploader class, and should persist the order between sessions of the app.

Unfortunately the currently upload system doesn't appear up to it. Admittedly it's very complicated. If you think the current upload system is up for it (and even if it is rewriting it to simplify it may still be ideal) I'd be happy to talk about how we can get it to work in the way I need it to.

My very preliminary, basic thoughts on a simple interface:

UploadQueueManager: NSObject

• sharedUploadManager (singleton method)
• (NSArray<UploadTask *> *)queuedUploads (persists between app sessions)
• (Upload *)uploadFile:(File *)file toPath:(NSString *)path
• cancelUpload:(UploadTask *)upload

Upload: NSObject @property NSString * localFilePath @property NSString * destinationFilePath @property NSString * uploadIdentifier @property uploadStatus @property id<UploadTaskDelegate> * delegate

@protocol UploadTaskDelegate

• uploadDidStart
• uploadDidFinish:(BOOL)success error:(NSError *)error

Notes:

• Upload could share a lot of the attributes of UploadsOfflineDto but also need to directly or indirectly wrap an NSURLSessionUploadTask or some other upload mechanism, but also have information like the path to the file being uploaded, the server upload path, etc. This could possibly just mostly wrap current upload infrastructure, providing a facade.

[jesmrec]

Thanks for sharing your thoughts @Jon-Schneider. As you know, currently we are working in the new release. After that, we will schedule how to handle this issue by breaking it in tasks as far as it is possible.

[nasli]

Moved to next release. In 3.5.1 priority iOS10

[guruz]

Linking issues together: https://github.com/owncloud/ios/issues/352

[Jon-Schneider]

So where do things stand on this?

[jesmrec]

@Jon-Schneider right now we are focused on improving the app performance and new features like authentication method based in token. We have scheduled the current feature for 3.5.3 version.