Bundle download progress on Android

[janicduplessis]

Motivation

Android equivalent of #15066

Test Plan

Tested that download progress shows up properly when reloading the app.

Release Notes

[ANDROID] [FEATURE] [DevSupport] - Show bundle download progress on Android

[janicduplessis]

Sadly this wont work currently since progress is disabled on android (33057aa#diff-948206404ada96979d687d628e935ee1), but we've reverted this commit in the Expo fork so it would be great to merge it anyway :)

[ide]

true -> isCloseDelimiter?

[janicduplessis]

We do emit progress for each chunk so even if it is not the last chunk (what isCloseDelimiter means) we still want to pass isFinal to true. Its only use is to make sure the last event isn't throttled so we see 100%.

[ide]

If I understand this correctly, we'd reach 100% only on the last chunk -> don't we want to force the progress event only in that scenario then? Otherwise I'd say isFinal should be named something else if it gets set to true many times and not just for the final progress event.

[janicduplessis]

No it is not the case, progress is reset for each chunk so let's say we have three chunks progress would look like: 0, 1, 0, 1, 0, 1. In the case of RN packager we only care about the progress of the last chunk (the JS bundle so we ignore progress of the other ones (https://github.com/facebook/react-native/pull/17809/files/bbe67864421b1de228d7af3ddd7327ed8bca060c#diff-948206404ada96979d687d628e935ee1R204).

[janicduplessis]

Just to clarify a chunk is a "part" from the multipart response. You can pretty much see it as multiple http responses nested inside the normal http response. It has it's own headers and we track progress of downloading each chunk separately. The goal is to allow the server to push multiple responses to the client (packager progress events + final chunk is the js bundle).

[ide]

I think I get it. I thought that the progress was for the entire multipart response (e.g. like a multipart upload) rather than for just the chunk.

What do you think about refactoring the ChunkCallback interface so that it's clear the progress events are just for that one chunk? (Breaking change to the API)

  public interface ChunkListener {
    /**
     * Invoked when a chunk of a multipart response is fully downloaded.
     */
    void onChunkComplete(Map<String, String> headers,
                         Buffer body,
                         boolean isLastChunk) throws IOException;

    /**
     * Invoked as bytes of the current chunk are read and may be invoked multiple times per chunk.
     * This method is guaranteed to be invoked one last time when the chunk is fully downloaded,
     * with `isChunkComplete` set.
     */
     void onChunkProgress(Map<String, String> headers,
                          long chunkBytesRead,
                          long chunkTotalBytes,
                          boolean isChunkComplete) throws IOException;
  }

[janicduplessis]

Makes sense, I agree it will be clearer like that, not sure if we have to mark this as breaking since I don't think it is meant to be public api.

[ide]

clear these only when we return (or don't clear at all) so we don't always need to reparse?

[janicduplessis]

Each chunk of the multipart response has it's own headers so this is why we clear it every time we emit a chunk so we parse the next one.

[ide]

Instead of currentHeadersLength (assuming we want to calculate the size of the response body downloaded so far), don't we want to track the starting index of the response body?

[janicduplessis]

Yea there might be an error here, we don't take into consideration the length of the headers delimiter, it can cause the progress number to be off by a bit. I could keep currentHeadersLength and do content.size() - currentHeadersLength - headersDelimiter.size() or change currentHeadersLength for something like contentStart.

[ide]

@facebook-github-bot shipit

[facebook-github-bot]

Something went wrong executing that command, @hramos could you take a look?

[facebook-github-bot]

@ide is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.