Friday, July 10, 2009

Android - a snapshot

Recently , I had a chance to explore Android (as an interesting hobby :)). That exploration resulted in this snapshot:

# Platform

• Android is an open source software stack – It includes: OS, Middleware, Key applications, API libraries for writing mobile applications

• Android supports most of Java platform except AWT & Swing

• Following things makes up Android :

o A hardware reference design that describes the capabilities required for any mobile device to support the software stack

o A Linux OS Kernel 2.6 that provides low level interface (device drivers)
o Open source libraries for app. development including SQLite, WebKit, OpenGL & a media manager

o A runtime to execute & host Android applications including Dalvik virtual machine (Android’s own optimized JVM)

o An app. framework

o An UI framework to host & launch applications

o Pre-installed applications

o A SDK with tools, plug-ins & documentation

• Android phones will comes with pre-installed applications that include :

o A Gmail compatible email client but not limited to
o A SMS management application
o A full PIM suite
o A fully featured Google Maps application
o A webkit based mobile browser
o An instant messaging client
o A music player and picture viewer
o The Android Marketplace client for downloading thied-party Android applications.
o The Amazon MP3 store client for purchasing DRM free music.

• APIs allows access to hardware access, location based services, support for background services, map-based devices, relational databases, interdevice peer-to-peer messaging, 2D/3D graphics

• Windows Mobile & Apple’s iPhone are based on proprietory OS; Android offers an open development environment built on open source Linux kernel

• It is supported by Open Handset Alliance and designed to run on any handset that meets the requirements

• Central feature of Android is that one application can make use of the elements of the other application. For this happen, Android applications will not have a single entry point for every thing in the application.

• Intents, Activities, Views, Service, BroadcastReceiver, ContentProvider – important things in Android development – Activitie & View objects are Front end – Intents & Services are Back end



# Building Blocks

•INTENTS - Intent is a break through concept behind Android – Applications expresses it’s Intents to Android platform & it will take care delegating it to an appropriate application. By that way, we can re-use the existing applications. –An Intent is Android’s method for relaying certain info from one Activity to another activity – It is the message passed between the Activities - When an Activity sends an Intent to Android Intent Resolver, it will look for the matching Activity and calls that Activity – The 3 core components of an application: activities, services & broadcast receivers are activated through the messages called “intents”. - Intent Messaging is a facility for late runtime binding of the components within a same application or different applications. – Android owns the responsibility of finding the appropriate activity, service or set of Broadcast receivers to respond to an Intent, instantiating them if necessary.

An Intent receipient can be a Activity, Service or a BroadcastReceiver.

Intent Object – It is a bundle of information – It contains:

1.Information of interest to the component that receives the intent (Action to be taken / Data to act on)

2.Information of interest to Android system (like Category of compoent that should handle it, instrtuctions on how to launch the target activity).
Basically it will have

A.Component name – Name of the component that should handle the intent. If
not specified, then Android will use “Intent Resolution” to identify the

B.Action – Name of the action to be performed

C.Data & MIME type of Data


E.Extras – Key-value pairs for additional info that should be delivered to
the hanlding component


There are two types of Intents:

o Activity Action Intents

Intents used to call the Activities outside our application. Only one Activity can handle that Intent

o Broadcast Intents

Intents that will be handled by Multiple Activities

There are some pre-defined set of Intents under these 2 categories


Intent Resolution

From another perspective, Intents are classified into 2 categories: Explicit & Implicit

Explicit – Component name is specified – used to call the activities within the application

Implicit – No target component name specified – Used mainly to activate the components in other applications

# If a component does not have any intent filter, it can receive only explicit intents. A component with filters can receive both explicit & implicit intents.

Intent Resolution rules:

1. If the action is not specified in the IntentFilter, it will then match any action coming from an Intent

2. An IntentFilter can have additional categories beyond what an Intent specifies to match, but must have at least what the Intent specifies. an IntentFilter with no categories will only match an Intent with no categories

So first, action and category specifications have to be a match. It’s important to understand that data is optional. You can work with action and category alone

