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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s