Jump to...

  1. Packages in Java
  2. Android Project File Structure
  3. Application Resources
  4. Navigation on an Android Device

Chapter 2
Structure of an Android App

The structure of an Android application is fairly rigidly defined. In order for things to work properly, you need to put keep certain files in the right places. At the end of this chapter, we also discuss how basic app and screen navigation works on Android devices.

Packages in Java

Packages in Java are essentially just folders where your classes can be stored. This allows you to write code that has a well-organized structure where classes that are related can be in the same package and be named in a meaningful way that indicates their purpose.

You've already used packages before in Java, perhaps without realizing it, because it's almost impossible to write a meaningful application that doesn't use classes in different packages. For example, Java defines a top-level package named java, and inside it are packages such as lang, which contains core classes like String, and util, which contains collection classes like ArrayList. Similarly, the Android API provides a top-level android package that contains packages named graphics, view, widget, and many more.

If you wanted to use the ArrayList class in your code, you would have to refer to it using its fully-qualified name that includes its entire package path: java.util.ArrayList. Fortunately, the Java language reduces the amount of typing that you have to do by providing the import statement. If you write the following: 

  import java.util.ArrayList;

then writing ArrayList by itself would refer to the class in the java.util package.

Another advantage of using packages in Java is that you can have multiple classes with the same name as long as they are in different packages and they will not conflict. This becomes crucial when you write code that uses a lot of third-party libraries where the probability is high that libraries would have classes with the same names.

How Android Uses Packages

Android uses packages not only to arrange the code in an application but to manage the applications themselves. The Android OS requires that every app installed on a device have a package identifier that is at least two levels deep. In other words, a package named mycoolapp would not be appropriate, but one named mycompany.mycoolapp would be acceptable. Then, the main package that contains an app's code is used to uniquely identify that application on the device, and to permit apps to communicate and share information with each other.

As a popular convention, most Java developers create a package structure based on a reverse domain name scheme. For example, imagine that you were a developer at a company named CoolSoftware and had a website located at coolsoftware.com. All of the code for your company's apps could be stored in subpackages of com.coolsoftware. Then, if you were developing an app named AwesomeApp, you could store all of its code in com.coolsoftware.awesomeapp. You could even use subpackages under that to break up the code further, perhaps by separating the model and view code into separate packages.

Android Project File Structure

Android projects in Eclipse (or even in general, when using other development tools), have a pre-defined structure with code and resource organized into a number of folders.

src/

Contains source code that you write for your app.

gen/

Contains source code that is autogenerated by the Android development tools that is required for your app. Do not modify any of the source files in this folder—your changes will be overwritten the next time you build your project anyway.

libs/

Contains precompiled third-party libraries (JAR archives) that you want to use in your app. For example, if you were writing an app that pulls data from Twitter feeds, you would want to use a Twitter library that someone has already written for you, and you would put it in this folder.

res/

Contains other folders with resources for your application: GUI layouts, icons, menus, and so forth.

assets/

Contains other media that you might want to use in your app, such as videos, sounds, and large images that are not used directly in GUI layouts.

Application Resources

As briefly mentioned above, the res folder of your project stores a variety of resources that your application needs to present itself to the user. These resources are stored in folders inside the res folder, depending on the type of the resource:

menu/

Contains XML files that describe menus that are associated with screens in your application, which the user can make appear by clicking the Menu button on his or her device.

drawable-*dpi/

Contains images used in various parts of the application: launch screen icons, images attached to buttons or menus, and so forth.

Android projects can actually have multiple drawable folders that are named after the resolution of the device. For example, drawable-ldpi would contain images used on low resolution devices, drawable-hdpi would contain images used on high resolution devices, and so forth. This allows an app developer to create images designed specifically for different sized screens that look crisp and clear without any scaling or blurring.

Of course, if an exact resolution match is not found, the Android OS will look for the closest match and scale it up or down to fit. For this reason, in this class we'll just stick all of our images in drawable-hdpi and not worry about multiple sizes.

layout/

Contains XML files that describe the layout of the widgets (buttons, text fields, and so forth) on the screens in your application. Fortunately you typically do not need to write any XML directly – the Android tools in Eclipse provide a drag-and-drop editor for laying out your screens.

values/

Contains "values" used throughout the application, such as text strings and style definitions. The main use of this is the strings.xml file, which can be used to store the text strings used in your GUI layouts (e.g., the labels on buttons). You don't have to do this, but if you do, it makes your application easier to translate into other languages because you have all of the strings stored conveniently in one place and you only need to have that single file translated.

There are other types of resources as well, but these are the ones that we will see most frequently in this class.

Navigation on an Android Device

Navigation between apps and other features on Android phones is mostly consistent across devices, regardless of the form factor or manufacturer of that device. Google has put in place a set of suggested, and sometimes required, controls by which the user can navigate on the device.

The latest versions of the Android operating system require that devices have Home and Back buttons to support navigation among screens and apps. If you hover over the picture of the phone to the right, you will see portions of the interface highlighted that you can then hover over to see a description.

Older devices running older versions of Android had additional buttons, Menu and Search. In the latest OS, menus have been replaced by action bars, thin toolbars that were visible at all times instead of hidden until the user requested them. However, backwards compatibility allows users to still use menus in the "old" way in newer apps or to upgrade their apps to use the newer action bars. In fact, your emulator still provides a Menu button if you need to run these legacy apps.