If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
highscalability.com
If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
1–10 of 77 posts
Re: If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
#2Actual title "If You're Programming A Cell Phone Like A Server You're Doing It Wrong" is a much more accurate statement, and a different topic.
On topic, this is why I prefer native (or at least non-webview) apps. The control over the connection and app lifecycle provides a better experience and better analytics.
Re: If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
#3Given 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?
Re: If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
#4of course, if you program for anything like you do for "real man hardware" - by which i mean targetting hardware and not a software platform e.g. a games console or a proper native app, part of the 'web stack' etc.... you never have a problem like this. :P
eventually you realise that C isn't fast enough and you can make it faster, but nobody else cares because they spunk clock cycles and bytes everywhere like they have billions of them (which of course they do... :D)
...and suddenly every language and platform is solving problems you never had because you just weren't a bad programmer to start with, and instead of solving your problems they are just tying your hands to prevent other people from shooting themselves in the feet.
Re: If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
#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 battery life for a better user experience, especially since my phone never gets below 20%.
Your users will be better served by you fixing bugs or adding features. Really, unless you're a huge team with a huge budget, there's other stuff to worry about in your app experience before "maximizing battery life" should be a responsibility you want to help the OS/device maker with.(If you're one of the lucky ones who has the time and money to do both, by all means, go nuts.)
Being conservative with resource usage is sound advice. Making battery usage the prime concern for most apps is overkill.
Games and other applications that you know users will have open for extended periods of time, and/or that are already eating up battery should give this issue some thought, everyone else, really, don't worry about it.
Re: If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
#6Given 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?
> 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...
Re: If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
#7Great article, made me explicitly aware of something I had at the back of mind as a web developer.
Another point that struck me is that when I briefly used Android more than a year ago, there was a nifty tool that showed which app drained what %-age of the battery. If I am having troubles with my battery life on Android, I am likely to uninstall (or not use) an app that consumes more than its fair share of the battery.
I haven't seen an equivalent statistics pane in iOS, I wonder whether Apple will introduce it at some point to encourage app developers to author more efficient apps.
Re: If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
#8> 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…
Maybe a good mobile app can determine its optimization/ux strategy depending on what level the battery is currently at. I am not sure whether apps can query for battery levels though.
Re: If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
#9Given 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?
> 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...
That's true, although I guess it's mostly listening as opposed to sending, which is possibly better? Although I realise there's probably some kind of "are you still there?" message from the cell tower.
Re: If You're Programming a Cell Phone Like a Server, You're Doing it Wrong
#10> 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…
Maybe a good mobile app can determine its optimization/ux strategy depending on what level the battery is currently at. I am not sure whether apps can query for battery levels though.
At least on iOS you can indeed. It's available from UIDevice.
And if you're doing something that sucks up battery, you should know about it and act accordingly.
If you're not doing heavy lifting, It's just not something you should have to think about as an app developer, there are so many other areas to focus on to keep users happy.
Apple has a few WWDC sessions that talk about it I think.
Here's what they have to say in their "performance tuning" section:
https://developer.apple.com/library/ios/documentation/iphone...