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

21–30 of 77 posts

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

#21

Post by hyperpape »

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…

Prefetching is often an element of a pleasant user experience. It also can bring difficult UI problems with it (when is information too stale to display, etc), but that just means it's not easy.

It feels like so many apps are designed by people who never have experienced a bad connection, and just assume that their app can download everything it needs quickly as soon as it starts up. What you end up with is bad experiences when your connection is slow or has high latency.

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

#22

Post by fulafel »

thibauts wrote: post #15

The author talks about Google Cloud Messaging to avoid polling. I've been researching the topic and gave it a try with websockets without much success. TCP connections tend to hang on cell tower switching and I suspect TCP keepalives keep turning the radio on. I really wonder how to implement push to client on the html5 platform. I even wonder if this is possible at all for now.

cell tower switching is transparent to TCP except for delayed packets. TCP keepalives are off by default and the default interval is 2 hours.

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

#23

Post by ianstallings »

DougWebb wrote: post #11

The last thing I'd want is for my apps to each be downloading several MB of data they think I might need in the next few minutes. I can easily control how much battery life is remaining on my phone by plugging it in. I can't control how much of my data plan an app is using, except by uninstalling the app. Besides, in my experience the biggest drains on battery life aren't data transfers, they're (a) having the screen…

It's funny I came here to mention how the handshaking from constant dropped connections and cell location changes should be accounted for. I've had to consolidate multiple calls into single calls in order to increase the network performance of mobile applications. It wasn't until I actually sniffed what was happening that I noticed the handshake issue as I walked around, went down into the subway, hit alleys, etc.

As for prefetching, I think that should be a user setting. I've had to pre-fetch and cache data because the content was enormous and the backend was out of my control. But I do agree that a user should be able to decide themselves how the device uses resources and I try to push this into every app. Give the user a choice if they feel inclined.

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

#24

Post by kevinbowman »

tjohns wrote: post #19
kevinbowman wrote: post #3

Given the "preload any data the user might need in the next 2-5 mins" statement, how do people suggest we handle live streaming of updates (eg commentary on a sports event)? Presumably websockets are ok as it's more of a "push" model for the network than a "poll" model?

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?

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

#25

Post by ianstallings »

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…

I disagree because there are fundamentals, highlighted by the author, that a lot of experienced mobile developers know already through trial and error that should be acknowledged up front.

For instance, doing single calls to APIs for multiple pieces of information instead of a bunch of calls. If you design for these up front, you can then head the problem off before it even becomes a problem. It's not premature because users expect it. They do notice network lag, they do notice battery usage, and they will give you one star on the app store or play store, etc. I've literally seen this play out in real life. It's no different than making sure your website loads quickly IMHO. You still have to do all those other things you listed to worry about, but this isn't to be glossed over and addressed when you realize people are noticing.

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

#26

Post by timthorn »

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…

Modern phone batteries last a fraction of the time they used to - you could get phones with 2 weeks life in the days before smartphones. We've got used to short lives but devs should aim to keep power demands down.

Radio power consumption is very significant. It could well be more than the screen takes - it's not just the RF amplification, but also the computation required to generate the modulated RF in the first place.

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

#27

Post by miratrix »

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…

The difference between DCH (the full-on high power state) and PCH (the lowest power, waiting-for-paging state) is about 2-orders of magnitude. Last time I measured, it was about ~100mA vs ~1mA (at ~3.7V) used by the radio. So, it's not couple of minutes of battery life, but rather _many_ hours of standby life instead. People usually aren't very happy when a fully charged phone dies overnight.

I've seen apps do some crazy things and it really has a significant effect in over-all battery life. A popular Android weather clock widget woke the phone up every minute to update the minute number on the graphics and updated the weather information every ~15 minutes (gps + radio!) which single handily crushed the standby battery life from multiple days to less than 8 hours.

Yes, I don't think _every_ decision should be based on minimizing the wake ups... but on the other hand, all developers should at least try to have as much understanding of the platforms that they're working on so that they know what trade-offs they're making with each feature they're adding.

I'm glad that Google has these videos available and that they're being picked up in places like HN.

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

#28

Post by mtrimpe »

ianstallings wrote: post #25
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…

I disagree because there are fundamentals, highlighted by the author, that a lot of experienced mobile developers know already through trial and error that should be acknowledged up front. For instance, doing single calls to APIs for multiple pieces of information instead of a bunch of calls. If you design for these up front, you can then head the problem off before it even becomes a problem. It's not premature becau…

Indeed. This isn't about premature optimization, but about preventing the equivalent of what I've seen happen when you give desktop developers GWT and get a public facing website with a 3 MB JavaScript app that polls a hard to generate 5k document every second just to check if a posted job has completed or not.

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

#30

Post by levosmetalo »

DougWebb wrote: post #11

The last thing I'd want is for my apps to each be downloading several MB of data they think I might need in the next few minutes. I can easily control how much battery life is remaining on my phone by plugging it in. I can't control how much of my data plan an app is using, except by uninstalling the app. Besides, in my experience the biggest drains on battery life aren't data transfers, they're (a) having the screen…

> (b) being slightly out of range of a cell tower, and constantly dropping and reacquiring a 3G connection. The latter turns my phone into a hand-warmer and chews up my power.

For this reason I'm pretty happy that my Android has an option to force 2G network for battery savings. Gives me 50% better battery life with no noticeable speed difference.

Post reply on HN