DevBytes: Efficient Data Transfers - Understanding the Cell Radio
Why Stack Overflow recommends it
Stack Overflow users link it when explaining why the first network request is slow or why polling and frequent small transfers drain battery on Android.
Recommended by 2 people across 2 different months, 2013 to 2014.
What it is
A six-minute DevBytes episode from the Android Developers channel, presented by Reto Meier, explaining the state machine of a smartphone cell radio. It shows how radio power states affect battery drain and how timing and batching network transfers can reduce it. It is the first of a seven-part series on efficient data transfers.
What people said
Strong rec Mark Allison · 2014-03 · Stack Overflow · on “Android: first http response always takes longer (even without keep-alive)”
I suspect that the lag that you are seeing is simply down to the cellular radio transitioning from either low power or idle state to full power (which can take over 2 seconds). Check out Reto Meier's excellent DevBytes series on Efficient Data Transfer [this video] for an in-depth explanation of what's going on.
Recommends matiash · 2014-06 · Stack Overflow · on “Is httpPost too demanding to be used in an Android service?”
In general, this would not seem like a good idea. The scenario you describe seems like a perfect fit for GCM. I would first try to convince your boss to reconsider. :) "Polling" a server, even for a brief connection which transmits hardly any content, means the device must be woken (from a low power state) and the radio turned on, and it will stay on for a significant time. The impact on data consumption will probably be insignificant, but battery usage will be a concern. In case it cannot be avoided, you should check Minimizing the Effect of Regular Updates [LINK] section of the Efficient Downloads referenced by @CommonsWare in the comments. Also, Reto Meier gave an excellent talk [LINK] on
Cites saywhatnow · 2013-10 · Stack Overflow · on “Robospice/ Retrofit background service accessing database”
In the end, as I'm batching the various Rest API service calls to save radio ( Reto Meier Dev Bytes: Efficient Data Transfers [this video] ), I call the Rest API services ( RetrofitSpiceService s) from within a controller Robospice SpiceService containing both the reference to the DatabaseHelper (requiring Context ) and the respective Retrofit callbacks for the Rest services. This way, the controller service handles all the triggering ( AlarmManager triggers the controller service) and persisting to DB and the Rest services can shut themselves down as normal without knowledge of context , database or suchlike. For @lion789: I have 4 models each with a corresponding API call to sync with the serve