iPhone vs Android – Multitasking on small devices with no swap space (Valid for 2009 and early 2010)


Disclaimers are important part of blogs I must say. I mean, imagine if I write something like, iPhone devices dont support multitasking. But actually Apple add’s the support in a very subtle manner. My blog becomes useless then right ? Well. enuf with the disclaimer value proposition.  Lets get on with the comparison.

iPhone (and iPad for the rest of the blog) are single view, single document applications. Either the app is alive or killed. Simple. The multitasking is for applications that Apple ships. They dont allow third party applications to multitask. Mainly since there is no swap space

As for Android, application state is saved and retrieved when requested. The state (including the view) is saved in Bundles. In Android applications continue to live in the background, and are killed under memory pressure, in  least recently used order. But even after they are killed if the application is relaunched, the Bundle is used to provide seamless launch.

On Android, the philosophy is “all applications are equal”, contrary to Apple, “I have more privilege as compared to third party”.

So in short Android wins. Beyond the claims of Apple “multitasking cannot be done on devices with no swap space and less memory”.. Yeah Right!!!

Requirement to Design (In context with Android BroadCast Receiver and Service)


One particular skill that a developer/architect develops over time is the skill to convert a requirement to a design. More rare than often the very same guys dont realize the importance of “basic fundamentals”. The only difference between a architect and a developer (in simple words) is that, a architect knows his basics really well. He knows pointers, bit manipulations, data strucutres. For Android he knows Activities, Content Providers, Service, Intents and Broadcast Listeners really well. He has written small snippets of code for these just like he did when we was in college (you know the fibonacci series, bubble sorts and bit manipulations). It takes a few interviews to flunk and get write.

So guys, get your basics right. Write small snippets of code to get the fundamentals right. As a very close friend of my once said, “Dude, slow down. we are not going to learn the singleton pattern if we are in a hurry, lets read every sentence of GoF one by one, get it right and then move on. If we dont get it, lets take a break, have tea/water, get our brains full of water and oxygen and start from where we stop.”

So true I would say. I keep telling myself daily, slow down dude.. Dont be a in hurry… Get it right. Take time.. 🙂

Lets move on. So basics on Android. I’ll cover the Android Broadcast Receivers now. A broadcast receiver basically is a background process (with no UI) and is waiting for broadcast announcements to arrive. Ideally broadcast receivers do notificaitons, light weight actions.  Now people focus here. Broadcast Receivers do light weight actions, create a activity or send notifications. Notifications are of 3 types update a icon on the task bar, turn on/off LED’s on the phone, create sounds/lights and vibrations. NotificationManager manages all notification to the user (the phone user). Now, light weight here means, if you dont get your stuff done on a broadcast receiver within 10 seconds the android process manager will put your process in back ground for killing (if the phone is low on memory).

🙂 I know what you are thinking, what if I want a heavy weight process done. How do I acheive it in a broadcast receiver. Well, if you have read this blog, then you should ask this question. Put your comments. I’ll answer it.

Naah!!! Just kidding. You basically need to create a service in that case. Services generally are long lived and are not killed until the RAM is really low. But after the service is killed Android may remember that the service “wanted” to stay alive, and relaunch it when there is more RAM available.

Now you ask, what if I want a service to stay alive longer and not get killed at all. Well in that case u make it a foreground service, but you have to do the following to let android allow you to keep a service running

1) Create a notification to show the user that the service is running

2) Provide the user a way to kill the service

Kinda giving the user the power to decide and on purpose have a service running long.

In short, with a broadcast receiver and service, you can create a wide range of background running applications. Just check out the variety of stuff provided by Android, just in their 1.0 release.

– Music runs in the background (after u exit from the song selector)

– Calender raises a alarm at just the right time.

– Downloading a file is a service

– Email service receives a alarm regularly to check for new email.

VmWare 2.0, Web Client reports “Error:Cannot open the disk ‘/var/lib/vmware/Virtual Machines/ ‘ or one of the snapshot disks it depends on.”


While using vmware 2.0 server. Once every few weeks my vmware client (web client) reports “Error:Cannot open the disk ‘/var/lib/vmware/Virtual Machines/ ‘ or one of the snapshot disks it depends on.” when I try to start my virtual machine.

Fix took me time to search, felt it would be useful to know here. Opened the /var/lib/vmware/Virtual Machines/virtualmachine directory and deleted (moved, just to be sure) the lck files and log files. And that fixed it. Simple :).