-2

I don't even know whether this is a good question. But it's annoying me and I don't get why it works so badly for me, and it's annoying me that I don't get it.

Point is, when switching from one mobile cell to another, you don't notice, right? The internet connection just continues. There's no noticeable interruption. Even if the cells use a different technology, like HSPA, GPRS and whatever there is. But when switching to wi-fi or back, there's a dropout. A loading web page will say that there is no connection available and stop trying to load. An online game will kick you out immediately, probably discards your progress and asks if you want to reload the game (like Clash of Clans).

When switching between connection types, there's a hard drop. Being able to freely use hundreds of wi-fi access points during a trip is completely useless! While I think the whole purpose of public wi-fi access points is a strong and reliable internet connection, the result is exactly the opposite! (unless you stay in one spot with strong connection to one of them of course).

I asked myself why this was the way it worked when I had my first smartphone, with Android 2.3. I'm using my fifth now, with 5.1.1, and the problem is still exactly the same. How is this possible? Doesn't anyone care? Isn't there some internet connection layer in Android that applications communicate with, regardless of connection type? Or why is there no option to use mobile and wi-fi connections simultaneously? I would be okay with it if switching network type would cause a small delay, but instead it's just immediately dropping dead, destroying partially loaded stuff.

I can think of several solutions, none of which anyone seems to have worked on. Maybe the apps shouldn't be programmed to whine that much about connectivity. But still, if the connection you're using (either cell or wi-fi) just doesn't have any throughput for a second, that's no problem at all. Unless it switches to another type! Even though that might be done in a second as well. How do apps even know the difference? IMO, they really shouldn't. Or is it the case that Android always turns off mobile data as soon as it starts connecting with wi-fi, even though the connection isn't established yet? That would be extremely stupid.

Meanwhile, my 'workaround' is a terrible one: just switch off wi-fi while I'm moving. But obviously I forget that pretty often, or forget to turn it back on when I'm home.

Can anyone shed some light on the matter for me?

  • Are you looking for a recommendation for an wifi-turnoff app? Would an automation tool like Tasker or Llama do, which can check for proximity, can perform timed actions, etc? – wbogacz Sep 18 '15 at 13:30
  • No android update will sove a problem that is a) not a problem and b) not related to android. – Mindwin Sep 18 '15 at 14:21
4

TL;DR: When you switch internet connections you get another IP address, the online services have to drop and re-authenticate because it is the only way to know who you are from a new IP. It has nothing to do with Android.


It has nothing to do with Android, and everything to do with how TCP connections and IP addresses work.

When you switch cell towers, the cell provider servers re-route your cellular communications (including your internet traffic) to the next tower, but the provider servers KNOW you are you (from the IMEI of your phone and your SIM card), and the fact you switched cell towers is not transparent to the internet. You remain with the same IP address (most of the time), and all your connections are kept alive.

This same effect can be achieved with your home wi-fi, if you have a repeater in distinct rooms and just move around. The DHCP of your home router will remember your machine (from the wi-fi MAC address), and just redirect your traffic to the other repeater.

When you switch from 3G to WIFI, you are getting your traffic to another network device, another network entirely. Your IP address changes. The services you were connected to have no chance to tell you are you. And it is a good thing otherwise anyone on the net could impersonate you on facebook (or any other online service for the matter). "Whining about connectivity" is actually caring for your security and online identity.

So you have a hard drop. The apps have to re-authenticate themselves, to show that it is still you, and not another person.

The same issue would happen if you were traveling with a PC laptop and jumping from hotspot to hotspot.

  • With REST you're not having that problem. There's still a small pause tho. – ott-- Sep 18 '15 at 19:21
  • @ott-- but the specific APP must implement REST. Not the case for the vast majority of apps as of this writing. – Mindwin Sep 18 '15 at 20:49
  • Not every app can implement REST. But for the rest (sic) they have missed the bus. – ott-- Sep 18 '15 at 21:50
  • Thanks! That explains it. So apps will never be able to /keep/ the connection, because you can't have the same connection over multiple networks. They could, however, make a new connection in the background and for the user make it look like everything keeps flowing, but that's more complicated or restrictive to build. – MarijnvdZaag Sep 21 '15 at 11:44
  • @MarijnvdZaag there are some techniques to "keep" (mind the quotes) the connection alive when switching networks, but that means using some tricks to recognize server/client even when IP changes. Read about REST, that ott-- mentioned above. But as a rule of thumb, switching IP (or gateways) means re-connectiong all the services. Some are just more seamless than others – Mindwin Sep 21 '15 at 12:52
-1

I agree and disagree. I have a voip app. On iPhone the handover is fast enough that you can continue a call. On android the call is dropped while the app reconnects.

The aggressive wifi to mobile handover option has no effect. Reading on the option it would seem to merely drop the wifi in favour of mobile data at a higher rss.

-2

Enable and open Developer Options and toggle the option that says "Wi-Fi and Network Always On" or "Aggressive Wi-Fi to Cellular Handover" for faster switching.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.