Creating Our ImageButton Multi-State Image Source Files

Let’s fire up GIMP 2.8, and do that now for each of our four attack mode icons, for each of our four pixel densities required by Android. That’s four attack mode image buttons times four pixel densities, times two button states, and that equals thirty-two different image assets that we need to create. Developing a professional Android app isn’t an easy process by any stretch of the imagination, if you want to do it right.

Add the four image buttons in four pixel densities that we already have, and we’re at 48 images for our four attack mode multi-state buttons. Finally, add another four pixel density assets for our Exit Attack Mode button, and you have 52 separate digital image assets that are needed to implement our Attack a Planet screen, Note that this is not including the background stars.png digital image, which brings the grand total for this one user interface screen to 53 digital image assets needed to create this advanced user interface screen design for each screen density. I thought this was an introductory book! Once we’re at the end of this book, you will find you will have used hundreds of assets developing your Android app!

Once GIMP has launched, use the File Open menu sequence to find your attackinvade 96-pixel graphic in the drawable-XHDPI folder of your Android Hello_World project folder inside your workspace folder.

Let’s set-up GIMP’s working environment first, and use the View Zoom 2:1 menu sequence to set the view to 200%, as is shown in Figure 8-1.

Next, click the Layers tab at the top right (looks like stacked white vellum), so you can see that our image currently has a single layer called attackinvade.png, which is the indexed color PNG8 Soldier’s Face icon image that we just opened.

If you click the Channels tab (a stacked RGB color channels icon), you will see a single indexed color channel that contains our 8-bits of image data. If we add our hoop layer while our image is in indexed color mode, the hoop will only have a few colors with which to use to portray its 3D metal look, and will not look photo-real the way that we want it to. What we need to do is to convert our image into truecolor color mode before we import the next layer for the image compositing functions we’re about to perform.

In GIMP 2.8, the color depth that your image is currently set to use is found in the Image menu under the Mode sub-menu. If you access this Image Mode menu sequence, you will see several key image modes, including RGB (Truecolor mode), Grayscale (Monochrome mode) and Indexed color mode, which as you will see is the currently selected mode (a dot next to that sub-menu entry indicates the current mode).

Let’s change the color mode of our image before we go any further in our work process, so that we get the highest visual results from any additional truecolor image layers that we might add during this process. To change the color depth of the current image from Indexed (8-bit) to RGB (32-bit) color mode, select the Image Mode RGB menu sequence shown in Figure 8-2 to change the image mode from 8-bit to 32-bit color. If we don’t do this, any layer we add will use the 256 color palette for the image, which is taken from the initial image layer (data). This will constrain any future imagery (layers) imported later on to using those 256 colors; this will severely affect our visual quality, especially as we add more layers.

Once we have invoked an Image Mode RGB menu sequence to switch our GIMP image editing environment into Truecolor Mode, we can again click the Channels tab on the right, and see that we have now gone from having one channel, with an indexed color palette of 256 colors for our image, to an image editing situation where we have four color channels (or three color channels and a transparency channel). This is shown in Figure 8-3, and since our layer was selected (highlighted in blue) for use in Figure 8-1, so too are our four channels selected to maintain this selection from the Layer Editing Mode (tab) to the Channel Editing Mode (tab).

Image editing software is modal, that is, whatever tool, color, and editing modes are set and active at any given point affect what happens when you use the current tool on your image. Thus, if you are in Layer Mode, and you edit the image in Layer Mode, it will affect data on all the channels in your image. However, if you want to edit the data on just the Green Channel of the image, you can switch into Channel Editing Mode to do this, by clicking the Channels tab and the Green Channel before you use those editing tools (any editing tool can be used in any mode).

This modal software operation is much more powerful in its ability to combine software features into any toolset the user wants to create. Thus, it yields more professional results, but it is also far more difficult to use effectively. The user must always keep track of what modes, settings, and tools are currently active at any given time during the use of a modal software package. These editing modes, tools, and settings combine in real-time to ultimately create the exact editing function that is being used.

Importing Our Gold Hoop Image for Compositing

