Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

highscalability.com

Post reply on HN
Print view View original

31–40 of 77 posts

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

#31

Post by lucb1e »

Oh, shit.

    apt-get remove apache2 php5 ...
And here I thought running Debian (for ARM cpus) on your phone was cool. Apparently I'm Doing it Wrong.

Puns aside, good article. If everyone did this (for example caching for 2-5 minutes ahead) things would run a lot better! Next time I'm going to code an app, I'll read through everything on this page first.

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

#33

Post by zyb09 »

canthonytucci wrote: post #5

> Every decision you make should be based on minimizing the number of times the radio powers up. This is lunacy. Ok, lunacy is a bit strong. But I disagree with this and am throwing a "premature optimization" flag. Modern phone batteries last plenty long, and the radio being on is nothing compared to the big bright screen. /edit Given the opportunity to chose, I know I would gladly sacrifice a few minutes per charge…

Not only are you helping the battery, but prefetching a lot of data, is also a good way to structure your app. It leads to better User Experience in the app if implemented correctly. If you start relying less on On-Demand connections in your app, you can separate UI code and Network code much more easily, which speeds up the UI and enables/improves offline functionality. Doing it in an IntentService on Android also allows for implementing very specific scheduling strategy.

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

#35

Post by [deleted] »

canthonytucci wrote: post #5

> Every decision you make should be based on minimizing the number of times the radio powers up. This is lunacy. Ok, lunacy is a bit strong. But I disagree with this and am throwing a "premature optimization" flag. Modern phone batteries last plenty long, and the radio being on is nothing compared to the big bright screen. /edit Given the opportunity to chose, I know I would gladly sacrifice a few minutes per charge…

[deleted]

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

#36

Post by sliverstorm »

ryanpetrich wrote: post #16
jaytaylor wrote: post #6

Earlier quoted context omitted.

> Presumably websockets are ok as it's more of a "push" model for the network than a "poll" model? This is seems incorrect - as I understand it, a websocket holds open a TCP connection indefinitely, which would require the radio to stay in its active state as long as the websocket remained open. See also: http://stackoverflow.com/questions/4456407/iphone-keep-webso...

I can't speak for websockets, but holding a TCP connection open indefinitely does not require that the radio stay in its active state. On iOS, setting the kCFStreamNetworkServiceTypeVoIP property on the connection allows the radio to return to the idle state and reawake when it receives data on the socket. Android may have similar APIs.

Wouldn't the radio have to wake on a timer to scan? How else will you notice there is data waiting on the other side of the connection?

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

#37

Post by tjohns »

kevinbowman wrote: post #24
tjohns wrote: post #19

Earlier quoted context omitted.

GCM is the recommended solution for anything that's trying to "push" data to Android: http://developer.android.com/google/gcm/index.html We (Android) usually don't recommend developers try to implement push themselves. Using GCM allows the Android servers to schedule and collate data transmissions, so push messages from different apps get sent as part of the same transmission. Anything you roll yourself won't be able…

What about for a webapp, even an offline one? Is there a hook into GCM from Javascript or something like that?

I suppose you could use the Java-to-JS bridge, if you're using WebView inside a native app.

However, there's not really any "mobile-friendly" push solution available as part of HTML5 right now. I wish there was. There's "GCM for Chrome" (http://developer.chrome.com/apps/cloudMessaging.html), but that's both Chrome-only and only available on the desktop.

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

#39

Post by kintamanimatt »

canthonytucci wrote: post #5

> Every decision you make should be based on minimizing the number of times the radio powers up. This is lunacy. Ok, lunacy is a bit strong. But I disagree with this and am throwing a "premature optimization" flag. Modern phone batteries last plenty long, and the radio being on is nothing compared to the big bright screen. /edit Given the opportunity to chose, I know I would gladly sacrifice a few minutes per charge…

Respecting known limitations and working within best practices is absolutely not premature optimization. If you know that using the mobile radio in a certain way is a source of excessive battery usage, it's silly to just disregard this information. It's not premature optimization if you know where the performance issues are from the outset, and these performance issues are so incredibly common that the Android team put out videos about them.

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.

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

#40

Post by tjohns »

mikeash wrote: post #17
jaytaylor wrote: post #6

Earlier quoted context omitted.

> Presumably websockets are ok as it's more of a "push" model for the network than a "poll" model? This is seems incorrect - as I understand it, a websocket holds open a TCP connection indefinitely, which would require the radio to stay in its active state as long as the websocket remained open. See also: http://stackoverflow.com/questions/4456407/iphone-keep-webso...

I think the radios are down at the IP level and have no concept of a TCP connection, so an open but idle connection won't keep the radio from shutting off. For example, Apple recommends that VoIP apps on iPhones keep a TCP socket permanently open and use it to receive notifications of new calls and similar: https://developer.apple.com/library/ios/documentation/iphone...

This is outside my area of expertise, but I've heard that there's a keepalive timeout for open sockets set by the cell carriers. (Again, don't know the details.) So, there is a small cost to keep a TCP connection open, in order to avoid this timeout.

Also, as I mentioned in my previous comment: Even if keeping the socket open is free, every time you send a packet there's a cost -- both for the actual data transmission, as well as a medium-power state the radio enters for a bit before really going to sleep. And given the number of apps that use background data, background traffic on a phone can get quite chatty. This is why it's important to synchronize background activity across apps. If you implement your own push channel, there's no way for the OS to do any sort of synchronization.

Post reply on HN