Key Concepts

 

Page (1)

No doubt, you are in a hurry to get started with Android application development.

Let’s get started.

But, before we dive into getting tools set up and starting in on actual programming, it is important that we “get on the same page” with respect to several high-level Android concepts.

Android Applications

An application is something that a user might install from the Play Store or otherwise download to their device.

That application should have some user interface, and it might have other code designed to work in the background (multi-tasking).

Assumption is that, you have some hands-on experience with Android devices, and therefore you are familiar with buttons like HOME and BACK, the built-in Settings application, the concept of a home screen and launcher, and so forth.

Page (2)

Programming Language

The vast majority of Android applications are written exclusively in Java.

However, there are other options:

  • You can write parts of the app in C/C++, for performance gains, porting over existing code bases, etc.
  • You can write an entire app in C/C++, mostly for games using OpenGL for 3D animations
  • You can write the guts of an app in HTML, CSS, and JavaScript, using tools to package that material into an Android application that can be distributed through the Play Store and similar venues.
  • And so on

Assumption is that, you know Java at this point.

You do not need to know everything about Java, as Java is vast. Rather, focus on:

  • Language fundamentals (flow control, etc.)
  • Classes and objects
  • Methods and data members
  • Public, private, and protected
  • Static and instance scope
  • Exceptions
  • Threads
  • Collections
  • Generics
  • File I/O
  • Reflection
  • Interfaces

Page (3)

Components

Android applications are written exclusively in Java.

But keep in mind that, you will not write a public static void main() method. Instead, you will create subclasses of some
Android-supplied base classes(like Activity, AppCompatActivity, etc) that define various application components.

In addition, you will create some metadata that tells Android about those subclasses.

There are four types of components :

  • Activities
  • Services
  • Content Providers
  • Broadcast Receivers

Activities :

The building block of the user interface is the activity.

You can think of an activity as being the Android analogue for the window or dialog in a desktop application, or
the page in a classic Web app.

It represents a chunk of your user interface and, in some cases, a discrete entry point into your app (i.e., a way for other apps to link to your app).

Normally, an activity will take up most of the screen, leaving space for some “chrome” bits like the clock, signal strength indicators, and so forth.

keyconcepts1

Page (4)

Services :

Services are designed to keep running, if needed, independent of any activity for a moderate period of time.

Activities are short-lived and can be shut down at any time, such as when the user presses the BACK button.

You might use a service for checking for updates to an RSS feed, or to play back music even if the controlling activity is no longer operating. You will also use services for scheduled tasks( akin to Linux “cron jobs”)

Content Providers :

Content providers provide a level of abstraction for any data stored on the device that is accessible by multiple applications.

If you want to store some data on device and that data is to be accessed by multiple apps, Content Providers comes into picture and they help us with this.

The Android development model encourages you to make your own data available to other applications, as well as to your own application — building a content provider lets you do that.

Page (5)

Broadcast Receivers :

The system, or applications, will send out broadcasts from time to time, for everything from the battery getting low, to when the screen turns off, to when connectivity changes from WiFi to mobile data.

A broadcast receiver – to listen for these broadcasts and respond accordingly.

Widgets, Containers, Resources, and Fragments

Most of the focus on Android application development is on the UI layer and activities.

Most Android activities use what is known as “the widget framework” for rendering their user interface, though you are welcome to use the 2D (Canvas) and 3D (OpenGL) APIs as well for more specialized GUIs.

In Android terms, a widget is the “micro” unit of user interface.

Fields, buttons, labels, lists, and so on are all widgets. Your activity’s UI, therefore, is made up of one or more of these widgets. For example, here we see label (TextView), field (EditText), and push-button (Button) widgets:

keyconcepts2

If you have more than one widget – you need to tell to Android how these widgets are going to be organized on the screen – we use container classes, referred to as Layout Managers.

Page (6)

Layout Managers – put your widgets in rows, columns, grid or more complex arrangements as needed.

To describe how the containers and widgets are connected, you will typically create a layout resource file.

Resources in Android refer to things like images, strings, raw files. UI layouts are another type of resource.

——–>
Sometimes, your UI will work across all sorts of devices: phones, tablets, televisions, etc. Sometimes, your UI will need to be tailored for different environments.
You will be able to put resources into resource sets that indicate under what circumstances those resources can be used (e.g., use these for normal-sized screens, but use those for larger screens).

