AJAX Upload XHR2 and FileReader, Part 3

So, this week’s stand up meeting is finally concluded. You weren’t really paying attention – blah blah something uploader, the details are in the task, blah blah HTML5. You sit down at your station, pull up the task and – hmm, support for modern browsers, including mobile… need to show previews of certain types of files before uploading… show progress… pause and resume? You seem to remember seeing something like that on one of your favourite developer blogs…

You may have been thinking about the HTML5-based uploader and file reader I shared way back when. However, as reader RLK points out, there wasn’t really a way to pause or resume uploads previously. The logic was there… if you were willing to unwrap DeferXHR from the plugin. Oops. Let’s fix that, and add some functionality while we’re at it.

You’ll notice the pauseList parameter for both functions – this is to allow us to specify only specific file upload or read processors as needing to pause. Remember that the file reading or uploading will occur asynchronously, and if you’ve allowed the user to select or drag and drop multiple files, there can be multiple file reads/uploads occuring at once. The pauseList parameter, therefore, allows, for example, an interface you’ve built on top of this plugin to give the user the ability to pause one upload out of a list of uploads.

You can see we’re being fairly permissive about what pauseList looks like. It can be a boolean false, which will indicate we want to pause/resume all file processors (a boolean true is an invalid value). It can be an array, in which case it should be an array of strings or numbers (more on that in a moment). Or it can be a single string or number. Other values are invalid and will cause errors and/or untested strangeness.

If a number or string is specified (separately, or as part of the array), it should either be the 0-indexed number of the occurrence of the file you want to pause/resume processing on in the files array that gets returned from the FILE_LIST_LOADED event:

Or it should be the full name of the file as a string, e.g. picture_of_my_cat.jpg. Also worth noting is that most of the events that have to do with a specific file will also include the file_name as part of the event data, for use in disambiguating which file the event has taken place on.

On the DeferXHR that processes our files for upload in chunks, we have the following:

You’ll notice that we check the state of the Deferred object first – no point in attempting to pause an upload that’s already resolved or rejected. We also check that the upload is chunked – the way ‘pausing’ an upload works is to stop uploading after the current chunk is finished. If we’re not uploading in chunks (because the chunked option has been set to false, or because the file is smaller than the specified chunk_size), then calling pause on the upload has no effect.

So, now it looks like we have all the pieces for pausing and resume uploading in place – what about file reading?

Chunked File Reading

We just finished discussing how ‘pausing’ an upload works by finishing up the current chunk, and then waiting on resume to start uploading the next. Therefore, if we want to be able to pause a file read, we need to read it in chunks as well.

This involves a number of changes to the structure of DeferReader, but one obvious starting point is that, if we’re chunking the file read, we follow the same general structure as we do for file uploads – use the slice method on the File to get a specified range of bytes within the file, and read that using the specified read method.

You may be wondering what the advantage is to this. After all, the file is just going to get read into memory, whether we read it all at once or in chunks, right? Is it just to have a standard api across both file processors?

On the contrary, it offers us some interesting advantages.

For one, we can potentially avoid locking the browser while loading a large file – if we have to perform the file loading on the UI thread, we can pause between chunks to perform other updates as necessary.

For another, memory isn’t the only place we could load a large file – we could instead plan to re-assemble it into IndexedDB. This would also potentially be a good place to download files to, if we needed to interact with them in the browser before serving them up to the user (say, decrypting them)… more on that in a future article.

For now, if you do decide to chunk your file read, you’ll need to re-assemble it as its read in to get the complete file. Notice the changes in DeferReader.prototype.readComplete:

As detailed above, whenever a chunk has finished reading in, we’ll check to see if its the last chunk. If not, we’ll trigger a FILE_READ_PROGRESS event, much like the kind that was triggered previously while a file read was ongoing. The difference here is that this version of the event will also include a read_result property, with the result of reading the file chunk. A simple test for the presence of this property can be done when listening for the event, and the read_result can be stored in a new Blob in memory or elsewhere (such as IndexedDB).

If it’s the final chunk, then we trigger a FILE_READ_FINISHED as usual, and return the final chunk in the read_result in that event. In the listener for this event, we can finish assembling the chunked file, and do what we want with it at this point.

Use

I mentioned at the beginning we’d discuss how to actually call pause or resume on your element and the associated file processor(s). This is very simple. First, you’d attach a HUp instance to an element by calling it like so:

$('#hupInput').hup({options});

Then, you can get back the HUp instance by referencing that same element and looking for ‘hup’ in the data attached to the Node. You can also save a reference to this instance – it will never change within the lifetime of the Node, so it’s safe to save.

var aHupInstance = $('#hupInput').data('hup');

Then, you could call aHupInstance.pause() or aHupInstance.resume(). You could also skip saving a reference and address it directly:

Art+Logic has been designing and developing innovative custom software since 1991. We have built software for over 900 clients from a diverse set of industries including education, aerospace, music technology, consumer electronics, entertainment, financial services, and more. Coding the “impossible.”®