Now we are ready to get down to business and import our golden hoop image into its own layer to set up our image compositing operation. To do this, we are going to use GIMP’s File Open as Layer… menu sequence, as shown in Figure 8-4. This will, as the tool-tip tells us, open up an image file as a layer in our Layers tab. Once you select this menu option, you get a dialog that lets you find the image asset named GoldHoop96.png, which is a truecolor PNG32 file with an alpha channel defining transparency.

After you select this file to open it, it is merged into the project as its own layer in the Layers tab. The Channels tab shows the merged RGBA channel data, as shown in Figure 8-5, and your image view shows the golden hoop seamlessly composited over the soldier’s face. Next, we need to move this new layer containing the soldier’s face down, so that the face moves into the center of the hoop. We do this so that it looks like our soldier is looking through the hoop, and so that the eyes are not covered. It is important to note that GIMP uses RGBA channel ordering, whereas Android uses ARGB, that is, when specifying channels in hexadecimal in Android, the first two positions are the alpha value, not the last two positions, as someone who works with Photoshop or GIMP might simply assume.

Centering Our Soldier’s Face in the Gold Hoop by Moving Its Layer Position

To move the face layer down into the hoop, select the lower layer with the face graphic, as shown in blue in Figure 8-6, and then also click the Move tool (a four-arrow cross, located in the second row, middle) to set the modal editing operation to move (move tool mode) the attackinvade layer (layer editing mode).

Once you do this, you can take your mouse and click and drag the face straight down into the center of the hoop, and then, if you like, you can use the left and right arrow keys on your keyboard to nudge the image into place, one pixel at a time. This fine-tunes your image centering operation, until the resulting composited image looks like it does in Figure 8-6.

Erasing the Unwanted Pixels Outside the Gold Hoop

Now, all we have to do is to select the Eraser tool shown in Figure 8-7 (fourth row down second icon) to put GIMP into Erase Mode and erase the parts of the soldier’s face and shirt that are outside of the hoop. Note that we are keeping the bottom (face) layer selected, so our image editing software modes include: Erase Tool Mode, RGB Truecolor Mode, and Layer Editing Mode set to the attackinvade.png imagery layer (which applies Eraser tool editing to all four channels at the same time for imagery on that layer only).

Exporting Our attackinvadepress Button Icon State

Now, we are ready toexport our attackinvadepress button icon state into our drawable-xhdpi folder, and two of our three image state buttons (Normal and Pressed) will be ready to implement in XML code.

To do this, we use GIMP’s File Export menu sequence, name the file attackinvadepress.png, and finally, locate our workspace/Hello_World/res/drawable-xhdpi folder where we want to save this 96-pixel high-resolution (extra-high density pixel image) digital image file. After all this filename, folder pathname, and image type (.png extension) info has been specified in the GIMP Export Image dialog, you can then click the Export button to complete this operation, as shown in Figure 8-8.

Note that because our GIMP Color Depth Mode is set to truecolor RGB that we are now exporting PNG32 truecolor PNG files with an alpha channel, but our file size has only doubled, from 8K to 16K, because we removed (erased) a lot of image data, and because the PNG32 compression algorithm is very efficient.

It is almost always desirable to use a PNG32 format over a PNG8 format if you can get the data footprint well-optimized, because the level of quality of the image data, as well as alpha channel, are considerably better (far more colors and more transparency values are utilized) in a PNG32 file than in a PNG8 file.

Creating Our attackinvadefocus Image Button State

Finally, we need to create our attackinvadefocus image button state. This is much easier, as much of our image editing work process for this third button state has already been accomplished for our attackimagepress image button state, including changing the image mode, moving the soldier’s face, and erasing pixels outside of the hoop perimeter. All we have to do now is to add a silver hoop to show focus.

Use the File Open as Layer… function, shown in Figure 8-4, to add another layer to our image compositing stack, by finding the SilverHoop96.png image, and importing it into our GIMP 2.8.4 project.

Because the result looks great, as shown in Figure 8-9, we can proceed to again use our File Export work process, shown in Figure 8-8, only this time, use the filename: attackimagefocus.png, and use the same drawable-xhdpi folder location, as this is a 96-pixel extra-high density pixel image file.

Creating Our Other Resolution Density Multi-State ImageButton Icons

