Android 7 Platform Structure: A Collection of Open Technologies

As you have learned, the foundation on which Android is built is the carefully coded, and painstakingly tested, Linux Kernel. Linux and its core services manage physical hardware for smartphones, tablets, e-book readers, smartwatches, and iTV sets, and give Android applications complete access to the features of each consumer electronics device, including GPS, touchscreen, memory, data storage, camera, flash, gyroscope, compass, accelerometer, barometric sensor, biometric (e-Health) sensors, Bluetooth, Wi-Fi, NFC, 4G LTE, USB, and much more.

Linux doesn’t do it all alone, however. Android has a wide array of Java API libraries, that provide higher-level customized functions and services for things like SQLite database management, 2D image compositing, image blending, SVG rendering, 3D rendering, web page (HTML5, CSS3 and JS) rendering, digital audio playback, digital video streaming, frame-based and procedural animation, Bluetooth, and more. The majority of these are based on open technologies, such as SQL, GIF, SVG, WebKit, OpenGL, Vulkan, PNG, FLAC, Ogg Vorbis, Ogg Theora, VP8, and VP9. Some “almost” open source (these patents expire in a few years) have been licensed for Android by Google, such as MPEG-4, MP3, WAVE, BMP, JPEG, Bluetooth, and similar new media technologies.

The higher-level Java functional libraries are the ones that Android app developers use to create their applications. This is so that developers do not have to “talk” directly to the low-level operating system functions. This is done so that application development becomes an order of magnitude more easily! You will be learning about some of the core Java 8 functional libraries that are used to develop Android 7.1.1 applications during the course of this book, starting with this chapter when we look at the basic (empty) Android application bootstrap Java code.

The Android OS on the user side of the equation (versus the developer side, which we will be focusing on during this book) also includes a large number of “end-user utility” applications, which Android device users have come to expect on their Android device. Examples of these include a phone call management utility, an e-mail client, various social media platform clients, a contact manager, a web browser, an alarm clock, a calendar, Google Maps, Google Search, a media player, and possibly some basic casual games, to name a few.

Android OS supports all of the popular open source new media formats that developers will want to use in their applications, including the powerful ON2 VP9 video codec, added in Android 5. ON2 was acquired by Google, and VP8 and VP9 were released in an open source video codec called WebM, which you can find in Android as well as in browsers such as Firefox, Opera, and Chrome. Both the WebM and the MPEG-4 H.264 AVC digital video codec’s “Quality to File Size Ratio,” and therefore their playback performance, are fairly impressive for open source video codecs. Also added in Android 5.0 was the ability to play back MPEG-H H.265 HEVC content.

For more information regarding the two dozen new media formats that are supported in Android 7.1.1 you can visit:

http://developer.android.com/guide/appendix/ media-formats.html

The next section of this chapter introduces Java’s Dalvik Virtual Machine (VM), which optimizes your Java code, so that it will execute effectively in low-power, embedded (portable and iTV set) consumer electronics devices.

Now let’s take a look at the runtime, or compiled version, of your Android application, and how it uses Java bytecode with the Android Run-Time (ART) to optimize the runtime (end user) performance of an Android app.

Android 7 Executable Structure: Compiled Runtime Java Bytecode

Everything in the Android Studio 2.3 development environment, as well as all of the included applications, is created by using a combination of Java code and XML markup. This is compiled by IntelliJ and Gradle into a Java “bytecode” version of your app that will be “executed” (run) using the Android Run-Time (ART) utility, which is a part of Android OS. IntelliJ creates this bytecode, and puts it into the .DEX file format (similar to an .EXE file).

This .DEX file extension and data format essentially amounts to being a compact, low-level executable file format that the Android operating system, and therefore Android devices that run Android OS, will be able to understand and run. A DEX is not specifically encrypted, but if you look at the contents of one of these compiled files, it will not be readily decipherable. The flow of XML, to Java code, to bytecode, to executable data would be as follows:

  XML (.XML) → Java (.CLASS) → ByteCode (.DEX) → App (.APK) → Runtime (ART) → Device Display

