This exists on Android. If you enable the "developer settings"

https://www.howtogeek.com/129728/how-to-access-the-developer...

you then have the option to enable "Aggressive Wi-Fi to Cellular handover"

> It just artificially reduces the WiFi RSSI (received signal strength indication) to encourage the WiFi state machine to decide to switch the connection from WiFi to cellular network.

https://android.stackexchange.com/questions/90250/what-does-...

Anecdotally, I have had fewer headaches with the phone holding on to poor wifi-signals since I enabled this. Ideally the phone would handle this in a smarter way, e.g., by monitoring the strength of both the wifi and data signals and switching to whichever is likely to have the least packet loss.

> Ideally the phone would handle this in a smarter way, e.g., by monitoring the strength of both the wifi and data signals and switching to whichever is likely to have the least packet loss

The tradeoff here of course is battery life. The phone OS doesn't want to switch on a second radio until absolutely necessary for obvious reasons.

As someone who works in a building with four underground stories, this cuts both ways: there are plenty of times when I've had seemingly zero bars and full wifi yet no ability to conjure network access until I manually disable cellular data. Why it's trying to prioritize cell over wifi in the first place, god only knows.

I'd imagine it could have something to do with the incentive to take up as much cellular data as possible, the same reason many providers don't let your phone access the built in antenna.

I turn it off when I get into my elevator because if not it'll be in a 1x limbo state for about five minutes, even once I am completely out of the building.

Phone apps in general have a huge problem with extremely high timeouts and no user-facing cancel/retry buttons.

My intuition for whether a request that's not done yet is ever going to complete seems to be much better than what's written into most apps. It's really annoying when I have to entirely kill and reopen the app, rather than just have that one operation retried.

The answer to that of course is that the underlying network protocols need to be aware of this dilemma. It's wasteful for every developer to try and solve this problem on their own.

The main culprit here is of course TCP's session based view of the world which was invented for a completely different era. An era when "cable got cut" was a catastrophic event that was almost never going to happen. It's a pity that the native app world is still mostly stuck with TCP/HTTP based networking stack where a UDP/mobile-specific-protocol is what's needed.

Get llama