To create the other three size (80, 64 and 48 pixels) versions of attackinvadepress and attackinvadefocus, follow the work process outlined in the previous chapter in Figure 7-17 using the Image Scale Image… menu sequence, and image scaling dialog, to uniformly scale the images from 96 to 80 (and later 96 to 64 and 96 to 48) pixels. Be sure during each work process to click the eye icon on the SilverHoop96 layer to turn off its visibility, then use File Export to save the file in drawable-hdpi as attackinvadepress.png.

Once that is done, you can click the eye icon again to turn the SilverHoop96 layer visibility back on, and execute the File Export operation again, to create an attackinvadefocus.png in your drawable-hdpi folder. Once you have generated these two files, use the Edit Undo menu sequence to go back to your 96-pixel version, and do the entire work process outlined here to create 64-pixel MDPI and 48-pixel LDPI invade icon assets. It is important to note that the focus button state is not used on Android devices that have touchscreen only (such as our Nexus S emulator). This focused state is only used on Android devices that utilize a trackball, keypad, or keyboard navigation. Once a user touches the touchscreen (if the device has one), Android goes into touch mode, and in this mode of operation the focus button state is not used, but it is still installed and works on other Android device types (such as iTVs) that don’t use touchscreen.

Creating a New Android XML File of Resource Type: Drawable

The first thing that we want to do is to create a New Android XML File. Right-click your Hello_World project’s drawable-xhdpi folder, and then select the New Android XML File creation wizard dialog. This dialog is shown in Figure 8-10, and automates XML file creation for you.

Set the Resource Type to Drawable and the Project to Hello_World and name the File:  attack_invade. Since Android does not use file extensions in XML and Java code, be sure not to name the file attackinvade as that is our PNG8 filename. Because underscores are allowed in Android file names, use an underscore between the words attack and invade, to simulate a space character between those words.

Next, find the Root Element named selector, and select that for our parent tag (root element) container, and finally click the Finish button to create the attack_invade.xml file. It’s important to note in Figure 8-11 that Android put the attack_invade.xml file in a /res/drawable/ folder, which it created as part of the New Android XML File operation. This is because the file references multiple resolution assets, so it goes once in the /res/drawable folder instead of in each drawable-dpi folder.

Adding Android <item> Tags to our attack_invade.xml Multi-State XML Definition

Now that we have our attack_invade.xml file open in our editing pane, let’s add the three <item> tags that specify our three image states. The item tags contain one parameter for state definition and another for drawable asset definition. The pressed and focused multi-state item tags are coded like this:

<item android:state_pressed="true" android:drawable="@drawable/attackinvadepress" />
<item android:state_focused="true" android:drawable="@drawable/attackinvadefocus" />

The default or normal button state item tag does not have a multi-state parameter, it just has the image’s drawable asset reference parameter, and this <item> tag is added in last, as can be seen in Figure 8-11.

The order of these <item> tags in the selector container is important in this case, because that is the order in which these items are evaluated, much like the select (case) statement we used in our Java code.

Referencing Our New Multi-State ImageButton XML Definitions from Our Activity Screen Layout XML

The last thing that we need to do is open the tab for our activity_attack.xml user interface screen layout definition, and change the reference for the attackinvade button to point to attack_invade (XML) instead of attackinvade (PNG). This is so the chain of logic that Android goes through to implement the ImageButton now includes the multi-state XML selector logic in how it processes the use of that user interface element.

To implement the other three bomb, virus, and laser attack mode multi-state buttons, we must go through the work process shown in Figures 8-10 and 8-11 three more times, adding in XML <selector> definitions for attack_bomb.xml, attack_virus.xml, and attack_laser.xml multi-state image asset definition XML files.

Each of the selector XML files must point to the proper PNG8 (normal) and PNG32 (presses and focused) digital image asset filenames in the drawable sub-folders, and then we can reference these new XML file definitions in our activity_attack XML file, instead of referencing the default image state PNG8 filename.

Once all this work process is completed for each of our four attack mode buttons, our Attack a Planet user interface screen will be fully converted to feature multi-state ImageButton user interface elements!

Remember that when you test the user interface screen next using the Nexus S emulator that the focused image state does not show, as that Android device that we are emulating is a consumer electronics product that features a touchscreen only.

Figure 8-12 shows an Eclipse IDE with the XML files in the /res/drawable folder in the Package Explorer pane (highlighted in blue) for the attack_bomb, attack_invade, attack_laser, and attack_virus files that we just created (also notice the tabs for these files still open at the top of the Eclipse primary editing pane).