The Android runtime environments before Android 4.4 used only Dalvik Virtual Machine (DVM); and in Android 4.4, you could choose between DVM and ART. Android 5.0 and later use only ART. These runtimes give your apps access to hardware device features, as well as the low-level Android and Linux Kernel functions, so that you don’t have to do all of that low-level programming yourself.

The good news is that an an Android Absolute Beginner, you don’t need to understand much about ART, other than what this .DEX file is, the place it provides in the chain of code to runtime, and that it will do a good job optimizing your application for your users. To use the Java programming language, you’ll simply include the appropriate components from the Java libraries you need in your program, using something in Java called an import statement. After you do this, your app’s code can employ that built-in Java library’s capabilities. You will learn how to put a number of these powerful Java libraries to work later on in this chapter, and in all the chapters, for that matter, during the remainder of the book. We will also cover this in detail in the Java Primer in Chapter 5.

Next, I show you how to create your first Android application, so that you can see how to organize your Android 7 application assets in a highly structured Android project hierarchy, which must be followed for Android apps to work properly. In this way we can get right to some hands-on use of the Android Studio application development environment, to see how you create a new, empty Android bootstrap application infrastructure; and start learning about Android Development, Android Studio, Java, XML, Gradle, application resources, and new media assets.

The Android Studio Welcome Menu: Creating a New Android 7 App

The first step is to launch Android Studio 2.3. From there, using the Welcome to Android Studio menu that you saw in Figure 2-5 in Chapter 2, you will create your new Android 7.1.1 application project. The application infrastructure we are about to create (or Android Studio is about to create for us) will contain your application’s Java programming logic, XML markup, new media assets, and your other application resources.

1. To launch Android Studio, find and click the Android Studio quick launch icon, located on your workstation taskbar. If you didn’t create one of these, find Studio64.exe on your hard drive (you can use Search in your File Management Utility), and double-click it.

2. You will see the Welcome to Android Studio launch dialog, and you will click the first option, Start a New Android Studio Project. If you want to see a screenshot of this aforementioned dialog, see Figure 2-5, from Chapter 2.

3. Once you select this option you will get the New Project dialog, as is shown in Figure 3-2. This is the first in a series of five dialogs you will be using to create a blank Android Studio project. These dialogs will step you through the process of creating a new Android application project infrastructure. Accept the default My Application name for your app and user.example.com Company Domain. Since this is the Absolute Beginners title, you will not need to select your Include C++ Support option check box. Click the Next button to advance to the Target Android Devices dialog, where you will accept the default Phone and Tablet application type option.

   

   Figure 3-2. Accept the default My Application name, user.example.com Company Name, Phone and Tablet, and click Next

4. After you click a second Next button in the Target Android Devices dialog, there is a possibility that Android Studio might launch the Installing Android SDK repository updater progress bar, which can be seen in Figure 3-3. What Android Studio is doing is that it is checking the Android APIs that you have specified for the use of the core Android OS (phone and tablet), as well as Android Wear 2, Android TV, Android Auto, or Glass. If any of these need installing or updates, this Installing Android SDK update function will kick in automatically and make Android Studio compliant with the application types that you wish to develop your Android application for.

   

   Figure 3-3. Android Studio will install any components needed for those target Android devices that you want to utilize

5. Once Android Studio has downloaded all of the new updates and APIs that you will need to develop the Android application you have specified in the Target Android Devices dialog, you will get the Installing Requested Components dialog shown in Figure 3-4. This will show you what is being added to your Android Studio. Once you see Done at the bottom left of this dialog, click the Next button to advance to the next dialog and continue creating a new blank Android application bootstrap software infrastructure.

   

   Figure 3-4. The Installing Requested Components dialog will tell you what APIs Android Studio has installed for you

6. The next dialog you will encounter is the Add an Activity to Mobile dialog, which can be seen in Figure 3-5. The default option is the creation of an Empty Activity (shown selected in blue in the top middle of this figure). This is the best option for an Absolute Beginner title, as we will need to examine what the minimum XML markup and Java code is required to create Android applications. We will then build up from that knowledge, and learn about what comprises the basic Android application infrastructure.

   

   Figure 3-5. In the Add an Activity to Mobile dialog, accept the default Empty Activity option, shown in blue, and click Next

