teaching machines

CS 491 Lecture 4 – Ketchup

September 15, 2011 by . Filed under cs491 mobile, fall 2011, lectures.

Agenda

Autoporting

A major feature of Android market is that you can sell your apps to people all over the world and probably in the ISS too. However, English is spoken by about only a quarter of the people on Earth. (Don’t ask for a source.) When your app gets downloaded by a non-English speaker, what’s going to happen?

Android comes to the rescue here. By pushing your text and other resources out to specially-named resource directories, the system will sample the ones that match the current configuration. These directories are named things like values-en (for English text), values-es (for Spanish text), drawable-ja (for Japanese images), and drawable-xdpi (for images on real high-density screens). When you reference your resources through their identifiers (R..), you will get the resource for the current configuration automatically, without resorting to a mess of conditional statements.

(Of course, messes still occur in the resource directory. You might need a drawable-port-notouch-12key directory, which holds images for portrait-oriented devices lacking a touch screen and only having a number pad input. Blech.)

Let’s add a little welcome Toast to our PopMusic app with something like:

Toast.makeText(this, R.string.instructions, Toast.LENGTH_LONG).show();

Now, let’s define the instructions string in two places. First, in values/strings.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>
  <string name="greeting">Pop some bubbles!</string>
</resources>

The unadorned directories like values and drawable are considered the defaults. The default directories should have definitions for every resource. Otherwise a resource might end up undefined and your app will fail.

Now, let’s place this in values-es/strings.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>
  <string name="greeting">¡Estalle algunas pompas!</string>
</resources>

Now if we had chosen to handle locale changes ourselves, we’d have to manually reconfigure everything that depended on resources. Otherwise, we’d still be referencing resources from the previous configuration.

Another common configuration we can support are different screen densities or sizes. My Asus Transformer will pull drawables from drawable-xlarge, if available, so let’s make some bigger bubble images and drop them in there.

Ketchup

A student suggested we write a Catchphrase-like game. We should inform each other of the rules and then draft a specification of what the app should look like. Once again, you’ve got five minutes. And don’t use the word Catchphrase.


XML Layout

Let’s assemble the main game screen for our game. We’ll do what we can to make this module reasonably independent of the other components of the game. For now, we’re going to use LinearLayouts, which allow vertical stacks and horizontal lines of views. Later on we may discover that an alternate layout may simplify things.

[code-code-code]

What happens with our layouts (all resources, really) is that a tool called aapt will compile them down into a binary form and they’ll be packaged up into the *.apk file. This tool also generates the class R, which contains the IDs of all the resources we include and views we define. Through the IDs found in R, we retrieve the view or resource dynamically according to the current configuration.

Defining interfaces declaratively takes some getting used to. The Eclipse plugin at least alleviates some of the XML generation.

To hook up our XML-defined views to our code, we use the ID. For example, in our Activity’s onCreate method, we can make a reference to an ImageView with something like:

ImageView imageView = (ImageView) findById(R.id.picture);

It’s important that you only call findById after you’ve called setContentView, as findViewById will only look for the view in the currently registered view hierarchy.

Dialogs