Android 101: The Basics

right now in the world of software development, writing mobile apps has become very popular. there's never been more choice in frameworks and the amount of smartphones available. while writing for ios has been popular, it's android that has caught the attention of java developers. over the next few articles, i'll be taking you through some steps to get started with android. but before we get coding, let's take a look at some of the core principles of android development.

what is android?

the following diagram, taken from the online developer guide, shows the architecture of the android operating system:

the android is built on top of a linux kernel, for managing the typical operating system services. the android runtime is based on the dalvik virtual machine (subject of a lot of attention from oracle these days). dalvik is a slimmed down variation of the java virtual machine, which builds on the apache harmony java implementation. no javame, swing or awt components are provided; instead android provides it's own library of components.

there are a number of native libraries available, all written in c/c++. surface manager deals with access to the display subsystem, while the media libraries provide playback for most popular audio and video formats.

it's the application framework that will interest most developers as this provides the api and services that you need to create quality mobile applications for android.

the core android concepts

as mentioned above, the application framework has everything that a developer needs for creating apps. here's a rundown on the main concepts:

• activities
  a activity is a user interface screen. one application can have one or more activities across the application's execution. each activity that you create will be given it's own window to draw in. each screen that you create will be a subclass of activity.
• services
  a service runs as a background task, and has no visual representation. like activities, services run on the main application process thread, but will usually spawn off other threads to run their tasks without affecting other applications running. the typical example for a service is a music player, where you play songs from your playlist while doing other things on your phone. services extend the service base class.
• content providers
  a content provider is a custom api that allows read and write access to a certain data set. this then allows different applications to share data between each other. content providers subclass the contentprovider base class which provides a standard interface for accessing data. applications will not call the contentprovider implementation directly, but will instead go through the contentresolver object, which can access any contentprovider.
• intents
  an intent is a specific action such as sending an email, playing a song or calling a contact.
• resources
  the final piece of the application jigsaw is resources - images, text or non-coded information that you application needs to access or display.

activity lifecycle

the following diagram illustrates the different states for an activity through it's lifecycle:

while you cannot control moving the activity between states, you will get notified as the state changes through the onx() methods like onstart(), onresume() etc. you can override these methods to get your application to react appropriately to these state changes.

next up

now that you have a better understanding of what makes up an android application, we're ready to get going with some real development. the next article will bring you through your system setup.