7. Take a look at some of the other options in the Add an Activity to Mobile dialog to see what Android Studio is able to create for you. This is a pretty cool feature, because Android Studio will do a lot of the core application Java coding and XML markup for you automatically, allowing you to get to that application development stage where you can drop in your new media assets, and define your software functionality much more rapidly. You can create a Fullscreen Activity for iTV sets or tablets; Google AdMob and Maps Activities; Navigation Drawer Activity; a Scrolling Activity; a Tabbed Activity; a Basic Android Activity; and various utility-based Activities, such as login screens, settings collections, master-detail data display utilities and more. In case you may be wondering what this “Activity” is, it is a functional user interface display screen or collection of functionality in Android.

8. After you click the Next button, you will advance to the Customize the Activity dialog, which is shown on the left-hand side in Figure 3-6. Accept the default MainActivity Java class name and the activity_main.xml user interface layout container name, as we will be learning about these Android application component naming conventions as well during this chapter. Leave both the Generate Layout File (so Android Studio writes XML markup for you), as well as the Backwards Compatibility (AppCompat) options selected. The AppCompat API inclusion allows you to code apps for Android 7.0, which also work on Android 4.0.3, 5.0, and 6.0, as you already specified in the Target Android Devices dialog, shown on the right-hand side, back in Figure 3-2.

   

   Figure 3-6. Customize the Activity with the MainActivity name and activity_main user interface layout name, and click Finish

9. Once you click on the Finish button, Android Studio will start building the Gradle files for your application, as can be seen (numbered as 2) in Figure 3-6. Gradle is an open source build tool that was adopted in Android 5.0 and which manages the compilation (building) of your Android application. Prior to Android 5 Eclipse used the Apache Ant and Apache Maven build tools. Since this is an Absolute Beginner title, we will not be delving deeply into the complexities of Gradle build tools and configurations, other than to utilize them to create your Android applications.

10. If at some time your Windows Firewall blocks the OpenJDK Platform binary using the Windows Alert dialog, like the one shown in the right-middle of Figure 3-6, click the Allow Access button (numbered as 3), to allow the OpenJDK Platform binary to communicate with your own private network. You can also select public networks as well, if you know for a fact that they are safe. After you do this, the Gradle build tool will continue to create Android 7 application build files, and a progress bar dialog will tell you precisely which files are being generated for you. We will take a look at these files a bit later on, so you know what, and where, they are in your project.

11. Once this Gradle build process has been completed, Android Studio will launch. You will see your MyApplication project name in the title bar, as well as the location of your project files and the Android Studio version, as can be seen on the top left in Figure 3-7. In my case, the project files are located in the C:Users folder, under C:UsersuserAndroidStudioProjectsMyApplication.

    

    Figure 3-7. Close the Tip of the Day dialog , agree (or disagree) to help improve Android Studio, finish indexing your project

12. In the Tip of the Day dialog that comes up in the middle of the screen (I moved it to show you what was behind it in a virgin launch), look through some or all of the tips, and then use the Close button to close that educational feature of Android Studio 2.3. You can leave the Show Tips on Startup checked, if you want to avail yourself of this feature later on, which I will recommend that you do as an Absolute Beginner, until you are familiar with Android Studio. I numbered this first step as number 1 in Figure 3-7.

13. After you close the Tip of the Day dialog, Android Studio will open a pop-up dialog, numbered as 2 in Figure 3-7, that asks if you want to share your usage statistics with Google so that they can make user interface and user experience improvements to Android Studio 2.3. If this is acceptable to you, click the I agree link, and if not, click the I don’t agree link.

14. Android Studio and the Gradle build system will continue to build and index the project, as seen at the bottom right in Figure 3-7, using a progress bar and a text update as to what is being done.

