View Single Post
Old 10-16-2007, 02:50 PM   #2
Mark Rejhon
Retired BBF Moderator
 
Mark Rejhon's Avatar
 
Join Date: Aug 2004
Location: Ottawa, Ontario, Canada
Model: Bold
Carrier: Rogers
Posts: 4,870
Default

Programmer comments

(technical notes, skip this if you're not a programmer). There is a "Battery Save Mode While Idle" in JiveTalk. These optimizations to run very well with battery power may go down to a simple matter of minimizing CPU and network use intelligently. Let me speculate it's probably batching up transmissions into more infrequent transmissions: It often takes the same amount of power to transmit one 512-byte packet as a 10-byte packet. Instead of transmitting 50 packets, it transmits one packet, and when running in background, it could ignore transmitting unnecessary idle/active/away/etc transmissions and batches them up into more occasional, intermittent prioritized transmissions while JiveTalk is running in background mode, while pushing incoming messages quickly in more immediate transmissions. (especially if there's a tiny delay between packets, that might prevent the OS from batching then together automatically - and even so, one could save the OS the CPU trouble of doing so). For old WebMessenger software which I used a lot in the past, it automatically went into a battery miser mode while running in background (skipped contact list updates such as signons/signoffs, and probably used a server-side pounce signalling since those require immediate notifications) and updated them when the chat client was brought to foreground. I think JiveTalk goes into a similiar battery miser mode when it's idling for 5 minutes, but instead of forcing a list update, it probably intermittently updates it and probably requests an immediate update when stopping idling. This is probably the best way, as I haven't seen the list "suddenly catch up" in JiveTalk so it must be doing it even more intelligently than WebMessenger did. For a big buddy list of 200 people, this makes a huge difference because all those contact list updates require transmissions, which requires large amounts of battery power when 200 people sign on and off all day long. (Remember it takes up to 2 watts of electricity from cellphone battery to transmit a packet in a weak-reception area on a GSM850 or GSM900 network) to transmit a data packet. It is possible to make a chat software waste less power in data transmissions, simply by mere optimization of merging as many chat-signalling messages as possible into more infrequent packets while idling, and running all chat networks over a single socket connection. Theoretically, you could transmit low-priority buddy list updates only once every few minutes while in background, and bringing software to foreground automatically forces a quick update of low-priority online/offline/away/back notifications. Server can even be designed to "push" the incoming chat messages. Even if it's non-push, an idling EDGE / GPRS connection actually uses fairly little power, and it's possible for a modern BlackBerry have a nonstop idling connection for a long period of time - it's the transmissions that gobble power. While I don't know how JiveTalk optimized for low battery power usage, the improved performance is one of them - because it's spending less CPU time trying to render the user interface. A startling example is when IM+ logs onto a chat network - it adds the buddies one by one, while JiveTalk adds all 200 buddies nearly instantaneously to the list (after a very short pause on a blank buddy screen). JiveTalk uses a lot less CPU per buddy status change away/online/offline. Whereas, IM+ tends to use a fraction of a second worth of CPU when this happen. This isn't a problem for small buddy lists, but when you've got 200 buddies logged on 24/7, one really need to optimize the low priority stuff such as signon/signoff/away/busy/etc signalling to use as little CPU and network bandwidth as possible. It seems JiveTalk does this better, and probably batch-processing plays a role. For example, comparing a Pounce list with Buddy list, would require a battery-efficient search algorithm, and a signon/signoff notification probably shouldn't update the graphics if the software is running in the background, and so on. JiveTalk probably uses a lot of techniques to improve efficiency by optimization to reduce as much CPU and network use as possible, while making high-priority stuff (i.e. incoming messages) immediate. Most developers of mobile chat software do not test with large buddy lists often enough, but JiveTalk clearly designed the software to be efficient with big buddy lists. And clearly programmed by programmers that obviously love their BlackBerries, and have BlackBerries as their personal non-work phones from even before they got hired by BeeJive (or started BeeJive).
__________________
Thanks,
Mark Rejhon
Author of XMPP extension XEP-0301:
www.xmpp.org/extensions/xep-0301.html - specification
www.realjabber.org - open source

Last edited by Mark Rejhon; 10-16-2007 at 03:19 PM..
Offline   Reply With Quote