Game Development Reference
In-Depth Information
We saw in Chapter 1 that devices come in different sizes, but we didn't talk about how Android
handles those different sizes. It turns out that Android has an elaborate mechanism that allows
you to define your graphical assets for a set of screen densities.
Screen density
is a combination
of physical screen size and the number of pixels of the screen. We'll look into that topic in more
detail in chapter 5. For now, it suffices to know that Android defines four densities:
ldpi
for
low-density screens,
mdpi
for standard-density screens,
hdpi
for high-density screens, and
xhdpi
for extra-high-density screens. For lower-density screens, we usually use smaller images; and for
higher-density screens, we use high-resolution assets.
So, in the case of our icon, we need to provide four versions: one for each density. But how big
should each of those versions be? Luckily, we already have default icons in the
res/drawable
folders that we can use to re-engineer the sizes of our own icons. The icon in
res/drawable-
ldpi
has a resolution of 36×36 pixels, the icon in
res/drawable-mdpi
has a resolution of 48×48
pixels, the icon in
res/drawable-hdpi
has a resolution of 72×72 pixels, and the icon in
res/
drawable-xhdpi
has a resolution of 96×96 pixels. All we need to do is create versions of our
custom icon with the same resolutions and replace the
icon.png
file in each of the folders with
our own
icon.png
file. We can leave the manifest file unaltered as long as we call our icon image
file
icon.png
. Note that file references in the manifest file are case sensitive. Always use all
lowercase letters in resource files, to play it safe.
For true Android 1.5 compatibility, we need to add a folder called
res/drawable/
and place the
icon image from the
res/drawable-mdpi/
folder there. Android 1.5 does not know about the
other
drawable
folders, so it might not find our icon.
Finally, we are ready to get some Android coding done.
For Those Coming from iOS/Xcode
Android's environment differs greatly from that of Apple's. Where Apple is very tightly controlled,
Android relies on a number of different modules from different sources that define many of the
APIs, control the formats, and dictate which tools are best suited for a specific task, e.g. building
the application.
Eclipse/ADT vs. Xcode
Eclipse is a multiproject, multidocument interface. You can have many Android applications in
a single workspace, all listed together under your Package Explorer view. You can also have
multiple files open from these projects all tabbed out in the Source Code view. Just like forward/
back in Xcode, Eclipse has some toolbar buttons to help with navigation, and even a navigation
option called Last Edit Location that will bring you back to the last change you made.
Eclipse has many language features for Java that Xcode does not have for Objective-C.
Whereas in Xcode you have to click “Jump to definition,� in Eclipse you simple press F3 or click
Open Declaration. Another favorite is the reference search feature. Want to find out what calls
a specific method? Just click to select it and then either press Ctrl+Shift+G or choose Search
➤ References ➤ Workspace. All renaming or moving operations are classified as “Refactor�
operations, so before you get frustrated by not seeing any way to rename a class or file, look at
the Refactor options. Because Java does not have separate header and implementation files,
there is no “jump to header/impl� shortcut. Compiling of Java files is automatic if you have