15. Also notice in the center of the Android Studio screen there are some shortcuts that you can use to speed up your Android 7 applications development (this is why I have moved the Tip of the Day dialog out of the way). At the bottom of the list, notice the “Drop files here to open,” which lets you know you can drag existing Android Studio files into Android Studio 2.3 to open them. You can also use Double Shift to Search Everywhere, Alt+1 to get a Project View, Ctrl+Shift+N to Go to a File, Ctrl+E to open Recent Files, and Alt+Home to access the navigation bar.

Once your new project build has finished building, indexing, generating Java code and XML markup, and all of the other steps needed to create your Android application, the blank screen in Android Studio will be replaced with the project navigation and development panes that we will use during the remainder of the book to develop (and learn) Android applications.

These various panes let you navigate your project structure as well as edit your Java code and XML markup structure, as well as more complex files such as the Gradle build files that use the Groovy programming language. Let’s explore Android Studio 2.3 next, and see what we can learn about Android applications, and how they need to be put together, in order to compile (build) into a usable Android package (.APK) file that you can use in Google’s Play Store, to publish applications.

Exploring Your Android Studio Project: The Android App Structure

Once Android Studio opens, use the right-facing arrows to open the primary application folders, so you get what is seen on the left half of the screen in Figure 3-8. The right-facing arrows are called expand arrows, which turn into downward-facing arrows, called collapse arrows. These arrow heads toggle folder directories open or closed, as you’ll see, once you get familiar with them. As you can see, Android has a top-level app folder, which contains three primary subfolders: manifests, java, and res (resources). java and res subfolders have subfolders as well.

Figure 3-8. Open the Android Project pane folder hierarchy, and see what folders need to be used for Android Development

Your application Java code is in an appjavacom.example.user.myapplication folder that takes its name from the Application Name and Company Domain fields, which you saw in Figure 3-2. Inside of that folder is the Java code file MainActivity.java, which when compiled into Java bytecode, will become MainActivity.class after a build.

Your application resources (I like to call these your application’s “assets”) on the other hand are contained in the app esdrawable (images and illustration), app eslayout (user interface design), app esmipmap (app icons), and the app esvalues folder and its subfolders, which contain XML definitions and constant values for the app.

We will be getting into what the Java code in the MainActivity.java tab in the Android Studio central editing pane does in Chapter 5, so in this chapter, let’s focus on the contents of the Android project management pane, and learn what all of the components are that make up an Android project structure. As we do this during this chapter, we will take a look at the various subfolders and what components of our Android application need to be stored in certain subfolders. One of the things you need to do to become an Android developer is to learn how Android projects need to be organized. It’s really too bad there is not “forced organization” in more areas of our lives, because as you will soon see, Android is organized in such a way that it forces your application development work process to be surgically precise!

Let’s take a quick look at the activity_main.xml tab, which is shown selected in the center of Figure 3-9. You will be learning about XML in Chapter 4, but I wanted to make sure you knew how to click on tabs in the editing section of Android Studio, so you can go back and forth easily between editing your app’s XML markup and Java code.

Figure 3-9. Select the activity_main.xml editing tab (top) and Text tab (bottom), and use the Preview pane to see your app

As you can see, Java files go in the /app/java folder hierarchy, and the rest of the folders contain XML files and (or) new media assets. There are a large number of different types of resource folders, which start with specific names, such as drawable (image, animation, or shape assets), layout (UI Design XML definition assets), mipmap (app icon imagery), and values (value constants defining colors, dimensions, styles, and text strings).

You can also add other types of Android application project asset folders to this project folder hierarchy, which we will be doing during the course of this book, when we add advanced assets like digital video and animation. Since these folders also require specific names, which indicate the type of assets, as well as their functionality, I will outline what Android asset folder types (indicated by their folder names) and naming conventions are. I will provide them in a tabular format in Table 3-1, just so you have an overview of Android’s project folder hierarchy.

Let’s spend the rest of the chapter taking a look at the types of resource folders and what they contain, as this will show you what an Android application can contain, where you will need to place assets in order for them to be utilized properly, and show you capabilities and design factors that you’ll need to be aware of to make Android apps work on different Android hardware device types with various sizes, shapes, orientations, and resolutions.

