Let’s start with most basic android concepts which some of us may already know.
An Android Application is something that a user might install from the Google Play Store or otherwise download to their device from any remote location over internet/ even from their local systems as well. This application should have some user interface, and it might have some other code designed to work in the background of application. Here I am assuming 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, the concept of a home screen and launcher, and so forth. If you have never used an Android device, I would like to strongly encourage you to get one and play with the device and apps which come installed on it/ or download from app store. This will help you in understanding what you will be building after so much hard work.
Allowed Programming Languages
The vast majority of Android applications are written exclusively in Java. However, there are other options as well:
- You can write parts of the app in C/C++. It is usually done for performance gains or porting over existing application’s code bases etc.
- You can write an entire applications in C/C++. It is mostly done for games using OpenGL for 3D animations.
But still the fact is that Java is most used and popular language to build android applications. If you want to deep dive into android app development, then there is no excuse for not learning java.
Major Android Components
Remember when you started learning java, your first program was ‘Hello World‘ application. You wrote a
main() method and some print statement; then some magic happened and output was written in console. Similarly, when you entered into web programming area, normally you will learn/write the http servlet first. You extend a class and write some code in it; and then something passes control to your servlet and it start executing.
Android takes the second approach i.e. you extend some specific classes and define your configuration in some XML file and you are good to start your first android app. The subclasses you create, by extending base classes supplied by Android, are called components. Below are major 4 components you should know before hand:
The major building block of the user interface is called activity. You can think of an activity as an user interface as you see in classic windows application. Just like in windows where an application takes most of screen apart from toolbar strip, activity also leave area on mobile device screen only for strip on top contain device clock, signal strength indicators etc. Remember this term, you will be using it in every step of your app development.
Activities are short-lived and can be shut down at any time, such as when the user presses the BACK button or HOME button. Services, on the other hand, are designed to keep running, if needed, independent of any activity inside application, for a short period of time. You might use a service for checking for updates to an RSS feed, or to play back music even if the controlling activity (i.e. media player) is no longer operating on front screen.
3) Content Providers
Content providers provide a level of abstraction for any data stored on the device that is accessible by ‘multiple’ applications. The Android development model encourages you to make your own data available to other applications. Building a content provider lets you do that, while maintaining a degree of control over how your data gets accessed by other apps on same device.
4) Broadcast Receivers
The system, and/or other apps, will send out broadcasts/notifications from time to time for everything relevant e.g. for the battery is getting low, the screen turns off OR connectivity changes from WiFi to mobile data etc. A broadcast receiver in your application will be able to listen for these broadcasts/notifications and respond accordingly the way you want.
Key Terms Used in Android Development
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. You can think of all text boxes, drop downs and other HTML UI elements in normal webpage. In Android, they are called widgets. Easy to remember.
b) Containers/ Layout Managers
If you have more than one widget — which is fairly typical — you will need to tell Android how those widgets are organized on the screen. To do this, you will use various container classes referred to as ‘layout managers’. These will let you put things in rows, columns, or more complex arrangements as needed. To describe how the containers and widgets are connected, you will typically create a layout resource file and put in project’s resource folder from where android pick it up directly and render the whole UI for you automatically.
In more familiar terms, they are equivalent to DIVs, SPANs or Table tags in HTML.
Resources in android refer to things like images, strings, and other similar things that your application uses on runtime. In android programming, you will be creating lot’s of such resource files for providing data on runtime of application; more like properties files in normal java applications.
Normally you will design your app in such a way that UI will work across all sorts of devices: phones, tablets, televisions, etc. For example, Gmail app on a tablet will show your list of labels, the list of conversations in a selected label, and the list of messages in a selected conversation, all in one activity (screen) in a tablet. However, same Gmail app on a phone cannot do that, as there is not enough screen space, so it shows each of those (labels, conversations, messages) in separate activities (screens). Android supplies a construct called the fragment to help make it easier for you to implement these sorts of effects. We will learn them in coming posts in detail.
e) 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 APK file that you will upload to the Play Store or distribute by other means.
Important thing to learn is that each android application has a unique package name and it must fulfill three requirements:
- It must be a valid java package name, as some java source code will be generated by the android build tools in this package.
- No two applications can exist on a device at the same time with the same package.
- No two applications can be uploaded to the Play Store having the same package.
So, you will pick a package name following the “reverse domain name” convention (e.g., com.howtodoinjava.android.app). That way, the domain name system ensures that your package name prefix (com.howtodoinjava) 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.
Types of Android Devices
Android devices come in all shapes, sizes, and colors. However, there are three dominant “form factors”:
However, it is important that you understand that 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.
Similarly, as you build your applications, rather than thinking of those three form factors, focus on what capabilities and features you need. Not only will this help you line up better with how android wants you to build your apps, but it will make it easier for you to adapt to other form factors that will come about such as:
- watches and other types of wearable devices
- airplane seat-back entertainment centers
- in-car navigation and entertainment devices etc.
Android Versions And API Levels
Android has come a long way since the early beta releases from late 2007. Each new Android OS version adds more capabilities to the platform and more things that developers can do to exploit those capabilities. Moreover, the core Android development team tries very hard to ensure forwards and backwards compatibility. An app you write today should work unchanged on future versions of Android (forwards compatibility), though it may perhaps miss some features or work in some sort of “compatibility mode”.
To help us keep track of all the different OS versions that matter to us as developers, Android has API levels. A new API level is defined when an android version comes that contains changes that affect developers. When you create an emulator AVD (sort of VM) 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.
Below is list of android versions and API levels. You will need this information when you want to have your application installed on devices having at least certain capabilities.
- API Level 3 (Android 1.5)
- API Level 4 (Android 1.6)
- API Level 7 (Android 2.1)
- API Level 8 (Android 2.2)
- API Level 9 (Android 2.3)
- API Level 11 (Android 3.0)
- API Level 15 (Android 4.0.3)
- API Level 16 (Android 4.1)
- API Level 17 (Android 4.2)
- API Level 18 (Android 4.3)
- API Level 19 (Android 4.4)
Dalvik Virtual Machine
Virtual machines are used by many programming languages, such as Java, Perl, and Smalltalk. The Dalvik VM is designed to work much like a Java VM, but optimized for embedded Linux environments. In development environment, you will using this VM for testing your code to see how it will look on a actual android device.
Now let’s see, what really goes on when somebody writes an android application and run it:
- Developers write Java-syntax source code, leveraging class libraries published by the Android project and third parties.
- Build tools compile the source code into Java VM bytecode, using the javac compiler that comes with the Java SDK.
- Build tools 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).
- An Android device or emulator runs the APK file and you get what you build in form of an live app.
From developer’s standpoint, most of this is hidden by the build tools. You simply pour java source code from the top, and the APK file comes out the bottom of a funnel.
That’s all for this short Introductory Android Tutorial. I will revisit all above terms again in coming posts to develop more robust understanding of whole picture and things which run behind the scene.
Happy Learning !!