Android Code Organization

Intro

In order to write effective programs, we must first understand how the source code of an Android application is organized.  Android applications are generally written in Java.  I say "generally" because there are mechanisms to use other languages if a developer so desires.  Because the official SDK supports Java, and the use cases for other languages are so slim, we won't discuss those in the scope of this class, but if you're interested, you can read about it here: Android NDK.

Before we move on, you should read the "Application Fundamentals" portion (the first section) of this page on the Google Developers website: Application Fundamentals

All done?  Great!  We'll be referring to the Developer pages frequently throughout this class, and you'll probably end up using it as a resource when developing your own apps in the future.  The nice thing about going straight to the source is that it always has the most up-to-date information...an important trait given the current pace of change in the world of mobile development!

Having read about application fundamentals, at this point you should have a basic understanding of how Android runs and how applications are treated.  At a minimum, you should know this:

• Android applications are compiled by the SDK into APK files
• Each app is treated as a separate Linux user with a unique user ID
• Each application runs in its own 'sandbox', in isolation of other apps
  • An app's files can only be accessed by the 'user' with the proper user ID
  • The Principle of Least Privilege means access to only what's needed to get the job done, and no more
• Each app runs in its own process by default
• Each process runs in its own virtual machine (VM)

Let's expand on that last bullet.  Applications run inside a special VM known as a Dalvik VM.  The Dalvik VM format is the standard for all API levels through 4.4.  With the release of Android 4.4, Google introduced a replacement for Dalvik called ART (Android Runtime).  ART provides many performance enhancements, and became the default starting with Lollipop (5.0).

The Manifest File

Let's go back and have a look at our Hello World app.  When developing an app in Android Studio we can see the un-compiled code (necessarily).  I can hear you saying to yourself, "self...there's more than Java here?!"  Nice observation.  In addition to Java, the Android SDK uses XML extensively.  You saw some of this in the layout files, which you modified to add a ToggleButton element.  Let's take a look at another one of these files in more detail.  Open the AndroidManifest.xml file:

 

 

The Manifest file is a required component of every Android application.  You can think of it as a type of configuration file used by the operating system, telling it how to treat each specific app.  It's also used by the Google Play store when you publish your app to uniquely distinguish it from other apps (by package name), push updates (using version numbers), determine eligible devices, etc.  In addition to the pre-populated fields shown above, there are many configuration options.  We'll introduce most of these options and add them as needed as we build progress through the lessons, but if you can't wait, have a look here: App Manifest Options

Source Code Files

   

As seen in the Package Explorer window, Android applications are organized into distinct folders, each with a special purpose:

• manifests
  • Contains the Manifest XML file discussed above
• java
  • Contains all your Java files, organized by package name
• res
  • Resources used by your application.  Unlike assets, files in the resources folder  are referenced and given unique identifiers at compile time.  Additionally, there are subfolders that each provide a specific functionality:  
    • drawable - image files and XML-defined graphics
    • layout - define and organize Views 
    • menu - define the options and context menus
    • values - define variables such as Strings, custom styles, etc.
  • The resources folder provides you the ability to support multiple devices by using custom folders/files for things like screen dimensions, languages and device orientation.
  • Custom sub-folders are NOT supported in the resources folder!

Take a moment to examine the build > generated folder, viewable in Project view.  HERE THERE BE MONSTERS!  DON'T TOUCH!  OK, not really.  But seriously...don't touch the files in this folder. There's an important file that you should be aware of in this folder, but should NEVER make changes to, named R.java.  The R file is automatically generated by the IDE dynamically, and defines a unique integer value to every item in your app's resources folder.  When this file is generated, all of the XML objects you created are assigned a unique integer value which is, in turn, used to reference the object in your Java code.  

 

To see this in action, let's look a little closer at the R.java file generated in our helloworld app.  Remember the new String you added to the strings.xml file that was name "fun"?  Here's what it looks like in the R.Java file (see the yellow highlighted line):

Build Process

All of your Java and XML files are compiled as part of the APK build process.  There are several steps involved in turning your raw code into a runnable app (see graphic below).  This entire process can be accomplished from the command line.  Luckily, the IDE automates the entire process for us.  It's still useful to understand exactly what is happening behind the scenes when you click the IDE button to run your app on a device.  To get a more detailed explanation of the build process, click here: Building and Running Apps.  

(source: http://developer.android.com/tools/building/index.html#detailed-build)