Skip to main content

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



Popular posts from this blog

Lambda Architecture on Microsoft Azure

Gone are those days when Enterprises will wait for hours and days to look at the dashboards based on the old, stale data. In this fast world of BYOD, fitness gears and flooding of other devices, it is becoming super important  to derive out “actionable” information from huge volume of data / noise that is generated from these devices or any other data sources and act proactively on them  in real-time, to stay competitive. At the same time, the need for having dashboards and other analytical capabilities based on the quality, cleansed, processed data still very much exists. With the emergence of more data types and need to handle huge volume, shift is happening from the conventional data warehouse practice to cloud based data processing & management capabilities where high volume batch processing is possible at the optimized cost. Business scenarios demanding the need to process the data in real-time    More  

Heterogeneous Cloud Integration

Heterogeneous integration is common scenario in the Enterprises where their IT portfolio is based on heterogeneous platforms. Various solution approaches such as message broker, messaging middleware, SOA – service based integration were employed to address heterogeneous integration challenges.   These solution approaches were good when the integration happens on premise, with in the data centers of an Enterprise. Problem here is non-availability of “elasticity”.   With the Enterprises started leveraging cloud platforms extensively for various solution aspects such as elastic computing, storage, it opens new capabilities that can be leveraged for heterogeneous integration. Also, similar to existing on premise scenario, Enterprises are also leveraging multiple cloud platforms to address their business needs. This scenario will pose same integration challenges as those that were faced within on premise datacenters   Within datacenters / on premise, integration product

SharePoint 2013 Architectural Trade-Offs

When planning for deploying SharePoint 2013 based Enterprise workloads, it should be done with the consideration / awareness of impact of various architectural decisions what we make. As SharePoint 2013 is a flexible platform providing lots of options in terms of configuration of the existing OOB features and development of custom development solutions to address specific business functional needs, care should be taken when making a particular decision and its impact on overall solution. Even though SharePoint is a matured product, the effectiveness of various business capabilities such as Enterprise Social, Enterprise Search, BI, Document Management, Web Content Management, and Enterprise Content Management that will be delivered based on it, in terms of addressing the business requirements depends on architecture planning. Effectiveness here means performance, security, up-time and other architectural qualities like Scalability, Reliability etc. more ...