3. If scheme is present and type is NOT present, Intents with any type will match
4. If type is present and scheme is NOT present, Intents with any scheme will match
5. If neither scheme or type are present, only Intents with neither scheme or type will match
6. If an authority is specified, a scheme must also be specified
7. If a path is specified, a scheme and authority must also be specified

Intent Filters

Activities, Services & Broadcast Receivers should have one or more intent filters to inform the system on which implict intents they can handle. Explict intent will be always delivered to target, irrespective of what it contains. Filter is not consulted. Implicit intent is delivered to a component only if it can pass through one of the component’s filters.

Intent Filters are available in AndroidManifest.xml



•ACTIVITIES – It is anologous to a screen. It will have View objects (Basically a View refers a control / field in a screen) – Most of the code that we write for Android will run in the context of an Activity - When an Activity is not actively running, it will be killed by the OS to conserve the memory – An application can have multiple Activities. - Life cycle method of an activity:

OnCreate, OnStart, OnRestart, OnResume, OnPause, OnStop, OnDestroy

An Activity started with StartActivity will become independent and will not send any feedback to parent. Activities started with startActivityForResult can trigger event in parent activity.

We can get result from a sub activity by calling setResult method. The intent that is returned can have URI and other extra info.


•SERVICES – Analogous to daemons / windows services – They will always run in the background until the handset is switched off – usually they will not have UI. They are of 2 types : Local service & Remote service

A Service is intended to serve 2 purposes: Running a background task or exposing a remotable object for inter-process communication.


•BROADCAST RECEIVERS – They respond to requests for service from another application – An Activity or Service provides access to other applications for its functionality through Intent Receivers. The requesting activity will leave it to Android framework to figure out which application should receive it & which should act on it.

•They can register either for global events or for intents.
•We cannot perform Asynchronous operations within BroadcastReceiver
•We can only start a Service. We cannot Bind a Service
•onReceive handler must be completed within 5 seconds
•Typically they are meant for updating content, launching services, updating an UI activity, make notifications using Notification manager
•Actually when broadcasting intents, the same Intent concept is used. Only difference is it is happening in the background. Also, a Broadcasted Intent cannot call an Activity. An Activity can be called only through a Broadcast receiver.


•CONTENT PROVIDERS – Android allows exposing data sources through a REST like abstraction called “Content Provider”. They provide a layer of Abstraction on a data source. These are created to share Data with other services / activities. A content provider uses URI to fullfill the requests for data from other activities. The Activities / Services may not even know which Content Provider they are using. When an Activity / Service issues a request against a URI, the OS will look for the applications that are registered against that URI and activites it. If more than one application registered against a particular URI, OS will ask user to choose the content provider. ContentProvider is used to shared data b between different application

•Content Providers exhibits characterictics of web services. Output of the URL of the content provider is not a typed data

•URI calls to content providers returns cursor

•Planning for a content provider involves: Planning for Database, URI, column names,; Extend from ContentProvider ; Implement query, insert, update, delete & getType methods; Register provider in the manifest file.

•RESOURCES – They are used to accommodate values which can be change later without re-deploying the application. Ex: XML files, Strings, Colors, Bitmaps etc. This info will be updated in the R.Java file. Irrespective of the no. of resource files, there will be only one R.Java file.

Different resource types are: String,Color,Dimention,Image,Color Drawable,XML Files,Raw Resources,Raw Assets, Layout.

Intents & URIs allows Android to provide Flexibility / loose coupling.

•Three types of components can register to be a Intent Handler. They are : Activities, BroadcastReceiver & Services.

•The elements of Intent are: Action, Data, Category, Type, and Component & Extras.

•Android SDK uses XML extensively to define UI layouts. All XML files are compiled to binary files, before they are placed in the device.



Different options available to store & retrieve data are: Preferences, Files, SQLite & Network

Shared Preferences : For storing UI state, user preferences / application settings, key-value pairs

Files : can be from internal / external media

Content Provider : for sharing data