Android Drawables: Images or Illustration That Draws on the Screen

A “drawable” in Android is aptly named, as it is anything that can be drawn onto the display screen. As you can see in Figure 3-9, Android Studio created five different application icon drawable-dpi versions for your PNG32 app icon. The app icon is named ic_launcher.png and is in the app/res/mipmap folder in the five most common pixel density drawable-mdpi, drawable-hdpi, drawable-xhdpi, drawable-xxhdpi, and xxxhdpi DPI resolutions. The latest XXXHDPI resolution density was added in Android 4.2 to accommodate Ultra-High Definition (UHD) displays, such as those found on 4K TVs, which have a 4096 by 2160 resolution; or the screen on the Samsung Galaxy S7, which has a 2560 by 1440 pixel resolution screen. From smartwatch (ldpi) to 4K TV (xxxhdpi), Android has a density constant to fit any consumer electronics hardware device.

You will be learning all about pixels and resolutions during Chapter 9 when we cover graphic design, but to give you an overview here of what the different DPI levels are for Android screen resolution density constants, I have put all of the density constants and their specifics in Table 3-2, for those of you who are already “pixel savvy.”

As you can see in Figure 3-9, I opened the drawable folder for you to show the ic_launcher graphic file that Android Studio created for you in five different resolution density versions. If you are wondering what the pixel dimensions are for these ic_launcher files, take a look at the sixth column in Table 3-2.

There are about a dozen different types of drawable objects in Android, each of which has their very own class. Some of the more important drawable types include BitmapDrawable, ShapeDrawable, NinePatchDrawable, AnimationDrawable, LayerDrawable, TransitionDrawable, and StateListDrawable, to name a few. I will try and implement as many different types of drawables as I can during this book, so you will be well rounded when it comes to using drawables in Android application development.

There are several types of drawable assets that will need to be placed in the drawable folders for these assets to be visible to, and accessible to, the Android application. The primary one is bitmaps, which we will be covering in Chapter 9, as well as media assets that are based upon (created with) bitmaps, such as frame animation, which we will be covering in Chapter 10. Assets that reference Bitmaps or Frame Animation in an XML definition file format would also be kept in this folder, as would any XML definitions creating shapes (2D vector graphics).

Android User Interface Design Layout: Asset to Design UI Layout

A “layout” in Android is also aptly named, as it is a definition of how your user interface elements and drawable assets are going to be “laid out” relative to each other on the Android device display screen. Once we get you up to speed on Java, in Chapter 5, you will be learning more about UI layout design throughout the rest of this book! Chances are, if you want your Android app to have a custom design for each type of device (iTV, smartphone, tablet, smartwatch, and iTV set), you’re going to have a number of custom /res/layout folders, not just /res/layout-land or /res/layout-port folders as I gave as an example earlier. You can have complex alternate resource folders as well, such as /res/layout-sw800dp-land for tablet, and /res/layout-sw480dp-port for phone or smartwatch.

The /res/layout/ folder and any custom layout alternate resource folders that you create will generally contain UI layout definition XML files. As you will see during Chapters 6 and 8, and over the rest of the book, UI layouts in Android are defined using XML layout definitions. These are handcrafted using XML markup, and stored in filename.xml files in the /res/layout folder or one of the alternate layout resource folders that you create.

Since we are going to look at the XML for the UI layout that Android Studio created for us in Chapter 4, and because we have a couple of chapters coming up specifically covering UI layout design, I am going to leave the /res/layout/ folder coverage at that, and move on to look at some of the other resource folder types next. Although Android applications tend to use Activity screens filled with UI widgets for navigation, Android does support menus as well, so let’s take a look at that next, as it is often integrated with the Activity user interface design layout.

Android Menu Design: Asset to Define Menu Structure and Options

A “menu” in Android is exactly what it says it is, and what you would expect it to be: a menu, or a list full of options, for your end users to select from in order to navigate around your Android application infrastructure. In previous versions of Android. menu use was not as much as a priority as it is going to be as iTV set devices and integration with Chrome OS (and Android laptops and PC sticks) become popular with billions of consumers.

