This
is Part 1 of a series of articles I plan to write to simplify the new
paradigms introduced by the Android platform for developers.
The
part 1 will only define and introduce the fundamental building blocks
of Android. Later articles will provide sample code focusing on one
aspect at a time, more to drive home to concept than to show any great
programming skills.
From a developer's perspective, the fundamental building blocks / components of Android are:
1. Activities
2. Services
3. Broadcast Receivers
4. Content Providers.
The means of communication between the above mentioned components is through
1. Intents
2. Intent Filters
The User Interface elements are by using what are called:
1. Views
2. Notifications
Now,
having broadly classified the basics, I would like to give a simple
definition for each of them, before we can appreciate the need for each
of them.
Activity is
the basic building block of every visible android application. It
provides the means to render a UI. Every screen in an application is an
activity by itself. Though they work together to present an application
sequence, each activity is an independent entity.
Service is
another building block of android applications which does not provide a
UI. It is a program that can run in the background for an indefinite
period.
Broadcast Receiver is yet another type of component that can receive and respond to any broadcast announcements.
Content Providers are a separate league of components that expose a specific set of data to applications.
While
the understanding and knowledge of these four components is good enough
to start development, the knowledge of the means of communication
between the components is also essential. The platform designers have
introduced a new conpect of communication through intents and intent filters.
Intents are
messages that are passed between components. So, is it equivalent to
parameters passed to API calls? Yes, it is close to that. However, the
fundamental differences between API calls and intents' way of invoking
components is
1. API calls are synchronous while intent-based invocation is asynchronous (mostly)
2. API calls are bound at compile time while intent-based calls are run-time bound (mostly)
It is these two differences that take Android platform to a different league.
NOTE: Intents can be made to work exactly like API calls by using what are called explicit intents, which will be explained later. But more often than not, implicit intents are the way to go and that is what is explained here.
One component that wants to invoke another has to only express its' "intent"
to do a job. And any other component that exists and has claimed that
it can do such a job through "intent-filters", is invoked by the android
platform to accomplish the job. This means, both the components are not
aware of each other's existence and can still work together to give
the desired result for the end-user.
This
dotted line connection between components is achieved through the
combination of intents, intent-filters and the android platform.
This leads to huge possibilities like:
1. Mix and match or rather plug and play of components at runtime
2. Replacing the inbuilt android applications with custom developed applications
3. Component level reuse within and across applications
4. Service orientation to the most granular level, if I may say
Now that the concept of intent has been introduced, let me get down to a more formal definition of Intent.
Intent
is a bundle of information, a passive data structure that holds an
abstract description of the operation to be performed. (or in the case
of broadcasts, a description of an event that has happened and is being
announced).
There
are 2 types of intents which I intend to detail in the next part of
this series. Before winding up part 1, I would finally also give you a
formal definition of Intent filters.
Intent
filters are the means through which a component advertizes its own
capabilities to handle specific job/operations to the android platform.
No comments:
Post a Comment