The XML mark-up for our activity_attack user interface screen definition in Figure 8-12 also shows that we have changed all the android:src parameters for each of our ImageButton tags to point to the XML filenames, which use an underscore in the middle of each filename, instead of pointing to the PNG8 filenames, which do not use an underscore character in the middle.

Finally, we need to test the application, and our new multi-state ImageButton user interface elements, via the Run As Android Application work process. Launch a Nexus S emulator and click the Soldier Face icon for Invade a Planet, and you will see that the face moves into the center of the hoop when you click and hold down (via a mouse-down operation) the left mouse button, as shown in Figure 8-13.

Be sure and also test all four of your attack mode button icons, to make sure that you have implemented all your activity XML mark-up and your <selector> XML mark-up and digital imagery references correctly.

Now it’s time to take our Configure Planet user interface screen to a more professional level, by adding a space-related background image, and then changing how our user interface elements composite over that new colliding galaxies image, so that we enhance the contrast ratio (readability) for this new UI Design.

Modifying Our activity_config XML Parameters to Composite Space Background Image with Our UI Elements

The first thing we want to do in our activity_config.xml file is to add an android:background parameter that points to our newly installed space.png files, using the @drawable/space reference parameter, as shown in Figure 8-14. If you click on the Graphical Layout tab at the bottom of the editing pane after you add in the new digital image background, you will see that our existing user interface elements have essentially disappeared, and so we’ll have to make some fairly drastic parameter changes to our current XML mark-up to make our UI look really professional with this space background.

Let’s start with the Button tags, and add in an android:textColor parameter, set to the hexadecimal value for white of #FFFFFF, as is shown in Figure 8-14. Once again, let’s use the Graphical Layout tab as a quick and easy screen preview, and see if our buttons have become easier to read. As you can see in Figure 8-15 this solves the problem for the Button UI elements, and they look great. However, the EditText text fields are nearly impossible to discern, and these will require a number of new tag parameters to make them both readable and ultimately professional in appearance.

Improving the Contrast of Our EditText Fields Using Background Color and Alpha Transparency

To make our EditText text editing fields work with this amazing colliding galaxy background we will have to use a combination of bright background colors (white), some opacity (alpha channel) to allow the stars to shine through, and some better fonts, alignment and edit text field spacing to match (balance out) the button spacing on the opposite side of the screen layout.