There are several types of menus in Android, including pop-up menus, context-sensitive menus, and options menus. We will get more into menu design as we progress through this book, adding menu items to your application’s menu. Technically, the Android menu that your application uses, via a hardware MENU button on the Android device or via those three vertical dots on the Action Bar at the top of an Android device if there is no hardware MENU button, is called the Options Menu. The Status Bar is always above the Action Bar, at the very top of every Android device, and holds the battery power indicator, network mode indicator (3G, 4G, 4G LTE, and so forth), signal strength indicator, wireless connection indicator, and other device operation indicators.

In addition to the options menu, the Action Bar contains your application icon; application title; and if you code it correctly, either icons or text tabs that can access areas of your app, each of which is generally an Activity with its own UI design layout scheme.

The app/res/menu/ folder will contain XML definitions outlining the menu structure that you want to create for your application. Notice in Figure 3-9 that Android Studio follows file naming conventions for Java and XML files, so you would want to follow those and name the file containing your menu definition menu_main.xml. Notice the file naming convention; a menu_main.xml menu XML definition, a MainActivity.java and an activity_main.xml layout XML definition file. These all logically match up (type+function), so you know they are all functionally related to each other. This is because each Activity will have a UI layout and a menu, so this keeps things organized so that you know what code works together as an Android application complexity increases over time.

Android Data Values: Assets to Define Fixed Application Constants

A “value” in the Android project folder hierarchy is what is known in Java programming as a “constant.” Values in Java code are different than Java constants, as they are meant to change, whereas constants are meant to stay the same (that’s why they’re called constants). We will be getting into this distinction as far as Java goes soon, in Chapter 5, when we look at the Java programming language specifically. You will, of course, be required to understand exactly how Java works before we get much further into the book, as things will get more and more complicated with each successive chapter.

Android values (constants) are a bit more flexible than Java constants, because once your Java code places these initial constant values into memory, the application code may change them if needed.

Let’s examine the app/res/values/ folder from the current application bootstrap project in more detail. This is where you (or Android Studio, in the case of the New Android Application Project series of dialogs) will place any predefined application values. These exist in the form of XML files. These XML files contain constant definitions that define constant names and their data values.

The value constants that are defined inside of these XML files will later be referenced inside of your Java code, or via your XML markup. For example, these values might be strings (a collection of text characters), styles (how you want a UI design to be formatted throughout your app), dimensions (numeric size specifications), or other constants that need to be “hard-coded” values that your Java code or XML markup uses in your program logic or UI design that you do not want to change.

The logic behind having an app/res/values/ folder involves holding all of your constant values for your application in one place. This is a similar concept to the repository we used in Chapter 2 to update Android Studio, only the /res/values/ is a resource repository for value constants that are used in your Android application. The /res/values/ folder is therefore your application constants repository data (folder) structure, and its usage allows you to make your application constant changes in one single location. In this way, if you need to adjust your constant values during application development or testing, you can do this using XML files.

Figure 3-9 shows four examples of the types of constant value XML files that Android Studio has already created for you and placed into the app/res/values/ folder in your bootstrap Android application IntelliJ project hierarchy:

• colors.xml: An XML file that will define the color constant values to be used in your application. These allow you to standardize the UI. For example, you could define your app’s background color as a constant. Then, if you decide to tweak it later, you need to do the tweak in only one place and the change is implemented across your entire application. We cover color theory and hexadecimal color values in detail in Chapter 9, which will cover Android graphic design concepts and principles.

• dimens.xml: An XML file that defines dimension constant values like standard screen dimensions, or font sizes for your UI. You can then use these values across your app, to ensure it is consistent.

• strings.xml: An XML file that defines text (known as “strings” in Java) values that are used in your application. For example, you can place your screen titles, menu options, or your app name, here, and reference these text constants in your code. If you need to change or refine these items in the future, you simply do it in this one central location, rather than in your Java code or XML markup.

