My first smartphone was an Android phone, the HTC Desire to be more specific. I installed many apps on it that truly utilized multitasking in such a seamless way that I never paid any attention to it. I took the superior multitasking for granted.
A few months ago, when my Samsung Omnia 7 (Windows Phone 7) got the WP7.5 Mango update, I was excited to get multitasking on it! I installed WhatsApp and was shocked! Why did it have to load the new messages after I opened the app when I just received a notification of that message? It made no sense to me. I blamed it on the fact that the app was still in beta.
After going to a developer conference hosted by Microsoft, they explained how exactly WP7 dealt with multitasking. They explained about how the app is “tombstoned” when it is not the active app, which is basically freezing the state of the app rather than quitting it. Android, on the other hand, kept my apps running in the background unless they were specifically closed.
I didn’t dig too much into it though, since my Android was still my main phone. Then one day, my HTC Desire faced an unfortunate accident that killed it. I borrowed an old iPhone 3GS from a friend as a temporary smartphone to use until Q2 when HTC releases its next hero phone. And now this iPhone has become my main phone.
So I install WhatsApp, Facebook, Twitter and all the other social apps I use. I set them all up to give me live notifications of everything I care to know about. So I get a WhatsApp notification and I click it… WhatsApp is connecting… WhatsApp just connected… WhatsApp just received the new messages and can finally be read. How long did that take? Around 3 seconds between the app loading and then the data loading. How long would that take on my Desire? Instant, thanks to the power of true multitasking! I noticed that was the case with all my apps and it’s really been driving me crazy.
Now for the slightly more technical side of the article, here’s a brief conceptual explanation of how multitasking works on WP7 and iPhone VS Android:
On iPhone and WP7 (terms and fine details slightly defer, but concept is the same):
An app basically has 2 states: active and suspended. When it’s active, of course, the app is in the foreground and is what’s running. When it’s suspended, the app is enters a frozen state where nothing is happening, but can easily be thawed out of this frozen state to go back to exactly how it was. Of course, there are pausing and resuming events, where the app is told that it is about to be frozen or that it is about to be thawed for use again, so run whatever you need to to get ready.
So you’d wonder, “how can I send a notification to my app if it isn’t running?” Well, you don’t actually send it yourself! What you do is basically send the notification to Apple/Microsoft and tell them what phone to send the notification to. When the phone gets the notification, your app is not actually aware of the notification. Clicking this notification will only tell you phone that the user clicked a notification of type x (example: a private message notification, so launch the app at the inbox).
Big example: Instant messaging client:
Method 1: User directly connects to IM server:
In this case, the user has a direct connection to the IM server and gets his/her messages directly. When the user navigates away from this app, he/she is disconnected (perhaps you, the developer, would like to run some code to disconnect the user in a safer manner or save some information). While the app is suspended, the user will not receive any messages. Running the app again, the app should try and reconnect to the server and retrieve new messages.
Method 2: User connects to app server, which connects to IM server:
The user sends their login information to your server. Your server connects and acts as a sort of BNC; it connects as the user and relays all the messages to the user. In this method, the user will never get disconnected and will always get live notifications, whether the app is running or not. Of course, this makes it a lot more costly for you to have the server running at all times relaying the messages. The app becomes slightly simpler on pause and resume. On pause, app notifies the server of the disconnect, so it can start pushing the notifications as phone notifications. On resume, the app reconnects to the server and requests that the messages are sent in to the app now instead.
The app can run in the background keeping an active connection to the IM server. In the background, the user can get the notification and the app will automatically be updated with the information.
In conclusion, life is much simpler on the Android side of things, huh? So it seems, but the can also slow down the OS, drain the battery and cause a lot more malware! Of course, when efficiently used, this is a very effective and powerful platform for multitasking!