Once you have set up the Android SDK and AVD in your system, I would like to take some time and provide you with a little description of the Android Platform so that a read-through of it may give you a basic idea of it’s features and fundamentals.
- Android runs on Linux i.e. it is based on Linux Operating System, more specifically Linux 2.6
- It makes use of a virtual machine named Dalvik Virtual Machine, which in particular is optimized for mobile devices. It is analogous to the Java Virtual Machine with which most Java programmers must already be familiar.
- It makes use of embedded version of OpenGL named OpenGL ES for graphical purposes.
- It uses SQLite for storage of data in databases. Web Developers can find analogy in the fact that PHP uses MySQL and ASP.NET uses Microsoft SQL Server.
- For browsing purposes it uses the open-source WebKit Engine.
ABOUT ANDROID APPLICATIONS
- As most of you may already know Android applications are written in Java programming language.
- The Android API helps separate layout from functionalities. The layout is usually written in XML, however many programmers also write it in Java.
- Each application runs in it’s own Linux process just like different processes run in a computer’s Operating System.
- All applications must possess components, a manifest file and resources.
- There are four major components of an Android Application namely Activities, Services, Content Providers, Broadcast Receivers.
- A manifest file named “AndroidManifest.xml” exactly, is required for each application. This serves the purpose of giving a clear picture to the Android system what your application is all about, what permissions it requires and other related details. I will cover the Android Manifest file and it’s importance in detail in a later post.
- Resources may consist of xml scripts, colors, shapes, pictures and any other things that your application makes use of.
Any single screen with a user interface is an activity i.e. every screen a user sees is a separate activity. For instance, when you check your text/multimedia messages, the screen that lists the sms/mms conversations, is an activity. When you click on one and enter the conversation screen, that is another activity. Practically, every single application that you come across will have more than one activity. The user can navigate from one activity to another while using the application.
The question now arises, how does the flow of control work in a multi-activity application? Well, it is the responsibility of the Application Programmer to decide how and when will a user be taken from one particular activity to another. Remember that when switching activities, the current activity is paused and the next activity is brought to the front.
Also if you have used an Android device before, you must know that on pressing the “back” key on the device, the user is brought to the screen/activity he/she was on immediately before coming to the current activity. Quite intuitively, it is done using a stack data structure. This stack is known as Back Stack in Android.
Services are programs that perform long-running operations in the background. Since they run in the background, they obviously do not contain a user interface. The most striking feature of a service is that it runs independently of the activity that created it. In simple terms it means that on closing the activity that created a particular service, the service keeps running and does not close with the activity. Another very useful feature of services is that, if allowed, any application can bind to a service and manipulate it.
Now, if you have used an Android device before, you can definitely think of a few services that you have come across. One of them is playing music. When you go to the music player, queue your favorite tracks and then close the music player the music continues to play. This is a very simple day-to-day example of a service.
Have you ever thought how data can be shared between applications in an Android device? Since each Android Application runs in it’s own process, any and every data to be shared need to be centrally located, so that each application may have access to it. That is exactly what is achieved using Content Providers. Android already contains a number of providers like Contacts, Calls, Media etc. that applications can get access to. An application can also create a provider so that other applications can share it’s data and perform whatever tasks they need to.
Data is stored as a simple table in a Database Model. Data from a Content Provider is accessed with the help of a public URI (Uniform Resource Identifier). A URI uniquely identifies a particular data set.
Broadcast Receiver is a component that receives broadcasts from the Android System. A broadcast can be considered to be a system wide announcement of the occurrence of an event. Any and every applications programmed to receive to a particular type of broadcast, will trigger off as soon as a broadcast occurs.
Applications can also create their own broadcasts such that other applications might receive it and execute a specific set of instructions. Just like services, Broadcast Receivers do not have a user interface. You must have seen that a dialog appears on your device whenever the battery is low. That is a classic example of a broadcast receiver. When the battery is below a certain level, a broadcast is initiated by the Android system. The inbuilt applications receive this broadcast and show a dialog box informing you of the same.
With this, we come to the end of a thorough introduction and we are now ready to plunge ourselves into some real-time Android Application Programming. In my next post I will brief you about the Eclipse IDE and show you how to create your first Android Application