You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
When connecting, uploading and downloading data from IoT devices, sometimes we need to be able to only perform a network request through a specific network interface (e.g., WiFi).
A long time ago I implemented this feature for rn-fetch-blob (joltup/rn-fetch-blob#497), and I'm planning to migrate to this library, but this feature is a must for us.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Copying code from joltup/rn-fetch-blob#497 is probably a good start. A very simple flag to force WiFi and never falling back to mobile data.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
Hi @cristianoccazinsp, thank you for suggesting this feature! And glad to hear I'm helping a rn-fetch-blob user out, that was one of the most important reasons for me to start this library :)
At first I was kind of torn on whether or not to add the feature you're suggesting, because I figured detecting if wifi is on shouldn't be a consideration for react-native-blob-courier, and should be detected through react-native-netinfo before starting the transfer instead. But then I read your code and found your StackOverflow-post and realized that the goal of the feature you're suggesting is to actually force the download over wifi even when other connections are available. To be fair, you actually wrote that in the last line of your feature request, but I was thrown off by the naming of the wifiOnly flag.
Considering that, this feature is in scope and think it would be a nice addition to the library. I would like to enhance the suggested interface a little to make it more extensible though.
Instead of:
{(...)wifiOnly: <boolean>,(...)}
I propose something like this:
{(...),channelPreference?: [<cellular|wifi|other| ... >],// ordered list of preferred channels [1](...)}
@edeckers that interface looks better. When I added the feature I was in a hurry to get it working so that was the easiest option.
Keep in mind this feature was intended to be able to connect to IoT devices, which are most of the time connected through WiFi in a local address (e.g., 192.168.1.1), so in my use case I would never use cellular data to connect to it.
Thank you for elaborating. I'll try to add the new interface in January.
If you want to take a shot at it yourself before that: I accept PR's! Just make sure to adhere to the interface we discussed here and to include relevant tests for TypeScript, Kotlin and Swift and we should be alright.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
When connecting, uploading and downloading data from IoT devices, sometimes we need to be able to only perform a network request through a specific network interface (e.g., WiFi).
A long time ago I implemented this feature for rn-fetch-blob (joltup/rn-fetch-blob#497), and I'm planning to migrate to this library, but this feature is a must for us.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Copying code from joltup/rn-fetch-blob#497 is probably a good start. A very simple flag to force WiFi and never falling back to mobile data.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: