Implementing Images

The way that Android is set up to automatically implement your images via the project folder hierarchy is a bit hard to understand at first. But once you get used to it, you’ll find that it is actually amazingly simple to use graphic resources, as extensive asset reference coding is all but eliminated. You will see this in action in this chapter, as we will implement powerful graphics features using as few as five or six lines of Java programming logic.

I’m not sure what could be much simpler than this: put your imagery into the appropriate project/res/drawable folder, and then reference it by file name in your Java or XML code. Yes, all that you need to do is reference it in your XML and Java code, and you are finished, and with perfect results (assuming that your imagery is optimized correctly, which we are also teaching in this book).

In this chapter, we will look at which image formats to use, which techniques to implement, and which work processes to follow as much as (or more than) we will be dealing with XML attributes and Java code snippets (although these are fun to play with as well).

Core Drawable Subclasses

Android offers more than a dozen types of customized drawable objects. In this chapter, we’ll look at the following core subclasses of android.graphics.drawable:

• BitmapDrawable object : Used to create, tile, stretch, and align bitmaps.
• ColorDrawable object : Used to fill certain other objects with color.
• GradientDrawable object : Used to create and draw custom gradients.
• AnimationDrawable object : Used to create frame-based animations.
• TransitionDrawable object : Used to create crossfade transitions.
• LayerDrawable object : Used to create composited PNG32 bitmaps or WebP bitmaps via multiple image layers.

The most pervasive and often used type of drawable is the bitmap. A bitmapis an image composed of a collection of dots called pixels,where “pix” stands for “pictures” and “els” stands for “elements.” Yes, a bitmap is, quite literally, a map of bits. So, let’s get started with adding bitmaps to your Android apps.

PNG Images

The most powerful file format that Android supports, and the one that it recommends using over all others, is the portable network graphics, or PNG (pronounced “ping”) format. There are two primary types of PNG:

• Indexed-color PNG8, which uses a limited 256-color (8-bits of color allows 256 color values) image palette, which is an index of up to 256 colors that an image uses to make up its pixel colors
• Truecolor PNG32, which uses a 32-bit color image that includes a full 8-bit alpha channel (used for image compositing) and 8-bits each of red, green, and blue image channels, or PNG24 for a truecolor PNG image with no alpha channel included

PNG is known as a lossless image file format because it loses zero image data during the compression processing. This means that the image quality is always 100% maintained. If designers know what they are doing, they can get very high-quality graphics into a reasonably small data footprint by using either the indexed-color PNG8 or the truecolor PNG32 or PNG24 image file formats, depending upon how many colors are using in that image.

Indexed-color PNG8 files use approximately one-fourth of the amount of data (bits) that a truecolor 32-bit RGBA PNG32 image does. Remember the math we did in the previous chapter: 8 × 4 = 32. A smaller data footprint is achieved by using only 8 bits, or a 256-color “palette” of 256 of the most optimal (the most frequently used in the image) colors that are best suited to represent a particular image, but with much the same visual result as if 24-bits (16,777,216 colors) worth of color values were used. This is done primarily to save data file size, thereby decreasing the image’s data footprint (file size) considerably.

Each 8-bit “indexed” color image (PNG8 or GIF) will have its own custom index or palette of colors to use to represent the pixels in that image. More colors can be simulated in 8-bit images by “dithering,” which is a process where fine dot patterns are used between two different colors to simulate an intermediate color (similar to the concept of anti-aliasing that we discussed earlier in the book). This is done to minimize “color banding” in 8-bit images, and dithering is an option in the 8-bit image compression process that can be turned on or off as needed. Dithering adds a small amount of data overhead to the file size, or increases the data footprint slightly, within the resulting file, as more data (the resulting dot patterns) is added to the compressed file, but the visual results are usually well worth the few extra kilobytes.

Truecolor PNG32 images use a full 32 bits of data for each of the image pixels to represent the four image data channels that are found in most bitmap images: alpha channel, red channel, green channel, and blue channel (RGBA or ARGB). If an alpha channel is not used to define image transparency for compositing purposes, then the RGB PNG image would be called a 24-bit PNG24 image, as it uses 24-bits (3 × 8) of data, rather than 32-bits.

The alpha channel determines where the image is going to be transparent and is used for image compositing. As you learned in Chapter 7, compositing is the process of using more than one image in a series of layers to create a final image out of several component layers or parts. Image compositing is so important that Android even has a LayerDrawable, which you learned at the beginning of this chapter, and which you can research farther at: http://developer.android.com/reference/android/graphics/drawable/LayerDrawable.html if you are going to be doing a lot of compositing in your application. We already looked at using layers in GIMP earlier in the book, and this drawable class gives your Android applications this same capability.

Another benefit of image compositing is that in your programming code, you can access different image elements of a composited or layered image independently of other image elements because they are all on their own layer. For example, you might do this for more advanced game engine programming, where what seems to be one image to the game player is actually in fact a series of image layers that composite seamlessly together at run time, via code and clever GIMP or Photoshop compositing work. This allows your Java (and XML) code to grab onto individual image elements without having to use 3D (OpenGL ES) rendering, which is beyond the scope of an introductory book such as this but which we look at in Chapter 12 just so that you know about it.

It is important to note that at compile time, Android looks at your PNG32 (or PNG24) graphics, and if they use less than 256 colors within the image, Android automatically remaps them to be an indexed PNG8 image, just as you would want it to do to save space (app data footprint). This means that you don’t need to worry about analyzing your images to see if they should be in truecolor or indexed-color PNG format. You can simply do everything in truecolor, and if it can be optimized into indexed-color with no loss of data, Android will do that for you—making your data footprint three to four times smaller, depending on if you have used an alpha channel (PNG32 RGBA) or are using only the RGB image channels (PNG24 RGB).

If for some reason you don’t want your images optimized at compile time, you can put them into the project /res/raw folder, which is for data that is accessed directly from your Java code. A good example of this is video files that have been perfectly optimized for size and quality, and just need to be played. This concept will come up in a media player example in Chapter 11, so stay tuned, as we will be using the /raw folder soon enough, I just wanted to point it out here, as it relates to circumventing the mandatory PNG image optimization that Android has implemented into it’s compile-time processing.

JPEG and GIF Images

The next most desirable format to use is the JPEG image file type. This type does not have an alpha channel. It uses lossy compression, which means that it throws away some data to get a much better compression result, but at the expense of your image quality. JPEG stands for joint photographic experts group.

If you look closely at (zoom into, using GIMP) JPEG images, you will see a lot of artifacts, such as areas of strange color variations or what looks like dirt on the image (dirt that was not on the camera lens). JPEG is useful for much higher-resolution (print resolution) images, where artifacts are too small to be seen. So, it is not really as suitable for lower-resolution smartphone screens. JPEG is supported, but is not recommended for Android apps because Google wants their product to look as pristine as possible, and PNG or WebP formats are the sure-fire way to accomplish this.

Finally, we have GIF, the CompuServe graphic information format, a much older 8-bit file format. The use of this file format is discouraged because it has the poorest quality to file size ratio. Stay away from using GIFs for your Android apps if possible. Use PNG8 instead, as it has a superior image compression algorithm that results in a smaller data footprint (file size).

Frame-Based or Cel-Based 2D Animation

Traditional 2D animation involves moving quickly among a number of what originally in the cartoon industry were called cels, or hand-drawn images, creating the illusion of motion. To steal a more modern term from the movie industry, each image, which is a little bit different from the next, is called a frame. This term refers back to the original days of film, where actual film stock would be run through a projector, displaying 24 frames per second (known in the industry as fps).

In Android, frame-based animation is the easiest to implement via XML and gives us great results. You just need to define some basic XML animation attributes—what and where the frames are—in the correct place for Android to find them. Then you can control your animation via your Java code if you need to.

In our example, we are going to animate a solid gold 3D logo. It will circle around smoothly, casting a T-shaped shadow onto the ground. Let’s fire up a new project in Eclipse, and we’ll see how animation works in Android.

1. If you still have the UI_Design project folder open from the previous chapter examples, right-click on that folder, and select Close Project. This closes the project folder in Eclipse (of course, it can be reopened later; as you can see, it’s still there).
2. Select Eclipse File New Project and choose Android Application Project to open the New Android Application Project dialog sequence. Fill it out as follows (and shown in Figure 8-1).
   • Project name : Name this project GraphicDesign.
   • Application name: Let’s call this application GraphicDesign.
   • Package name : Name the package fourth.example.graphicdesign.
   • Build SDK target : Choose Android 4.1 SDK Level 16 (Jelly Bean).
   • Min required SDK version : Enter API Level 8, which matches with the recommended Android 2.2 compatibility build target setting.
   • Create custom launcher icon : Check this box.

   

   Figure 8-1 .  Creating our GraphicDesign Android 4.1 project

3. Now we need to define our animation’s frames in an XML file, which we’ll call logo_animation. Right-click your GraphicDesign folder and select New File. At the bottom of the dialog, enter logo_animation.xml. In the GraphicDesign navigation pane in the middle of the dialog, expose your directory structure (via the arrows next to the folders), and select the /res/drawable folder, so that the parent folder field above shows GraphicDesign/res/drawable-xhdpi. This places our logo_animation XML file in the correct folder. Figure 8-2 shows the completed New File dialog as well as the drop-down menu sequence, together in a single screenshot.

   

   Figure 8-2 .  Creating our logo_animation.xml file in the GraphicDesign/res/drawable-xhdpi folder

   Caution  Because frame-based animation in Android uses bitmap images, you must place the XML file that references these bitmap images into the same folder the images occupy: the /res/drawable folder. Do not put frame animation images or XML specifications into the /res/anim folder. That folder is for transform animation (covered in the next section of this chapter). This is an important difference in how frame-based animations and transform-based or tween animations are set up and created in Android. This is also a very common mistake, as one would assume that all animation-related XML would logically go into the /res/anim/ folder, but this is not in fact the case. Bitmap (frame) animation goes into the /res/drawable/ folders alongside the image assets that it uses, and procedural (vector) animation goes into /res/anim. Memorize this now to avoid hours of frustrating debugging later on!

4. Next, click the logo_animation.xml tab in Eclipse, and type in the following XML markup to define our frame-based animation for Android (Figure 8-3 shows the new file in Eclipse):

 
<animation-list xmlns:android="http://schemas.android.com/apk/res/android "
 android:oneshot="false">
    <item android:drawable="@drawable/logoanim0" android:duration="200" />
    <item android:drawable="@drawable/logoanim1" android:duration="200" />
    <item android:drawable="@drawable/logoanim2" android:duration="200" />
    <item android:drawable="@drawable/logoanim3" android:duration="200" />
    <item android:drawable="@drawable/logoanim4" android:duration="200" />
    <item android:drawable="@drawable/logoanim5" android:duration="200" />
    <item android:drawable="@drawable/logoanim6" android:duration="200" />
    <item android:drawable="@drawable/logoanim7" android:duration="200" />
    <item android:drawable="@drawable/logoanim8" android:duration="200" />
    <item android:drawable="@drawable/logoanim9" android:duration="200" />
</animation-list>

This is pretty straightforward XML tag markup logic here. We add an animation-list tag to hold our frame-based animation image (item) listings. This tag has its android:oneshot attribute set to false, which will allow our seamless animation to loop continuously. Setting oneshot equal to true will stop the animation after one full iteration through the ten files. We’ll try both settings later, so that you can get used to using this important parameter.

Inside of the animation-list tag, we have ten nested item tags (nested because the animation-list closing tag comes after these ten item tags). These specify the location of each image in our /res/drawable-xhdpi folder, where each image is a frame in the animation.

Using each item tag entry, we specify the name and location of each of our ten animation frames logoanim0 through logoanim9, as well as the duration of the frame display time in milliseconds (ms). In this case, we start off using 200 ms, or one-fifth of a second, for each frame, so that the entire animation plays over 2 seconds, and at 5 fps, just barely fast enough to fake movement. We can adjust frame times later, to fine-tune the visual result and to make the animation loop more smoothly and more rapidly.

We need to put our animation frame images into the /res/drawable-xhdpi folder, so that the XML code can reference them successfully. As you know by now, in Android, everything needs to be in the correct place for things to work properly (or at all, for that matter).

1. Copy the ten animation frames into the /res/drawable-xhdpi folder from the code download.
2. Right-click the GraphicDesign folder in the Package Explorer and select Refresh, so that the IDE can see the new animation frame image assets that you have added.
3. If there are still errors on your XML editing pane, right-click your GraphicDesign folder and select Validate to clear these as well. Validate checks and validates your project and all of its code, so it looks one level deeper than Refresh, which just looks at folders to make sure that Eclipse sees all of your resource assets.

At this point, you should see a screen that looks similar to Figure 8-3.

package fourth.example.graphicdesign;
 
import android.os.Bundle;
import android.app.Activity;
import android.view.Menu;
import android.widget.ImageView;
import android.graphics.drawable.AnimationDrawable;
 
public class MainActivity extends Activity {
 
    AnimationDrawable logoAnimation;
     
    @Override 
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
 
        final ImageView logoAnimHolder = (ImageView) findViewById(R.id.imageView1);
        logoAnimHolder.setBackgroundResource(R.drawable.logo_animation);
        logoAnimHolder.post(new Runnable() {
        public void run() {
              logoAnimation = (AnimationDrawable) logoAnimHolder.getBackground();
              }
        } );
    }
    @Override
    public void onWindowFocusedChanged(boolean hasFocus) {
         logoAnimation.start();
    }
    @Override
    Public boolean onCreateOptionsMenu(Menu menu) {
         getMenuInflater().inflate(R.menu.activity_main, menu);
         return true;
    }
}

AnimationDrawable logoAnimation;

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android "
    xmlns:tools="http://schemas.android.com/tools "
    android:id="@+id/relativelayout1"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >
 
    <ImageView
    android:id="@+id/imageView1"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_alignParentTop="true"
    android:layout_centerHorizontal="true"
    android:layout_marginTop="=24dp"
    android:contentDescription="@+string/content_desc" />
</RelativeLayout>

<string name="content_desc">Frame Animation Example</string>

Tween Animation in Android

Tween animation is used for shape-based animation, where shapes are animated from one state to another without specifying the intermediate states. In other words, you define the start and end positions of the shape, and Android fills in the gaps to make the animation work. This shape based animation is sometimes called “Vector Animation” whereas frame based animation would be called “Raster Animation.”

This contrasts with frame-based animation, which uses a sequence of cels, or bitmap images, as the flipbook animations of days gone by. So, frame animation does its work via pixels, while tween animation does its work via transforms that move, rotate, or scale a shape, image, or even text. Thus, tween animation is more powerful than frame-based animation. It can also be used in conjunction with frame-based animation to achieve even more spectacular results.

Tween animation in Android is completely different than frame animation. It is implemented with the set of classes found in the android.view.animation package. These classes represent the true power of tween animation in Android. They include things such as advanced motion interpolators, which define how animation transformations accelerate (or decelerate)  over time; and animation utilities, which are needed to rotate, scale (resize), translate (move), and fade (effect transparency) View objects over time.

“Wait a minute,” you must be musing, “does ‘View objects’ mean that I can apply all of this animation class power to, say, TextViews, for instance? Or even VideoViews?” Indeed it does. If you transform a TextView (rotate it, for instance), and it has a background image, that image is transformed correctly, right along with the text elements of the TextView and all of its settings.

As you might imagine, tween animation definitions can get very complex. This is where the power of using XML to define complicated things, such as transformational animation constructs, becomes very apparent. Again, we thank Android for off-loading work like this from Java coding to XML constructs, so our designers can take care of it for the programmers.

In XML, the tween animation transforms are simply lists of nested tags; they are not usually set up via classes and methods. It is certainly far easier to fine-tune and refine these types of detailed animations via XML line-entry tweaks, rather than inside of the Java code, although you could probably do it that way if you wanted to, once you are an expert Java programmer.

The XML for tween animations goes in an entirely different directory (folder) than frame animation (which goes in /res/drawable). Transform animation XML definitions (files) go in the /res/anim folder.

<set xmlns:android="http://schemas.android.com/apk/res/android "
     android:shareInterpolator="false">
 
    <scale android:interpolator="@android:anim/accelerate_decelerate_interpolator"
          android:fromXScale="1.0"
          android:toXScale="1.4"
          android:fromYScale="1.0"
          android:toYScale="0.6"
          android:pivotX="50%"
          android:pivotY="50%"
          android:fillAfter="false"
          android:duration="700" />
 
    <set android:interpolator="@android:anim/decelerate_interpolator">
        <scale android:fromXScale="1.4"
                android:toXScale="0.0"
                android:fromYScale="0.6"
                android:toYScale="0.0"
                android:pivotX="50%"
                android:pivotY="50%"
                android:startOffset="700"
                android:duration="400"
                android:fillBefore="false" />
 
        <rotate android:fromDegrees="0"
                android:toDegrees="-45"
                android:toYScale="0.0"
                android:pivotX="50%"
                android:pivotY="50%"
                android:startOffset="700"
                android:duration="400" />
    </set>
</set>