At Alpha we have a strong focus on real world customer needs (you would expect any successful company to have this focus after all!)
As part of this focus we have been hard a work on building an elegant solution to the problem of making sure your Alpha Anywhere app can continue to work when there no signal or poor signal
Here at 5app we have been conducting some tests to determine the real-life data connectivity that the public can expect from mobile data networks. The results surprised us:
We used a mobile phone to run a web page that uses GPS to detect your current location. Every 10 seconds we sent a web request containing this location and the GPS time to our server. This time stamped when the request was received, and from which IP number, and then sent this back to the phone. This simulated making a number of web page requests or Ajax queries.
We merged the data from the phone with the data from the server; the following images show the results we obtained.
As you would probably expect, phones aren't perfect. This track was made using an iPhone5 walking around the block from our central London office, and it's a few metres off most of the way. The orange markers show where the phone switched from the office WiFi to the mobile network and back again. The red markers show when a transaction failed to get through to the server, and the height of the green markers indicate how long the round-trip took - varying from under a second to 11 seconds, with the majority being around 1-2 seconds. But it took 20 seconds to realise that the WiFi access point was too far away and switch to the mobile network. What is surprising was that out of 35 data points sent 2 failed to get through - this was probably while switching between WiFi and mobile.
Here is an example from a car journey in a rural location. The signal was fine initially, then came and went in the valley before coming back again. There are two 30-second long sections where the phone wasn't connected, and if we had tried to access a web page then it would fairly quickly fail. The blue marker indicates a special case, which is when the message did actually arrive at the server but the reply did not. In this case if the request was to update data then the user might be tempted to send it again, making two transactions in total.
A little later on during the same journey west, now near Chippenham, there's another new IP address from O2, followed by a dead patch for a minute. Again any VPN would have lost connectivity from this point on.
Our results show that even in areas which you'd expect to have excellent coverage mobile device connectivity should be seen as "mostly connected" as opposed to "always on". So apps that appear to work perfectly when tested over WiFi in an office environment will behave rather differently out in the real world! Note too how IP addresses can change regularly during a trip, further exacerbating the problem. The surprising reality is that mobile data communications are fundamentally unreliable, something that all apps developers need to take into account.
06 Jun 2014
As part of this focus we have been hard a work on building an elegant solution to the problem of making sure your Alpha Anywhere app can continue to work when there no signal or poor signal
The surprising reality is that mobile data communications are fundamentally unreliable, something that all apps developers need to take into account.
Here at 5app we have been conducting some tests to determine the real-life data connectivity that the public can expect from mobile data networks. The results surprised us:
- Even on major motorways there are sections with no data connection;
- You can still fail to make a connection even in central London due to congestion;
- You may get several different IP addresses over a period of time;
- Requests that do work can take over a minute to respond;
- Data doesn't always get through.
Methodology
We used a mobile phone to run a web page that uses GPS to detect your current location. Every 10 seconds we sent a web request containing this location and the GPS time to our server. This time stamped when the request was received, and from which IP number, and then sent this back to the phone. This simulated making a number of web page requests or Ajax queries.
We merged the data from the phone with the data from the server; the following images show the results we obtained.
Walking around in a city
As you would probably expect, phones aren't perfect. This track was made using an iPhone5 walking around the block from our central London office, and it's a few metres off most of the way. The orange markers show where the phone switched from the office WiFi to the mobile network and back again. The red markers show when a transaction failed to get through to the server, and the height of the green markers indicate how long the round-trip took - varying from under a second to 11 seconds, with the majority being around 1-2 seconds. But it took 20 seconds to realise that the WiFi access point was too far away and switch to the mobile network. What is surprising was that out of 35 data points sent 2 failed to get through - this was probably while switching between WiFi and mobile.
Driving in the countryside
Here is an example from a car journey in a rural location. The signal was fine initially, then came and went in the valley before coming back again. There are two 30-second long sections where the phone wasn't connected, and if we had tried to access a web page then it would fairly quickly fail. The blue marker indicates a special case, which is when the message did actually arrive at the server but the reply did not. In this case if the request was to update data then the user might be tempted to send it again, making two transactions in total.
Traveling on the motorway
This is an interesting track taken from a coach travelling from east to west along the M4 near Reading, the sort of journey where you would expect good continuous mobile coverage. This time there's another instance (the blue marker) of the server receiving a message but the reply failing to get through, then a dead patch (the red markers) for 50 seconds or so, before the mobile is given another IP address (the orange marker) - both owned by O2, perhaps when switching between 3G and 2G. If you had been on a VPN then it would have broken by this change of address - although it would not have been immediately apparent as the old TCP/IP connection would have needed to time out.A little later on during the same journey west, now near Chippenham, there's another new IP address from O2, followed by a dead patch for a minute. Again any VPN would have lost connectivity from this point on.
Conclusions
Our results show that even in areas which you'd expect to have excellent coverage mobile device connectivity should be seen as "mostly connected" as opposed to "always on". So apps that appear to work perfectly when tested over WiFi in an office environment will behave rather differently out in the real world! Note too how IP addresses can change regularly during a trip, further exacerbating the problem. The surprising reality is that mobile data communications are fundamentally unreliable, something that all apps developers need to take into account.
06 Jun 2014
Comment