blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px
#715FFA solid !important; padding-left:1ex !important; background-color:white
!important; } Your biggest problem on a 2G network might actually be latency.
Resolving DNS, establishing a TCP connection, negotiating TLS and issuing a
first HTTP request will take a while (likely around 2 seconds, maybe more if
the underlying network connection needs to be established), which means that:
-You need to run all your network requests through a single socket, i.e. to a
single host.
-You need to open a network connection as soon as the app starts, but you
shouldn't rely on getting any response before displaying a meaningful UI, not
even an HTTP 304.
-For ultimate optimization, you'll need to embed a QUIC stack into your app,
but that's heavy engineering, and the binary size might be prohibitive if your
users need to download you app over a slow connection.
Your next problem is throughput.
-Obviously, your content needs to be put on a diet.
-Be very careful about the size of your HTTP headers (request and response).
-If you're targeting users with network throughputs ranging from 100 kbps to
100 Mbps, you might need to look into serving different content (or different
variants).
-On slower connections, there's a good chance that your bandwidth-delay product
is low, such that a single socket is likely to be able to saturate the link.
Multiple sockets are likely to compete for resources and end up slower.
-Beyond that, you have to be able to measure your content and optimize the
heavier parts.
-Truly adaptive content is surprisingly hard at scale, typically because most
optimizations are beneficial in all circumstances, not just on slow links.
Chances are, the result will boil down to disabling videos entirely and having
a few buckets (probably between 3 and 5) for image quality.
-Pay very close attention to your ads. They should represent a nominal increase
in your payload size, and never be as large as (or larger than) your actual
content.
There's a risk that your users have per-byte charges, such that
downloading/prefetching in the background might not be an option. Also, slow
connections tend to drain the battery the most (on a per-byte basis).
Also, to keep in mind: on a slow link, a predictable progress bar helps the
user experience a lot. That's easier on a solid connection (e.g. steady 2G)
than on a bursty connection (e.g. congested 3G).
Finally, in an Android-specific way, consider building multiple APKs that each
target fewer devices. You can typically split by density, and by CPU
architecture (if you use the NDK).
JBQ
--Jean-Baptiste M. "JBQ" QuéruMobile Excellence Architect, YahooSent from the
Yahoo Mail app
On Monday, January 11, 2016, 5:19 PM, Anshul Jain <anshul.jain...@gmail.com>
wrote:
Today most of the applications use internet in some way or the other. But in a
country like India, network is the one of the major issues for most of the
users. Most Indian users are still on mobile networks rather than Wifi. Even
networks like 3g tend to be very slow. So in this scenario, how do the big and
most widely used android applications which perform extensive network
operations work and optimize their network calls?
I am working on a news reading application which contains news content, news
image and also advertisements. Now if the network connection is not good, then
it gives a bad experience to the user. So before making requests, I want to
determine the connectivity of the user in real time. And based on the network
type, I want to enable or disable some of the content.
Android provides a class Networkinfo which can be used to determine the type
and subtype of the current network based on which we can categorize the network
as WIFI, 3g , 2g etc . But this information doesn't practically help in real
time because even a Wifi network can be slow sometimes. I came upon a class
from Facebook Connection Class which helps to determine the speed of the
internet based on the actual transfer of the data. Based on this library the
connection can be classified into four categories like POOR ( < 150 kbps ),
MODERATE ( 150 - 550 kbps ), GOOD ( 550 - 2000 kbps ) and EXCELLENT ( > 2000
kbps ). Now this solutions seems to little more practical and I intend on
including this in my application.
Before plunging into any implementation, I want to know how other applications
which have huge network calls optimize their operations for poor networks ? Any
references would be really helpful.
--
You received this message because you are subscribed to the Google Groups
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/android-developers/ab4c9391-a402-436c-80ff-ef4c73ee54ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/android-developers/1944694242.3587214.1452692493381.JavaMail.yahoo%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.
