Add onSendProgress callback

[tlueder]

This fixes the upload part of #465

I had also tried to include the download progress, but that did not work as expected.
And it is why easier to do this while consuming the response stream.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[tlueder]

@googlebot I signed it!

[NazarenoCavazzon]

Hope this gets merged, it would really help

[tomassasovsky]

@tlueder @jasonroland @piotrsed any updates on this?

[tlueder]

Hi, I can rebase this. But without a clear path forward I don't see the point.

Currently I just use this plugin from my repro via dependency override, works great.

[yinxulai]

Why to needs close this ioRequest

[tlueder]

It's been a while since I've last had a look at this.

But I need the response from the ioRequest for the code that follows and I guess that was the easiest way I could think of.

But if that is not a good idea or best practice I'm all in for improvements.

[kevmoo]

@brianquinlan @devoncarew @natebosch

[kevmoo]

Please fix merge conflicts!

[tlueder]

@kevmoo done

[natebosch]

This looks like a breaking change, and we have been avoiding breaking API changes. This is only breaking for a subset of users, but I don't know what proportion.

We are currently getting through a major version bump without too much difficulty, but that was a version bump without breaking API changes. cc @brianquinlan for thoughts on the practicality of a breaking API change and another version bump.

[tlueder]

This is a API change for sure but I would argue against a breaking one. This adds a new optional feature. And should not break anything for anyone not using it.

Can you elaborate what you mean by "This is only breaking for a subset of users"?
Maybe I can change the code to make sure it won't affect them.

[natebosch]

This is breaking for classes with overrides of the changed methods.

[tlueder]

Of course, I haven't even thought about that.
Thanks for the information.

[brianquinlan]

We are currently getting through a major version bump without too much difficulty, but that was a version bump without breaking API changes. cc @brianquinlan for thoughts on the practicality of a breaking API change and another version bump.

1. As you said, this is definitely a breaking change (in particular it will definitely break at least package:cronet_http and package:cupertino_http).
2. I wonder if there is a way to implement this without breaking the API? For example, we could define a new class like:

interface class ProgressTracker {
  void onSendProgress(int loaded, int total);
}

class ProgressTrackingRequest extends StreamedRequest implements ProgressTracker {
   ...
}

And send implementations could check if the Request implements that class and, if so, could update the progress e.g.

if (request is ProgressTracker) {
  request.onSendProcess(...);
}

That's a bit ugly.

3. I'm not sure why tracking upload progress is more important than tracking download progress. If we are going to make a breaking change then we should do both so we don't have to update the major version just to add the obvious complementary feature.
4. I'd be fine with another version bump but maybe we should wait a few months and accumulate all the breaking changes into one release? Is there an easy way to do this? Like have a 2.0 branch or something?

[tlueder]

1. Understood, and thanks for your input I was not aware of that.
2. I'd rather wait for a version bump instead of a "quick fix". But in the end, I don't really care so much about the how this is implemented, because I don't know enough about dart best practice and what side effects this can have. I just need the progress data and if this is done a different way? I'm happy to update my apps if that means I can get rid of the dependency override and rebasing my fork.
3. It is not that tracking the download is not important, but in contrast to the upload it can be done easily on the consuming side as all the needed data is already available. Just not as callback function. And when I wrote this, 2 years ago, I was not able to do this and my attempts felt just wrong. So I left it at that, but any hints in the right direction are welcome.

[github-actions]

PR Health

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?
http	Breaking	1.2.3-wip	1.2.3-wip	1.2.3-wip	✔️

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

Coverage ⚠️

File	Coverage
pkgs/http/lib/http.dart	💚 100 %
pkgs/http/lib/retry.dart	💚 92 %
pkgs/http/lib/src/base_client.dart	💚 97 %
pkgs/http/lib/src/base_request.dart	💚 88 %
pkgs/http/lib/src/browser_client.dart	💔 Not covered
pkgs/http/lib/src/client.dart	💚 100 %
pkgs/http/lib/src/io_client.dart	💚 76 %
pkgs/http/lib/src/mock_client.dart	💚 100 %
pkgs/http/lib/src/progress.dart	💔 Not covered

This check for test coverage is informational (issues shown here will not fail the PR).

This check can be disabled by tagging the PR with skip-coverage-check.

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbols

License Headers ✔️

// Copyright (c) 2024, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

Unrelated files missing license headers

