As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:
- Transmit no data.
- Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.
- If you must transmit, then transmit only a small volume.
- If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.
- If you must transmit, then compress as hard as possible.
- Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.
- If you have transmit a lot, then do a lot
- If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.
- If you receive, then transmit
- If your peer raises the radio state, you may as well use it.
And for servers, similar rules apply:
- Send no data.
- Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.
- If you must send, send tiny bits.
- Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.
- If you receive, then send anything you have.
- Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.
- If you must send when not receiving, send plenty.
- Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.
- XEP-0286: XMPP on Mobile Devices
- GSMA: Smart Apps for Smarter Phone