The first EditText tag parameter we will want to add, so that we can see what we are doing on this dark background, is the android:background parameter, which we will set to the hexadecimal color value for white (#FFFFFF). To make this white background somewhat translucent, let’s also add an android:alpha parameter, which controls opacity (alpha channel value) for the UI element using a decimal range of Zero (transparent) to One (opaque). We use a 50% transparent setting of 0.5 to start off with. Now that we can see our text fields, we can next adjust our android:layout_marginTop parameter to space them out.

For the first EditText tag this equates to 13dp and the rest require an additional 10 dp, or a final setting of 23dp, to space them perfectly opposite each button, as you can see in the XML mark-up in Figure 8-16.

So now that our text fields are perfectly spaced out from top to bottom opposite each of their respective buttons, we need to space them out from left to right. They are touching the right-hand side of the UI screen and this looks unprofessional. Let’s adjust this to add some symmetry to the UI screen design.

Because we want to move all the EditText fields an even distance of 5dp, similar to the spacing on our buttons on the opposite side of the screen, let’s do that with a single tag in the LinearLayout container that holds them, instead of adding a half-dozen tags (one in each EditText element tag).

Once you add the android:layout_marginRight=“5dp” as shown in Figure 8-16, hit your Graphical Layout tab, and see how it looks. To get an even more precise look as to how it will all line up, use the Run As Android Application work process and look at the current UI design in the Nexus S emulator; you will see that it is starting to look truly amazing.

Formatting the Text Characteristics Inside Our EditText UI Elements

Now that we have the EditText UI container spaced out and composited perfectly with the screen and its background image, let’s set some parameters to optimize the text that is contained within that text field. For the numeric data entry text fields let’s specify a monospace font, which makes numeric entries especially readable; this is accomplished via the android:typeface=“monospace” parameter.

To make the text a bit more readable on the screen let’s also add an android:textStyle parameter, setting the font to use bold text to make the characters thicker and easier to read on smaller displays. Finally, to make the text look evenly spaced within the text field and be symmetrical on the right side of the display, let’s use a center parameter to center the text within each EditText data entry field. This is accomplished by using an android:gravity parameter set to center or android:gravity=“center” mark-up. The Android gravity parameter centers just about anything in Android, not just text, so become familiar with this parameter, and look for it in other types of user interface widgets and tags, as gravity can be very useful.

Now it’s time to use our Run As Android Application work process and to preview the outcome of all this user interface element tag parameter modification and optimization in the Nexus S emulator. As you can see in Figure 8-17, the Configure Activity user interface screen is really starting to look professional.

Next let’s take our Hello World application Home Screen to the next level by adding custom background imagery and an ImageView of the planet we’re on. We will customize these later on in the Animation chapters. Finally, we’ll color our text to match dazzling plasma light colors in a galaxy background image.

Creating Our Activity Screen Title Constants in the strings.xml File

Click the number in the top right of the Eclipse central editing pane (in Figure 8-23 it is 14) to drop-down the open files menu. Next, select the strings.xml file for editing, and change the app_name text value to Hello World - Home Screen. Copy and paste that <string> tag underneath itself four more times, so we can add titles (labels) for each of our four application Activity user interface screens.

Name each <string> tag constant with the name=“activity_title_type_planet” parameter and with the text value Hello World - Screen Title, for instance, a <string> tag for the NewPlanet Activity would look like:

<string name="activity_title_new_planet">Hello World - Create a Planet</string>

The five resulting <string> constant tags to label our app Activity screen titles can be seen in Figure 8-23.

Configuring Activity Screen Labels in Our Hello_World AndroidManifest XML File

Once we have our string constants defined and in place in the strings.xml file, we can then reference them from our AndroidManifest.xml file, which is where we are going to set up the android:label parameters for each of our Activity screens, which will install a custom screen title at the top of each Activity.

Click the number in the top right of the Eclipse central editing pane (in Figure 8-23 it is 14) to drop-down the open files menu. Next, select the AndroidManifest.xml file for editing and change the current android:icon parameter in the <application> tag to reference an @drawable/helloworldicon reference, which is the reference to our new Saturn icon image PNG file.

Next, in each of our <activity> tags add a new android:label parameter that references the new <string> tag constants that we just created by name via @string/activity_title, as shown in Figure 8-24.

For the NewPlanet.java Activity user interface screen, the parameter to place a custom title at the top of the application is android:label=“@string/activity_title_new_planet” which is fairly straight forward, once you know where Android wants you to put everything. So using the NewPlanet Activity <activity> tag as an example, the entire <activity> tag with the name and label parameters would look like this:

<activity android:name="chapter.two.hello_world.NewPlanet"
          android:label="string/activity_title_new_planet" />

Now let’s use the Eclipse Run As Android Application command, and launch the Nexus S emulator and see how the new icon and screen title looks at the top of our application. As you can see in Figure 8-25 the results are professional and an improvement over the previous screen title (Hello_World) and app icon (Android Bot) as they are now more specific to what our app is and what it is doing.

Click the Menu button in the upper-right of the Nexus S emulator and let’s see what our Activity UI screens look like with their new icons and screen titles. As you can see in Figure 8-26, our screens (the three that we have finished, the fourth TravelPlanet Activity screen we are going to implement in future Chapters 11 and 12 covering Digital Video) look great, and look far more custom and professional due to this attention to UI detail.

Note that by using this android:label parameter to create our Activity screen title, we don’t have to use a TextView UI element at the top of our screen container, so we only need a TextView on two of the screens to instruct the user what to do when they get to the screen. On the Configure Planet UI screen, our button labels call the user to action, and thus we require no TextView UI elements on that screen at all.

Also notice that our Activity user interface screen titles (labels) closely match our Options Menu Labels, thus providing the user with excellent continuity throughout the application user interface infrastructure.

Now that we have the basic graphics elements composited together with our application’s user interface elements, we can proceed to implement more advanced new media elements such as Animation, Digital Audio, and Digital Video over the next several chapters.