Battery Bit

Posted: January 19, 2010 | Categories: Mobile Development

I'm going to try to coin a new phrase this afternoon in my Browser Development tricks session at Lotusphere 2010. I wanted to write about it here first, just in case it takes off and I get credit for the idea. The term is "Battery Bit" or, as I decided to try out early this morning, 'Battery Bit Time.' I'll explain what it means in a little bit (no pun intended).

I've been doing a lot of analysis of the wireless development space and have noticed a couple of trends. The biggest one is that developers have begun (mostly because of the iPhone) to completely disregard the network and the limited capabilities of mobile devices when they build their applications – especially their mobile web applications. We're dealing with small devices with limited processing capacity, limited memory and limited battery life, and developers are regularly building apps that no longer take that into consideration. They're treating these smartphones like they're desktop computers and that's causing problems for everyone.

AT&T is getting hammered by its customers and by the press for its network problems, but honestly (as an AT&T employee it's very important for me to point out here that the statements made in this post are my personal opinion and in no way reflect or represent the thoughts or opinions of my employer) it's the users & applications and their complete disregard for the network that are causing the problem.  The network is fine – and recent independent tests have concluded that it's faster and better than its competitors; it's how the network is being used that's creating all of the problems. I hope to get some time in the next couple of weeks to write more about this because I think I have some interesting insights into this – but we'll see if I can carve out the time to do that writing…

OK, now back to Battery Bit Time. As Mike Lazaridis (the founder of RIM) says, there's no way to get around Physics. Every bit of data that is delivered to and processed by a mobile device has an impact on the device battery life, the wireless network and the application user. Let's dig into this.

Every single bit (or byte, depending on how you look at this) of data transmitted to and/or from a mobile device affects the battery life for the device. If you send less data, you'll likely get better battery life out of your device. It's simple Physics (or as my father would say “it's Basic Physics”), every amount of work the device is asked to perform drains the battery. There's just no way around it. So, what happened to the days where mobile developers took that into account with their applications? It's gone. The iPhone is basically a small desktop device – even its browser refuses to identify itself as a mobile browser. It's regularly downloading full, desktop versions of web sites across a wireless network that shouldn't be processing so much data. Developers should always (and yes, I do mean always) send as little data as needed across the wireless network to provide the needed functionality for the application. No more than needed. There's no need for Flash, images, cool transitions or other glitz – just send the data the user needs and nothing else. Mobile web sites should be text-based, nothing more. If you do this Developers, you'll allow your users, through the simple application of Physics, to achieve better (longer) battery life for their mobile devices. Since Apple has decided we're not worthy of being able to swap out batteries (which all other mobile devices do) when we run out of power this becomes even more important for iPhone users.

As with every bit of data transmitted to/from a mobile device, every bit processed by the mobile device application (whether it be a browser or custom application) has an effect on the user. Every bit of work done by the processor further drains the battery. There's no way around the Physics of this. It's why as much processing as possible should be done by the back-end server, minimizing the work done by the client-side processor. When building mobile web sites or rich client applications, as cool as the technologies are that allow you to crunch data locally and create a very cool and compelling visual experience for your applications – it's not needed on a mobile device and does nothing but drain the battery and decrease the responsiveness of the application for the user. See my article about the BlackBerry Developer Conference application for more on this topic.

Taking this even further, every bit of data transmitted to/from a mobile device and every bit processed by the mobile device application increases the amount of time it takes to display the data on the screen for the user to access/act upon. Mobile devices and mobile applications provide immediacy – give me access to the things I need access to when I need access to them. Right? By building these complicated applications – web applications with all this funky, dynamic rich content or native applications with all of these fancy visual effects and transitions does nothing but drain the battery, make the processor do more work and delays the display of the data the mobile user is interested in seeing.

The BlackBerry Developer Conference application drove me crazy because of how long it made me wait to see the data I wanted just because they wanted to have a custom screen background image for every page and a cool fade transition between menu item selections. It's ridiculous. These are mobile devices with limited processing capability, limited battery capacity and limited network bandwidth available to it. Treat the mobile device it's a mobile device – give the users access to the information or data they need and do nothing more. Just because you can do all of these fancy screens, transitions and so on doesn't mean you should when you're dealing with a mobile device. Those types of things are cool for desktop browsers where you have relatively unlimited processing power and much bulkier networks, but they just don't belong on wireless apps.

If needed, one of the things the BlackBerry does that no other platform does (that I know of) is set an HTTP Header called 'Via' that identifies to the target server what connection was used to request the data. Using this, a developer could determine that the connection was made over a Wi-Fi network connection (the Via header isn't sent when connecting over a Wi-Fi connection) and send a richer version of a web site or an application's data when it knows it has a faster connection available to it. There's still the problem with processing and rendering time, but it does give the developer more options.

The wireless carriers are in the process of beefing up their networks (4G's coming soon) but at the same time, mobile devices are getting bigger processors and more memory (not more battery life sadly). Did you see that LG announced a smartphone recently with a 1 GHz processor? Ginormous processing capacity – shouldn't be used unless absolutely needed.

Battery Bit Time – The impact that the decisions Developers make have on mobile users and wireless network providers.  More bits (either processed or delivered) affects battery life and the amount of time the user waits to see the data they want to see.

Even though we'll soon have almost unlimited processing capacity and network bandwidth availability doesn't mean that it should be used the way it's being used.  If developers start taking this into account and get back to building mobile applications for mobile devices (instead of building desktop applications for mobile devices), then all of us will be much happier. We'll be able to use our devices for longer periods without recharging, we'll think our applications are more responsive and easier to use, and we'll probably stop complaining about our wireless network providers since there will now be more room for more users and more application data across their networks.
If you get a chance, swing by my session this afternoon, it's in Swan 5-6 at 3:30 (I'd originally reported it was at 3:00 PM – that was an error).

Next Post: Android Application Demo for Lotusphere

Previous Post: Android Emulator Access to LocalHost

Header image: Photo by ilgmyzin on Unsplash.