Files
pkgs/cronet_http/lib/src/jni/jni_bindings.dart
pkgs/cupertino_http/lib/src/native_cupertino_bindings.dart
pkgs/http/example/main.dart
pkgs/http_client_conformance_tests/example/client_test.dart
pkgs/http_client_conformance_tests/lib/src/compressed_response_body_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/compressed_response_body_server_web.dart
pkgs/http_client_conformance_tests/lib/src/dummy_isolate.dart
pkgs/http_client_conformance_tests/lib/src/multipart_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/multipart_server_web.dart
pkgs/http_client_conformance_tests/lib/src/multiple_clients_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/multiple_clients_server_web.dart
pkgs/http_client_conformance_tests/lib/src/redirect_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/redirect_server_web.dart
pkgs/http_client_conformance_tests/lib/src/request_body_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/request_body_server_web.dart
pkgs/http_client_conformance_tests/lib/src/request_body_streamed_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/request_body_streamed_server_web.dart
pkgs/http_client_conformance_tests/lib/src/request_cookies_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/request_cookies_server_web.dart
pkgs/http_client_conformance_tests/lib/src/request_headers_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/request_headers_server_web.dart
pkgs/http_client_conformance_tests/lib/src/request_methods_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/request_methods_server_web.dart
pkgs/http_client_conformance_tests/lib/src/response_body_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/response_body_server_web.dart
pkgs/http_client_conformance_tests/lib/src/response_body_streamed_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/response_body_streamed_server_web.dart
pkgs/http_client_conformance_tests/lib/src/response_cookies_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/response_cookies_server_web.dart
pkgs/http_client_conformance_tests/lib/src/response_headers_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/response_headers_server_web.dart
pkgs/http_client_conformance_tests/lib/src/response_status_line_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/response_status_line_server_web.dart
pkgs/http_client_conformance_tests/lib/src/server_errors_server_vm.dart
pkgs/http_client_conformance_tests/lib/src/server_errors_server_web.dart
pkgs/http_profile/lib/http_profile.dart
pkgs/java_http/lib/src/third_party/java/io/BufferedInputStream.dart
pkgs/java_http/lib/src/third_party/java/io/InputStream.dart
pkgs/java_http/lib/src/third_party/java/io/OutputStream.dart
pkgs/java_http/lib/src/third_party/java/io/_package.dart
pkgs/java_http/lib/src/third_party/java/lang/System.dart
pkgs/java_http/lib/src/third_party/java/lang/_package.dart
pkgs/java_http/lib/src/third_party/java/net/HttpURLConnection.dart
pkgs/java_http/lib/src/third_party/java/net/URL.dart
pkgs/java_http/lib/src/third_party/java/net/URLConnection.dart
pkgs/java_http/lib/src/third_party/java/net/_package.dart
pkgs/ok_http/lib/src/jni/bindings.dart
pkgs/web_socket/example/web_socket_example.dart
pkgs/web_socket/lib/testing.dart
pkgs/web_socket_conformance_tests/example/client_test.dart
pkgs/web_socket_conformance_tests/lib/src/close_local_server_vm.dart
pkgs/web_socket_conformance_tests/lib/src/close_local_server_web.dart
pkgs/web_socket_conformance_tests/lib/src/close_remote_server_vm.dart
pkgs/web_socket_conformance_tests/lib/src/close_remote_server_web.dart
pkgs/web_socket_conformance_tests/lib/src/continuously_writing_server_vm.dart
pkgs/web_socket_conformance_tests/lib/src/continuously_writing_server_web.dart
pkgs/web_socket_conformance_tests/lib/src/disconnect_after_upgrade_server_vm.dart
pkgs/web_socket_conformance_tests/lib/src/disconnect_after_upgrade_server_web.dart
pkgs/web_socket_conformance_tests/lib/src/echo_server_vm.dart
pkgs/web_socket_conformance_tests/lib/src/echo_server_web.dart
pkgs/web_socket_conformance_tests/lib/src/no_upgrade_server_vm.dart
pkgs/web_socket_conformance_tests/lib/src/no_upgrade_server_web.dart
pkgs/web_socket_conformance_tests/lib/src/peer_protocol_errors_server_vm.dart
pkgs/web_socket_conformance_tests/lib/src/peer_protocol_errors_server_web.dart
pkgs/web_socket_conformance_tests/lib/src/protocol_server_vm.dart
pkgs/web_socket_conformance_tests/lib/src/protocol_server_web.dart

Package publish validation ✔️

Package	Version	Status
package:cronet_http	1.3.2	already published at pub.dev
package:cupertino_http	1.5.1	already published at pub.dev
package:http	1.2.3-wip	WIP (no publish necessary)
package:http_profile	0.1.1-wip	WIP (no publish necessary)
package:ok_http	0.1.1-wip	WIP (no publish necessary)
package:web_socket	0.1.6	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[brianquinlan]

Hey @kevmoo

What is your expectation here in terms of review?

[kevmoo]

@brianquinlan – and maybe @devoncarew – need to figure out (1) if this is a pattern we want to support and (2) if this approach is good.

package:dio provides onSendProgress and onReceiveProgress callbacks. But adding those to request methods would be breaking.

An alternative would be to add those as fields to a new class BaseRequestWithProgress. Clients could check if the Request that they are passed is a BaseRequestWithProgress and, if it is, they could make the callbacks. This is similar to our existing BaseResponseWithUrl class.

When we decide to release package:http 2.0, we'd update BaseRequest to contain this information (along with all the other APIs).

[tlueder]

Hi @brianquinlan,

sorry for the noice here. I needed my branch updated and forgot that it is linked to this MR.

I don't know what I can or should do to advance this MR.

[brianquinlan]

I think that we have to coordinate landing this (or something like this) with an semver major release and I don't have the bandwidth to work on that right now.