Apps and Packages :

Given a bucket of source code and a basket of resources, the Android build tools will give you an application as a result. The application comes in the form of an APK file.

It is that APK file that you will upload to the Play Store or distribute by other means.

Each Android application has a package name, also referred to as an application ID.

package name —- application ID

A package name must fulfill three requirements:

  1. It must be a valid Java package name, as some Java source code will be generated by the Android build tools in this package.
  2. No two applications can exist on a device at the same time with the same application ID
  3. No two applications can be uploaded to the Play Store having the same application ID

When you create your Android project — the repository of that source code and those resources — you will declare what package name is to be used for your app.

Typically, you will pick a package name following the Java package name “reverse domain name” convention (e.g., com.commonsware.android.foo). That way, the domain name system ensures that your package name prefix (com.commonsware) is unique, and it is up to you to ensure that the rest of the package name distinguishes one of your apps from any other.

Page (7)

Android Devices :

There are well in excess of one billion Android devices in use today, representing thousands of different models from dozens of different manufacturers.

There are four dominant “form factors”:
• the phone
• the tablet
• the television (TV)
• the wearable (smart watches, Google Glass, etc.)
• airplane seat-back entertainment centers
• in-car navigation and entertainment devices
• and so on

Android has no built-in concept of a device being a “phone” or a “tablet” or a “TV”. Rather, Android distinguishes devices based on capabilities and features. So, you will not see an isPhone() method anywhere, though you can ask Android:

  • what is the screen size?
  • does the device have telephony capability? etc.

While building Android apps, rather than focusing on those four form factors, focus on what capabilities and features you need.

Page (8)

The Emulator :

To help fill in the gaps between the devices you have and the devices that are possible, the Android developer tools ship an emulator.

The emulator behaves like a piece of Android hardware, but it is a program you run on your development machine. You can use this emulator to emulate many different devices, with different screen sizes and Android OS versions, by creating one or more Android virtual devices, or AVDs.

OS Versions and API Levels :

Each new Android OS version adds more capabilities to the platform and more things that developers can do to exploit those capabilities.

To help us keep track of all the different OS versions that matter to us as developers, Android has API levels.

When you create an emulator AVD to test your app, you will indicate what API level that emulator should emulate.

When you distribute your app, you will indicate the oldest API level your app supports, so the app is not installed on older devices.

Page (9)

At the time of this writing, the API levels of significance to most Android developers are:
• API Level 16 (Android 4.1)
• API Level 17 (Android 4.2)
• API Level 19 (Android 4.4)
• API Level 21 (Android 5.0)
• API Level 22 (Android 5.1)
Here, “of significance” refers to API levels that have a reasonable number of Android devices — 5% or more, as reported by http://developer.android.com/about/dashboards/index.html

The latest production API level for most form factors is 23, representing Android 6.0.

Note that API Level 20 was used for the version of Android 4.4 running on the first generation Android Wear devices. Unless you are specifically developing apps for Wear, you will not be worrying much about API Level 20.

Dalvik :

In terms of Android, Dalvik is a virtual machine (VM).

The Dalvik VM is designed to work much like a Java VM, but optimized for embedded Linux environments.

So, what really goes on when somebody writes an Android application is:

  1. Developers write Java-syntax source code, leveraging class libraries published by the Android project and third parties.
  2. Developers compile the source code into Java VM bytecode, using the javac compiler that comes with the Java SDK.
  3. Developers translate the Java VM bytecode into Dalvik VM bytecode, which is packaged with other files into a ZIP archive with the .apk extension (the APK file).
  4. An Android device or emulator runs the APK file, causing the bytecode to be executed by an instance of a Dalvik VM.

From your standpoint, most of this is hidden by the build tools. You pour Java source code into the top, and the APK file comes out the bottom.

Note that Android is moving to a new runtime environment, called ART.

Page (10)

Processes and Threads :

When your application runs, it will do so in its own process.

Dalvik’s magic is making it possible for many processes to be running many Android applications at one time without consuming ridiculous amounts of RAM.

Android will also set up a batch of threads for running your app. The thread that your code will be executed upon, most of the time, is variously called the “main application thread” or the “UI thread”.

You don’t have to setup this main thread, it will be automatically setup for you. But you need to pay attention to what you do and do not do on that UI thread.

—– End of Chapter —-