feat(mobile): native clients #21459
feat(mobile): native clients #21459
Conversation
mertalev
changed the title
|
This is indeed a very good way to improve the networking experience. Sadly, the
The mentioned embedded version on the other hand bloats the apk size a lot (a year ago this would have been ~14MB, but it might have changed). |
Our plan is to eventually move everything to using the cronet / cupertino http packages since it has better features than the dart client. Sadly, this means that the F-Droid build has to suffer from an increase in app size due to the embedded cronet stack |
|
I still face the following error for the first few assets on the timeline. The init call should probably be moved to before we make the call to |
It's done in |
There are two |
mertalev
force-pushed
the
feat/mobile-platform-clients
branch
from
1ed1282 to
8d272f8
Compare
mertalev
force-pushed
the
feat/mobile-platform-clients
branch
from
7fe8b12 to
11ebbe5
Compare
mertalev
changed the title
|
Does this solve the problem with mLTS, custom proxy header, or self-signed cert on Android? |
|
I ran into this error while running on Android release build Terminate the app and reopen showed the same error |
I just tried the latest build with mTLS and it already fails during |
|
Sh... void CronetURLRequest::NetworkTasks::OnCertificateRequested(
net::URLRequest* request,
net::SSLCertRequestInfo* cert_request_info) {
DCHECK_CALLED_ON_VALID_THREAD(network_thread_checker_);
// Cronet does not support client certificates.
request->ContinueWithCertificate(nullptr, nullptr);
}https://chromium.googlesource.com/chromium/src/+/abc0bae34bdc9456d7e4a1f1aa2c6aa51a4bad4d |
|
I created https://issuetracker.google.com/issues/446368909 to ask about the chances to get support for client certificates in cronet. My guess is that it won't happen... but let's see. I haven't tried self-signed server certificates - I assume that they would work if they have been added to the OS keystore. For request headers, there seems to be an API. No idea about proxy headers. |
|
Thanks for looking into it! I'm a little surprised Cronet doesn't support client certificates. |
|
FWIW, I think the dart team is also exploring the possibility of having an FFI-ed The package has only one release so far, but the repo has more activity, particularly the following PR that is more relevant to our discussion: dart-lang/http#1444 It might be worth exploring this for android instead of There is also the fact that both the packages might suffer from crashes when used from a background flutter engine, which we do a lot: dart-lang/http#1720 The required changes for this on the framework has been merged and the maintainers said that they'll get a fix for the cronet implementation out soon. I also believe that when they do, they'd likely handle it on the OkHttp implementation of the same |
Not sure about OkHttp, but it looks like Cronet is getting fixed. |
Description
Remote thumbnails are currently fetched using a Dart client along with persistence using
flutter_cache_manager.This PR consolidates this into using more robust native clients. Not only are these clients better optimized, but they also handle caching and revalidation automatically based on HTTP cache control headers. Because of this, the PR tweaks the cache control directives to be more offline-friendly. Specifically, it allows stale items to be used for up to 30 days and be revalidated asynchronously to minimize latency.
This is in contrast to the current cache manager, which is both slow and currently has no invalidation beyond a max age of 30 days or going above cache capacity. As a mitigation for the cache manager's slow performance, cached assets are also only used as an offline fallback after the app relaunches.
The specified cache size limit is 1GiB. This is more generous than the current limit of 500 previews and 5000 thumbnails. Because of the storage savings with the new local thumbnail implementation, I think it's okay to allow more storage for remote assets, as caching is not just an optimization but also increases offline accessibility.
The PR uses a repository method to construct the HTTP clients to make it easier for these improved clients to be used elsewhere beyond thumbnails.