A smartphone is an intelligent cellular phone, or a cellular phone with a computer inside, as well as some extra hardware. Thus, programmers can write application software for them; such application software is called an app. A smartphone has the typical components of a regular computer: a CPU, memory, a storage device, an operating system, and other devices, such as a camera, an accelerometer, or a GPS.

The two most well-known operating systems are the Android operating system, from Google, and iOS, from Apple. Other popular operating systems for smartphones include BlackBerry, Windows, and Symbian. The annual number of smartphones sold worldwide is now over one billion. Furthermore, smartphones comprise an increasing percentage of the mobile phones sold.

There are over 100 different varieties of Android phones or tablets. They can have a different CPU, a different screen resolution, and a different amount of memory available. This makes it difficult for developers to test their apps on actual devices. The dimensions of the various components of the user interface of an app can be different depending on the Android phone or tablet. Furthermore, in complex games where speed is an issue, an app can run differently on an old and slow Android device as compared to a more recent one. This is something to keep in mind as we develop apps for the Android market.

Android apps are distributed via Google Play (https://play.google.com), which used to be called the Android Market. Google Play is actually a store for digital content, much like the Apple’s app store, not just apps. In order to distribute apps on Google Play, you need to become a registered developer, which costs $25.

There are now over one million apps in Google Play, and the vast majority of those apps are free. Top categories include entertainment (games), personalization, tools, books, and references. Most of the downloaded apps are free apps. One should also be aware that the Android operating system is open, so anyone can easily copy an app from one Android device to another. There is little protection for intellectual property.

Open Android Studio. The first time we run Android Studio, the environment checks that it is up to date, asks us to download components if needed. Once that is done and we click on Finish (see FIGURE 1.1), we see the screen shown in FIGURE 1.2. Recent projects are listed on the left side; there will not be any the first time we use Android Studio. To start a new project, click on Start a new Android Studio project.

In the dialog box shown in FIGURE 1.3, we type in our project name (we choose HelloAndroid) and our domain (we chose jblearning.com; if we do not have a domain name, we can choose any name); the other two fields (package name and project location) are automatically filled. If we prefer a different project location, we can edit that field. Note that the package name is our domain name in reverse. It is typical for developers to name their package with their domain name in reverse; it insures that it is unique. When we are done, we click Next.

The next dialog box (FIGURE 1.4) is used to specify the minimum SDK for this project; depending on our app, this can be important. For example, if we incorporate advertising, this may require a higher SDK level than the default level; however, the more recent the SDK level we specify, the more we restrict the potential number of users for our app. For this app, we keep the default SDK level and click Next.

In the next dialog box (FIGURE 1.5), we can choose among several templates; a template creates skeleton code with some predefined user-interface functionality; often, it provides a user interface that is similar to what can be found in native apps. For this app, we choose the Empty Activity template—it creates a minimum skeleton code.

In the next dialog box (FIGURE 1.6), we can specify various names for the first activity class and layout files. For this first app, we keep the default names, MainActivity for the class, and activity_main for the layout file. After we click on Finish, our project is created.

The project directory structure has been created along with many source files, which we can see on the left pane of the Android Studio development environment (shown in FIGURE 1.7).

The program generates a lot of directories and files automatically.

• ▸ The manifests directory contains the AndroidManifest.xml file, automatically generated and editable. Among other things, it specifies the resources that this app uses, such as activities, the file system, the Internet, the device’s hardware resources. . . When a user downloads an app, this file tells the user about the resources that this app uses (e.g., if it writes to the file system of the device).

• ▸ The java directory contains the Java source files. We can add more Java source files as our app gets more complex.

• ▸ The res (res stands for “resources”) directory contains resources such as utility files (to define strings, menus, layouts, colors, styles) and images, sounds, etc. Ids are automatically generated for these resources inside a file named R.java. R.java should not be modified.

• ▸ Inside the res directory, the drawable directory is meant to contain images and other drawable resources. It can contain jpegs, pngs, gifs, files to define gradients, etc. As needed, we can add resources to this directory.

• ▸ Inside the res directory, the mipmap directory contains the icon for the app. As needed, we can add resources to this directory.

• ▸ Inside the res directory, the layout directory contains XML files defining screen layouts. At this point, it contains the activity_main.xml file, an automatically generated layout file for our empty activity. We can edit this file to define the Graphical User Interface (GUI) for this app.

• ▸ Inside the res directory, the values directory contains XML files defining various resources such as colors (in the colors.xml file), dimensions (in the dimens.xml file), styles (in the styles.xml file), or strings (in the strings.xml file). We can edit these files to define more color, dimension, style, or string resources.

• ▸ The gradle scripts directory contains the scripts used to build the app.

In this chapter, we look at the following files in detail: AndroidManifest.xml, MainActivity.java, dimens.xml, strings.xml, styles.xml, colors.xml, and activity_main.xml. We also add an icon for the app.

A nice feature of Android Studio is that it lets us preview a screen without running the app. A layout file needs to be selected for the preview to show. To select activity_main.xml, we double click on the file name. In the menu, if we select View, Tool Windows, Preview, a preview of the app shows on the right side of the environment, as shown in FIGURE 1.8. In this way, we can edit the GUI and preview it without running the app. We can preview a screen in both portrait and landscape orientations by choosing from a menu (FIGURE 1.9). FIGURE 1.10 shows the preview in landscape orientation. We can also preview the app choosing a different theme by clicking on the AppTheme drop-down list (FIGURE 1.11) and choosing among many devices (FIGURE 1.12) by clicking on the device drop-down list.

The GUI for this app is defined in the activity_main.xml file. Note that we can also set the GUI by code.

To open activity_main.xml, we click on res, then click on layout, then double click on activity_main.xml. In order to see the actual XML code, we may need to click on the Text tab at the bottom of the panel.

Activity_main.xml, shown in EXAMPLE 1.1, is an eXtensible Markup Language (XML) file. The Android development environment uses XML extensively, in particular to define the user interface of the various screens of an app and also to define various resources such as strings, dimensions, menus, styles, shapes, or gradients.

We may already be familiar with HyperText Markup Language (HTML) and its syntax. HTML is the language that web browsers use, and has a fixed set of tags and attributes. XML uses essentially the same syntax as HTML, but we can create our own tags and attributes.

We can find the full XML documentation at http://www.w3.org/XML/.

We will next outline the main characteristics of XML. An XML document is made up of elements, and each element can have 0 or more attribute/value pairs. Elements can be nested. An element can have content or not. A non-empty element begins with a start tag and ends with an end tag. The text between the start tag and the end tag is called the element content.

Although the actual specification is a bit more complex, we will use the following simplified syntax to define a non-empty XML element:

<tagName attribute1=”value1” attribute2=”value2” ... >
Element Content
</tagName>

Here are two examples:

<price>46.00</price>
<app language=”Java” version=”7.0”>Hello Android</app>

If an element has no content, then we can use an empty element tag with the following syntax:

<tagName attribute1=”value1” attribute2=”value2” ... />

Here are two examples:

<website name=”twitter”/>
<app language=”Java” version=”7.0”/>

There are rules for naming tags; we use only tag names that start with a letter or an underscore and are followed by 0 or more letters, underscores, or digits. The official specification for tag names is more complex than the earlier, and we can find it at http://www.w3.org/XML/Core/#Publications.

Comments use this syntax:

<!-- Write a comment here -->

The file activity_main.xml defines how the GUI should look like. The RelativeLayout element defines that the various graphical elements will be positioned and displayed in relation to each other or their parent graphical container.

In the activity_main.xml file the element RelativeLayout uses the first syntax and includes attributes android:layout_width and android:layout_height, which both have value match_parent (lines 5–6). This means that the RelativeLayout element will be as big as its parent element, which in this example is the screen. It also includes attributes android:paddingBottom, android:paddingLeft, android:paddingRight, and android:paddingTop (lines 7–10). The android:paddingBottom element has value @dimen/activity_vertical_margin (line 7): this means that there will be some padding on the left side of the screen equal to the value of the dimen element named activity_vertical_margin (in this case 16 px) in the dimens.xml file located in the values directory of the res directory.

Generally, if a constant named constant_name is defined in a resource file named resource_types.xml, we can access the value of that constant using the syntax @resource_type/constant_name.

Lines 13–16 define a TextView element that is nested inside the RelativeLayout element; a TextView element is an instance of the TextView class, which encapsulates a label. This TextView element is an empty element and as such has no content; it has three attribute/value pairs:

• ▸ The attributes android:layout_width and android:layout_height have value wrap_content (lines 14 and 15). That means that the TextView element’s width and height are just as big as necessary to make the contents of the TextView element fit; the element “wraps” around its contents.

• ▸ The attribute android:text defines the String displayed inside the TextView; it has value Hello World!.

The activity_horizonal_margin and the activity_vertical_margin values are defined within two dimen elements in the dimens.xml file (lines 3–4), shown in EXAMPLE 1.2. Their values are 16 px. The suffix dp stands for density pixels, which means that the value is device independent. If our app requires using a different value per screen size, we can define many values in the dimens.xml file, one per screen size.

Inside the dimens.xml file, the syntax for defining a dimen resource is:

Try to modify dimens.xml as in EXAMPLE 1.3. The environment updates its preview as shown in FIGURE 1.13.

Similarly, the String whose value is HelloAndroid (see the blue title of the app in Figure 1.13) is defined at line 2 of the strings.xml file (EXAMPLE 1.4), located in the values directory of the res directory. We can create String constants in our Java files, but it is recommended to store String constants in the strings.xml file as much as possible. If we want to modify one or several String values later, it is easier to edit that file than to edit our Java code.

Inside the strings.xml file, the syntax for defining a String resource is:

<string name=”stringName”>valueOfString</string>

Try to modify strings.xml as in EXAMPLE 1.5. The environment updates its preview as shown in FIGURE 1.14. The String app_name is used in the AndroidManifest.xml file, which is explained in paragraph 1.7.

The file styles.xml, located in the values directory of the res directory, defines the various styles used in the app. EXAMPLE 1.6 shows its automatically generated contents.

Inside the styles.xml file, we can modify a style by adding an item element using this syntax:

<item name=”styleAttribute”>valueOfItem</item>

The name of the style attribute that specifies the text size inside a TextView is android:-textSize. In EXAMPLE 11.7, we change the default text size to 40 at line 6. The environment updates its preview as shown in FIGURE 1.15.

Note that the style defined in styles.xml consists of three color constants using the syntax @color/color_name. These constants are defined in the colors.xml file, shown in EXAMPLE 1.8, and also located in the values directory of the res directory. Its contents are automatically generated. Inside the colors.xml file, the syntax for defining a color resource is:

<color name=”colorName”>valueOfColor</color>

The color values are defined using the syntax æRRGGBB where R, G, and B are hexadecimal digits representing the amount of red, blue, and green, respectively.

If we modify the value of the color named colorPrimary to æFF0000 (full red), the preview is updated as shown in FIGURE 1.16.

The entry point for our app is the MainActivity class, whose name is composed of the names Main and Activity. It is located in the com.jblearning.helloandroid package in the java directory (shown in EXAMPLE 1.9).

The source code for an Android app uses Java syntax. Line 1 is the package declaration. When this project was created, we told Android Studio to place the code in the package com.jblearning.helloandroid. Lines 3–4 import the classes used in this class. We need to import AppCompat-Activity because MainActivity extends it (line 6) and thus inherits from it. AppCompatActivity inherits (indirectly) from the Activity class and includes an action bar (in red on Figure 1.16) above the activity screen, where the app title shows.

An activity is a component that provides and controls a screen with which users can interact. An app can consist of several activities, possibly passing data to each other. Activities are managed on a stack (a last-in, first-out data structure). To create an activity, we must subclass Activity or one of its subclasses as done in the skeleton code of MainActivity, which was automatically generated. Some methods of the Activity class are automatically called by the system when an activity starts, stops, resumes, or is destroyed.

The onCreate method (lines 8–12) is automatically called when the activity starts. We should override this method and if needed, create the components of the activity inside that method. At line 10, we call the onCreate method inherited from Activity via AppCompatActivity. At line 11, we define the layout of the app by calling the setContentView method, shown in TABLE 1.1. The layout is defined in the activity_main.xml file. The argument of the setContentView method is an integer that represents the id of a layout resource defining a screen layout. Ids of resources can be found in the R.java file inside the app/build/generated/source/r/debug/com/jblearning/helloandroid directory. The R class contains many inner classes: anim, attr, bool, color, dimen, drawable, id, integer, layout, menu, string, style, styleable. Each inner class is public and static and contains one or many int constants. Each int constant is accessible via the syntax:

R.className.constantName

The activity_main constant, the id for the activity_main.xml file, a layout resource, is defined in the layout class, inside the R class. Thus, it can be referenced using R.layout.activity_main. Calling setContentView with an integer argument that represents a layout XML file, in this case R.layout.activity_main, is called inflating the XML.

The AndroidManifest.xml file, located in the manifests directory, specifies the resources that the app uses, such as activities, the file system, the Internet, and hardware resources. Before a user downloads an app on Google Play, the user is notified about these. EXAMPLE 1.11 shows AndroidManifest.xml’s automatically generated version. Among other things, it defines the icon (line 7) and the label or title for the app (line 8). The text inside the label is the app_name String defined in strings.xml.

We should supply a launcher icon for our app. This is the visual representation of our app on the Home screen or the apps screen. A launcher icon for a mobile device should be 48 × 48 dp. Various devices can have different screen densities, thus, we can supply several launcher icons, one for each density. When doing that, we should follow the 2/3/4/6/8 scaling ratios between the various densities from medium (2) to xxx-high (8). If we only supply one icon, Android Studio will use that icon and expand its density as necessary. TABLE 1.4 shows an example of possible dimensions using that rule. If we intend to publish, we should provide a 512 × 512 launcher icon for display in Google Play. We can find more information at https://www.google.com/design/spec/style/icons.html. FIGURE 1.41 shows the mipmap directory after we added a file named hi.png whose dimensions are 48 × 48.

To set the launch icon for the app to hi.png, we assign the String @mipmap/hi to the android:icon attribute of the application element in the AndroidManifest.xml file. The @mipmap/hi expression defines the resource in the mipmap directory (of the res directory) whose name is hi (note that we do not include the extension). Line 7 of Example 1.11 becomes:

android:icon=”@mipmap/hi”

One thing we have to worry about is that some users will use the app in vertical (portrait) orientation, and others will use the app in horizontal (landscape) orientation. The default behavior for an app is to rotate the screen as the user rotates the device, thus, our current app works in both orientations. FIGURE 1.42 shows the app running inside the tablet in horizontal orientation. As an app gets more complex, this becomes an important issue. Later in the book, we discuss alternatives and strategies to manage orientations. Sometimes, we want the app to run in only one orientation, vertical for example, and therefore we do not want the app to rotate when the user rotates the device. Inside the activity element, we can add the android:screenOrientation attribute and specify either portrait or landscape as its value. For example, if we want our app to run in vertical orientation only, we add:

android:screenOrientation=”portrait”

Note that we can control the behavior of the app on a per activity basis. In this app, there is only one activity, but there could be several. EXAMPLE 1.12 shows the updated AndroidManifest.xml file. If we run the app on a device, the screen does not rotate as we rotate the device; it stays in portrait orientation. FIGURE 1.43 shows the icon for the app in the emulator (among native apps).

Android Application Package (APK), is the file format for distributing applications that run on the Android operating system. The file extension is .apk. To create an apk file, the project is compiled and its various parts are packaged into the apk file. At the time of this writing, the apk file can be found in the projectName/app/build/outputs/apk directory.

Apk files are built using the gradle build system, which is integrated in the Android Studio environment. When we start an app, the gradle build scripts are automatically created. They can be modified to build apps that require custom building, for example:

• ▸ Customize the build process.

• ▸ Create multiple apks for the app, each with different features, using the resources of the project. For example, different versions can be made for different audiences (paid versus free, consumer versus corporation).