New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there support for wi-fi only uploads #187
Comments
Yes this should be a flag in dart which is picked up by the native side. |
The challenge with this approach is that the configuration is built immediately when the plugin is registered:
This is the place, where the flag would need to be respected and added to the configuration: Since this configuration is only available in the initializer and the session is supposed to be longlived, I don't see a way to schedule individual uploads with this flag. My idea here was that the user has a setting in the App to restrict uploads to wi-fi networks. I assumed that it would make sense to put this flag into each and every upload so that you could change this setting on the fly so to speak. For this to work, the session would need to be rebuilt every time an upload is scheduled. That seems wasteful and unnecessary. Some Apps require a restart in case a setting like this is changed. So maybe it would be possible to pass this flag along when constructing the Or put the flag in |
@lyio could we have 2 sessions (wifi, wifi+cellular) and the uploader picks the right one depending on the flag? |
I could give this a try. Would this impact the backchannel to the Dart side of things? We would also have two session identifiers. But the Configuring the session for wi-fi only uploads could be achieved similarly to how the background handler is attached.
We could add a method on the channel This only applies to iOS, of course, because on Android the WorkManger takes the wi-fi restriction on a per job basis, iirc. So this way we could delay constructing the session (or even the whole |
@lyio Start by having 2 session objects in the swift plugin and choose between them according to the upload object (which needs a new constraint parameter, or boolean flag) passed. You may not need additional methods on Dart side & only extend the Upload object. |
I have started to do just that. I will get a PR to you today. The only problem atm is that I do not have an iPhone that has cellular data. :) My testing capabilities are limited right now. |
Send something over, I'm happy to give it a spin later. Please do extend the example project with a checkbox or similar. |
+ Add flag to the Dart interface and pass it into the method channel when enqueuing jobs
+ Add flag to the Dart interface and pass it into the method channel when enqueuing jobs
+ Read `allowCellular` flag from method channel arguments when queueing uploads in iOS. + Add a second session and session configuration to `URLSessionUploader` that sets `allowCellularAccess` to `false`. The sessions are supposed to be long lived objects, so we construct both of them only once and keep them around. + Add switch to the actual creation of the upload task that respects the `allowCellular` flag of the job and chooses the correct session to schedule the upload.
…plugin + Respect the `allowCellular` flag in the Android plugin and set the `NetworkType` to `UNMETERED`. Otherwise any connection will do.
+ Remove null safe handling of the flag from the native plugins and throw an error in case the flag has not be set. + Add test to ensure there will always be a default value
+ Remove null safe handling of the flag from the native plugins and throw an error in case the flag has not be set. + Add test to ensure there will always be a default value
You have fixed it yourself. Thanks again. |
I know that Android WorkManager supports scheduling uploads for when there is a wi-fi connection. From what I gathered, the NSURLSessionConfiguration also supports restricting the uploads to wi-fi.
Will support for this be added to the plugin? Would this be more involved than adding a flag to the
UploadJob
and passing it all the way through to the native side?The text was updated successfully, but these errors were encountered: