The mobile radio will eat your battery very quickly, and probably chews through as much power as your screen. If you want to see how expensive it actually is, disable fast dormancy†. A slightly less brutal demonstration can be had by opening an OpenVPN connection. The keep-alive packets will keep your mobile radio in a higher power state, pretty much in the same way some disrespectful apps do and you'll (quite unsurprisingly) see your battery drain faster.
A badly written app can drain hours of battery charge, not minutes.
> Your users will be better served by you fixing bugs or adding features.
Excessive power drain is undoubtedly a bug. I absolutely love apps that respect the fact I want to go as long as possible without charging my phone. I might often be in a position where I can't charge my phone too. (Carrying a second or third battery is useful, if you've got a phone that has a replaceable battery.)
> Really, unless you're a huge team with a huge budget...
It's quite trivial to think about performance and battery life. This is something every mobile developer should be thinking about from the get-go anyway, and if you can't afford to write an app that performs well, you can't afford to write an app.
> Making battery usage the prime concern for most apps is overkill.
I'll uninstall apps that I identify as too power hungry without a second thought, and I'll also write negative reviews too. I'm pretty sure that when put in this light, power consumption suddenly becomes important.
† Don't do this. Some phone networks are misconfigured and may fail to ever recognize that the phone is FD-capable again.
I work for a mobile operator, and have had to work on several network issues related to poorly designed apps. I agree with kintamanimatt on this, it's not premature optimization, you need to know the cost of what you're doing. There is an incredible resource cost, to all the naive developers making apps these days, that treat the wireless interface as an always on connection.
1. Server polling every minute
We actually sent one customer an invoice for over $100,000 because they had a particularly bad application that polled a server every minute. This was only an internal app used by a few hundred people, but they used it at their office, and it caused constant blocking on the cell site covering their office. This actually broke cellular coverage near their office, and caused issues for all the other customers in the same area. Ultimately, we said, we can help you fix you're app, you can pay the invoice to upgrade cell coverage to you're office, or get off our network. In this instance, we helped them fix their app, so it only interacted with the server when something needed to be changed (the server pushed changes), which was actually quite easy to do. This simply isn't the same thing, as writing an inner loop in assembly, to shave off a few microseconds in runtime, which would be premature optimization, and actually making robust software that works well wherever it is used.
2. Synchronized network access
This one has been the bane of us on a few occasions. If you write a network access to be like a cron entry, that run's not only every 15 minutes, but does so at exactly the same time between all devices. We get to hunt you down, and scream, as our wireless network crumbles. When every device, wakes up at the same time, and asks for a higher power state, at exactly the same time, the network will only process so many. The funny thing is, you'll test this yourself and not see anything, but then when you release your app, you might find 30% of those checks are failing for some reason, and struggle to figure out why. For any one who is thinking, well the operator should add more capacity, the answer is we do, but ultimately the customer pays for the network build.
3. High usage apps
What happens is, your device vendor, is in the interest of protecting it's customers as well. We once had an app on our network, that would treat all reject codes, as a cause to retry. This caused it, to every time it was run, begin uploading data, over and over again, leading to thousands of dollars in bills to the customers for excessive data usage. The device vendor, pulled the app from their stores.
Now, how do you feel, about having to plead the case why you should be allowed to continue to sell your product, not only to the device vendor, but the carrier who found the problem, prove that you fixed it, have our bureaucracy test that you actually fixed it, and maybe if we feel like it, let you sell again. It's not as simple as fix the bugs, you might actually lose you're ability to make money of you're software, for months while this get's sorted out.
What do you think you're store rating will be, when all your customers get sent a $5000 bill for using your app?
Now the question is, should there be a better way, and I'd like to see more from mobile vendors, in making it stupid easy to be smart about this. In the phone API's, if I need to do a background update, I should be able to register with the OS, and say, I have an update to do, within the next 15 minutes, let me know when you have an active radio connection. You're phone goes into a high powered radio connection, and bam, all you're background updates now go out together. Need to send notifications, here is our push API, only interact with the mobile when an update needs to be done. If the API's you're using, are designed for mobile, and take alot of this network stuff that you shouldn't need to know into account, it's a lot easier for the naive developers to do better by blind luck.
* my views in this post are my own, and do not reflect those of my employer.
Aside from these things, is there anything else as a mobile developer that I can do to make your lives happier? I'm not guilty of any of those things you've mentioned and try to write well-behaving apps, but I'm always on the look-out to find out about stuff I don't even know I don't know!
Also, perhaps you could you lobby your higher ups to put together some kind of best practice guide from a network operator's perspective. I know the Android team do touch on this in their guides and in the Google I/O conference talks, but I'm guessing there's additional information that would be beneficial.
1. Power States
On UMTS, if the radio is "idle", it won't lose packets, but just a small amount of data, isn't enough to trigger a transition to a higher power state. These packets generally won't be lost, but can take 2 seconds or more to transit the RF network. If a transition is required, from the lowest power state, that alone can take 500-800ms. The important lesson from this, is that when just starting out a TCP/IP connection, it could be very slow for the first little bit, until the phone/network realize there is more data passing.
On LTE, this is less of an issue, as there are only two power states, which are idle and active. As such, you always have to transition to an active power state to do any data, and the transitions have been significantly optimized. However, the transition can still take a few hundred ms in this case.
This mostly becomes an issue, when you want to do something in real-time. We see lots of reports and have many investigations on things like call setup time on voip connections, etc. From an app perspective, this can be pretty hard to account for, but with the move towards LTE, this will constantly get better for you, since it's both faster and simpler.
2. Packet Loss
This point is hard to get across internally sometimes, but packet loss will occur. It's a radio network, and there are interference sources, and situations where we can't deliver every packet within a guaranteed time. You'll also get temporary losses of connectivity (user goes into a tunnel). This can get even weirder, where we get stuff like the uplink is working, but the down-link has very high loss.
We have seen many DPI, IDS and Firewall vendors have problems with this packet loss, and may cause inspection to fail, or the connection to get delayed. One thing that often happens, is these vendors don't use a large enough reassembly buffer for a mobile network. With the higher latencies we get on wireless networks, there tends to be more in-flight data at any one time. On CDMA, when a re-transmission was required, more than 100 packets of in flight data could pass before the ack/sack indicated the packet was to be re-transmitted.
3. Initial Window
On the server side, it should be fine to set the initial window to 10 packets as per the ietf draft: http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-00
I haven't had an opportunity to test this out, but my gut feeling is this should actually help, as the more pending traffic will help indicate what's happening from a power state standpoint. There are guides for many different OS about how to change this setting, as it won't be applied by default.
4. Exponential Back off
This probably isn't so important at you're level, but we've had issues more at a device stack level, that if some piece of the network is lost, we get two problems. Fixing the piece of the network, and fixing the "mass calling event", which is all the devices trying at the same time to reconnect to that resource. This is mostly out of you're control, but perhaps keep this in mind for your own server's benefit. If your server goes down, don't have all you're clients go nuts trying to re-establish connections as fast as they possible can.
Just in case you use SMS in any way, perhaps as part of push, one property of SMS, is if it's not successfully delivered on the first try, when it get's queued for redelivery, it could be delivered several hours later. Also, at least on our network with the newest technology, we've had some bugs we've had to look into with the same SMS being delivered multiple times. One property of SMS you can also take advantage of, is if the device is out of coverage (powered off, tunnel, etc), when it comes back into coverage, the pending messages should be delivered.
6. Reject Codes
HTTP and many other services usually have the concept of transient failure and permanent failures. Make sure not to retry on permanent failures. I got at this in my previous topic, but we've seen more than once, where something like a large email get's stuck in an outbox, because the mail relay has a maximum size limit on it. However, the rejection occurs after the upload, so the device sits their constantly uploading the same email over and over again. I'd even be careful with transient failure, and if the transient failure occurs for more than 3 or 4 tries, or an hour, to give up.
If you can, you may as well use compression to the best of your ability, to keep resources smaller and faster. Even though the network is faster, it'll still deliver a smaller payload faster than a bigger payload.
8. Packet Size
This one is often missed, but can be hugely important. And I almost forgot to tell you. What happens in a mobile network, is you have IP traffic that is destined towards the mobile. However, the mobiles position and pathway isn't fixed, so our network has to track the user and update the path. The way this is done, is network equipment will encapsulate the IP traffic with additional IP headers, for delivery internally within our network. However, our network has the same limitations for maximum packet size. So what happens, is when we do our encapsulation, we have to chop the packet into pieces, and then put it back together on the air interface. For awhile, we also used to just IP fragment you're packet into smaller pieces, but unfortunately this is also problematic as devices don't necessarily do the best job joining the fragments either, especially if they get delivered out of order.
So on my network, we use something call mss clamping, to limit the maximum size of TCP payload data in a single frame. We do this, so that when we encapsulate the packet, it will fit into one packet with our headers. However, MSS is a negotiation that only happens on TCP, so it cannot happen on UDP traffic. I also know for a fact, that not all carriers will do this, and I have talked to one or two developers about why their app will work on our network and not others. This is something you can adjust server side, to be consistent across carriers. As such, on the public interface of the server, I would recommend something like a MSS of 1350 bytes, which is enough for our internal headers, and IPSEC, but not require the packet to be chopped, than reassembled by the network.
As for lobbying the higher ups, I'll see what I can do. I think it's a great idea, and carriers worldwide aren't doing enough in the space. However, this is a really tough one, since as a large company, communications and branding are greatly metered, and it doesn't help to do all this work, and have no one read it anyway, because app stores today seem to be about volume, not quality. Really, what I'm seeing on my side of the network (The Packet Core), is a lot of the technology development, is to allow the network to be more flexible and robust towards the way it is used, than attempting to control the ecosystem. Ultimately what happens more and more, is we get just strait PC's connecting to our network, and we want to offer a superior experience in this space. Also, the most efficient devices are losing, where blackberry used to be an order of magnitude more efficient than everybody else, has largely been eroded by having a faster network and competing devices although less efficient, deliver superior experience.
However, a little bit of searching did turn up some initiatives. Not so much best practices, but in Canada the major carriers put together a consistent API access for location, SMS, and billing.
Also, it looks like ATT has some information, but it looks like it's more geared at enterprise, and most of the content is locked:
Hopefully we will continue to see, more partnerships among carrier, more standardization from the 3GPP and GSMA, and better API's to get the ecosystem more mature, and it'll be better for everyone. I'm also hoping to see more work on SCTP or multipath TCP, so we can start to see connection level handoffs between different access technology, ie wifi offload when you're at home. There are some technologies for call continuity today from you're wifi, but they're amazingly complicated, and only work in very specific scenarios.
* my views in this post are my own, and do not reflect those of my employer.
Release early, release often. If users love your app after release, focus on fixing the littler things like battery usage. If users hate it, try to fix the things that make them hate it, and then focus on the battery life.
Caveat: As in all optimization discussions, there are reasonable minimum thresholds for acceptability even in the "unoptimized" state. Desktop software can't take thirty minutes to boot no matter what stage of life it's in, and mobile software can't kill your battery in an hour or crash the nearby cellular network at any point either.
Don't make your software egregiously bad; just make it good enough.
"reasonable minimum thresholds for acceptability" is a great phrase that I will certainly be stealing.
I'm not saying throw caution to the wind and poll a remote host constantly and indefinitely, as I said originally, I think it's right to be concerned about resource usage. This is just a baseline for decent software. Be a "good citizen" and all that. (In most cases) If you can make one query for 100 items, rather than 100 queries, or 10 queries, do that. But that's just common sense.
>Excessive power drain is undoubtedly a bug. I absolutely love apps that respect the fact I want to go as long as possible without charging my phone.
Again, I think we are in agreement. Excessive drain is a bug, but my experience is that if you're already following best practices and not doing anything wild, you won't be a battery hog.
The article makes a HUGE list of do's and don'ts
I think it can be a lot shorter:
* just because you can, doesn't mean you should
* learn and follow best practices
* be mindful and conservative in your usage of all resources on the system
> I might often be in a position where I can't charge my phone too. (Carrying a second or third battery is useful, if you've got a phone that has a replaceable battery.)
Even if your phone doesn't have a replaceable battery, there are a lot of slim, rechargeable battery packs you can buy for around $20, many with short little USB cords that fold up in to them and others where you can use your own cord as well. The nice part is it will still be usable even if you change phones, and can be shared with other devices and people if needed. Some of them will even let you charge them inline with the phone so you're only using one usb port.
What are you doing on your phone/what phone do you have that you need 3 batteries?
The design decisions you make early on will stay with you. How you treat "occasionally connected" users is likely to have some architectural impact. Keep their requirements in mind as you sketch out your application.
> The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.
But as someone on Ward's Wiki said http://c2.com/cgi/wiki?PlanToThrowOneAway ,
> The corollary to this is that if you plan to throw one away, you will end up throwing away two.