If You're Programming a Cell Phone Like a Server, You're Doing it Wrong

Since Android is an open system, would it be possible to write an app that runs on a phone and forces applications to batch transfers?

I'm thinking of a "limiter" app that runs locally on the phone, and disables TCP/IP transmissions every 18 minutes out of 20. That way things like email you can still get relatively quickly, but the radio's only on 10% of the time.

Developers and users both being aware of the problem and trying to fix it might mean their solutions collide. E.g. a badly behaved app that tries to access the network once every 30 seconds will always get through during the 2-minute window, but a well-behaved app that only hits the internet every 10 minutes might miss the window entirely.

So maybe the limiter should intercept outgoing TCP/IP connections, lie to the initiating app and tell it the connection happened but the remote end isn't sending any data, then connect the outgoing app to the real remote end when the radio switches on. Of course if there's an application-controlled timeout interval on the connection, it'll trigger and the 10-minute-interval app would miss the window.

You might get around that problem by using whatever UNIX signal Ctrl+Z generates, to lock up an app entirely when it tries to open an outgoing connection, then resume it when the radio's on. Of course, this'll probably lock the app's UI too, so it'll become totally unusable. Although if the limiter acts like a screensaver and goes away whenever the user's recently given any touch or keyboard input, that doesn't really matter, does it?

Or maybe Google should make an API where an app can say, "I want to make a connection, and I'm willing to wait if turning the radio on right now wouldn't be good for the user."

What the hell? The M7 is a marketing label for some COTS silicon they licensed from some IP company somewhere (probably ARM/Broadcom or one of their associates).

It doesn't make unicorns shit rainbows or defy the laws of physics.

The problem with the battery statistics is that even though an app that is causing battery drain it might not be registered with that app. Imagine an app that sends a 1kb probe message every 15 seconds in the background thus keeping the radio alive the entire time (i.e. never allowing it to idle). I believe that the battery drain caused by the radio usage would count towards "Android System" and not the app when in reality the app would be shortening your phone battery lifetime significantly.

Assigning battery usage to apps is a hard thing as there are so many grey areas. OTOH you will notice apps that are stuck in CPU expensive loops that will not terminate, however this is not that common in my experience.

The Android battery statistics are nice but they usually don't provide me with a useful answer to the question: Which app is really draining my battery.

Fred Brooks, maybe?

> 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.

>Respecting known limitations and working within best practices is absolutely not premature optimization.

Absolutely.

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.)

(gadget aside) 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?