Fundamentals
Download 13.64 Kb.
|
- Navigate this page:
- Service
- Content Providers
Fundamentals | Android Tutorial for Beginners (Part 1)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. Directory: 2016 2016 -> Senate, No. 627 State of new jersey 217th legislature 2016 -> 2017 afoCo Landmark Scholarship Program 2016 -> Instructions for the Preparation of Camera-Ready Contributions to the Conference Proceedings 2016 -> Strategic Plan South Sudan Country Office Context 2016 -> Original: English 2016 -> Step student Scholarships for Year 10-13 2016 -> Resolution 2016 -> American bar association adopted by the house of delegates Download 13.64 Kb. Share with your friends:
|