• styles.xml: An XML file that defines UI design styles that you’ll use across your application. These styles constants will be applied to the UI elements, which will then reference these styles constant definitions, allowing you to separate the look and feel of your app from the physical layout and UI functionality. This makes your app easier to refine, change, and enhance stylistically over time.

Some of the other types of value constant XML definition files that you could later create, and locate, in your Android project’s app/res/values/ folder would include the following data value constant types:

• arrays.xml: An XML file that defines any series of data value constants that are intended to be utilized together (known in Java as an array) in your application. For example, this could be a list of icon files, a list of graphic layers, a list of menu items, or a list of options to display to the user.

• integers.xml: An XML file that defines numeric integer constant values that will be used in your Java programming logic for your Android application. We will be covering this topic in Chapter 5.

• bool.xml: An XML file that defines Boolean constant values (true or false) that will be used for the default (initial) setting for logic states (like switches) in your application. Examples of these might include states such as on or off, yes or no, visible or hidden, minimized or maximized, and so forth.

Notice that Android uses certain file name conventions for the different types of XML files in the app/res/values/ folder, adding another level of complexity. It is important to note that you can also create your own customized XML files and file names in this folder, so you are not limited to the constant types that are discussed here. Next, let’s cover the folder names that Android Studio (IntelliJ) did not automatically create for you, and that you can optionally utilize to contain other asset types, such as animation, digital video, digital audio, or custom XML data.

Android Anim Folder: Assets Defining Vector or Tween Animation

Besides frame animation, also known as bitmap animation, or raster animation, Android 7 also supports vector animation, which it terms tween animation. This type of animation is also known in the industry as procedural animation, and is created using Java code or XML markup parameter definitions, rather than by “flipbooking” through a series or collection of bitmap images (like frames of video) to create the illusion of motion.

Whereas bitmap animation in Android uses the BitmapAnimation class, tween animation in Android uses just the Animation class, and thus the proper folder to contain resources or assets related to procedural animation is not the app/res/drawable/ folder, but instead the app/res/anim/ folder, which you will have to create in order to utilize this type of animation in Android. Fortunately, we will be covering this during Chapter 10, so you will create this Android animation resource folder at that time.

Android Animator: Assets for User Interface Property Animation

There is a third type of animation in Android, called property animation, used to animate “properties” also known as “attributes” or “parameters,” for any of your UI widgets, called “Views” in Android, and this can even be done across your entire UI design. You can use this to obtain impressive special effects, especially transitional effects, which will entice your end users and increase your app professionalism. Property animation XML definition files are held in the app/res/animator/ folder, and reference the UI elements that you want to animate, as well as To and From data values that are interpolated between to create a smooth property animation. The reason the folder is called the animator folder is because the Android Java class is called ViewPropertyAnimator.

Android Raw Folder: Pre-Optimized Video and Audio Asset Files

The app/res/raw/ folder in Android OS holds your application’s “raw data.” Raw data in Android is not optimized (touched) in any way by the Android OS, it is simply played back (usually streamed) from this folder “as-is.” This is the folder that you want to contain your new media assets for which you have taken the time to optimize the data footprint (file size) to quality ratio. This would be done outside of Android Studio, using new media software packages like Audacity, GIMP, Inkscape, or Lightworks, all of which you downloaded and installed in Chapter 2.

We’ll be looking at how to create and leverage the app/res/raw/ folder a bit later on in this book during Chapters 11 and 12, where I will cover the Android MediaPlayer and MediaController classes, as well as how to play back digital audio and digital video new media asset resources using this particular raw asset resource folder.

Android XML: Arbitrary XML and Configurations

The last resource folder that you should know about is the app/res/xml/ folder, which is used to contain non-Android XML files that specify data structures or configuration parameters that are for use in your application but which are external to (outside of) the scope of Android-specified XML structures. As you will see during Chapter 4 and the rest of the book, Android defines a great many application components and characteristics using XML, and this (the XML markup) must be done (written or structured) in exactly the correct way or format. This folder usually contains XML files that have nothing to do with the Android app creation process, but that are “parsed” (read) by an Android application using a Resources.getXML() method. We cover Java method calls in Chapter 5.