Question

Problem statement:

I want to upload a large binary (such as an audio clip) from an iOS app to S3, and I’d like to make the app’s handling of disconnects (or low connectivity) as robust as possible, preferably by uploading the binary as a series of chunks.

Unfortunately, neither the AWSiOS SDK, nor ASI’s S3 framework seem to support to multi-part uploads, or indicate that they plan to add support. I realize that I can initiate a ‘longish’ upload using beginBackgroundTaskWithExpirationHandler: and that’ll give me a window of time to complete the upload (currently 600 seconds, I believe), but what’s to be done if I’m not in a situation to complete said upload within that timeframe?

Aside from worrying about completing tasks within that time frame, is their a ‘best practice’ for how an app should resume uploads, or even just break a larger upload into smaller chunks?

I’ve thought about writing a library to talk to S3’s REST API specifically for multi-part uploads, but this seems like a problem other have either been solved, or realized needn’t be solved (perhaps for being completely in appropriate for the platform).

Another (overly complicated) solution would be chunking the file on the device, uploading those to S3 (or elsewhere) and have them re-assembled on S3 via a server process. This seems even more unpalatable than rolling my own library for multi-part upload.

How are others handling this problem?

Answer 1

Apparently I was looking at some badly out of date documentation.

in AmazonS3Client see:

- (S3MultipartUpload * AmazonS3Client)initiateMultipartUploadWithKey:(NSString *)theKey withBucket:(NSString *)theBucket    

Which will give you a S3MultipartUpload which will contain an uploadId.

You can then put together an S3UploadPartRequest using initWithMultipartUpload: (S3MultipartUpload *) multipartUpload and send that as you usually would.

S3UploadPartRequest contains an int property partNumber where you can specify the part # you’re uploading.