Resources

9 Patches

9 Patches are stretchable images in which the areas which can be stretched are defined by black markers on a transparent border.

There is a great tutorial here.
Despite being so old, it's still so valuable and it helped many of us to deeply understand the 9 patch gear.

Unfortunately, recently that page has been put down for a while (it's currently up again).

Hence, the need to have a physical copy of that page for android developers on our reliable server/s.

Here it is.

A SIMPLE GUIDE TO 9-PATCH FOR ANDROID UI May 18, 2011

While I was working on my first Android app, I found 9-patch (aka 9.png) to be confusing and poorly documented. After a little while, I finally picked up on how it works and decided to throw together something to help others figure it out.

Basically, 9-patch uses png transparency to do an advanced form of 9-slice or scale9. The guides are straight, 1-pixel black lines drawn on the edge of your image that define the scaling and fill of your image. By naming your image file name.9.png, Android will recognize the 9.png format and use the black guides to scale and fill your bitmaps.

Here’s a basic guide map:

As you can see, you have guides on each side of your image. The TOP and LEFT guides are for scaling your image (i.e. 9-slice), while the RIGHT and BOTTOM guides define the fill area.

The black guide lines are cut-off/removed from your image – they won’t show in the app. Guides must only be one pixel wide, so if you want a 48×48 button, your png will actually be 50×50. Anything thicker than one pixel will remain part of your image. (My examples have 4-pixel wide guides for better visibility. They should really be only 1-pixel).

Your guides must be solid black (#000000). Even a slight difference in color (#000001) or alpha will cause it to fail and stretch normally. This failure won’t be obvious either*, it fails silently! Yes. Really. Now you know.

Also you should keep in mind that remaining area of the one-pixel outline must be completely transparent. This includes the four corners of the image – those should always be clear. This can be a bigger problem than you realize. For example, if you scale an image in Photoshop it will add anti-aliased pixels which may include almost-invisible pixels which will also cause it to fail*. If you must scale in Photoshop, use the Nearest Neighbor setting in the Resample Image pulldown menu (at the bottom of the Image Size pop-up menu) to keep sharp edges on your guides.

*(updated 1/2012) This is actually a “fix” in the latest dev kit. Previously it would manifest itself as all of your other images and resources suddenly breaking, not the actually broken 9-patch image.

The TOP and LEFT guides are used to define the scalable portion of your image – LEFT for scaling height, TOP for scaling width. Using a button image as an example, this means the button can stretch horizontally and vertically within the black portion and everything else, such as the corners, will remain the same size. The allows you to have buttons that can scale to any size and maintain a uniform look.

It’s important to note that 9-patch images don’t scale down – they only scale up. So it’s best to start as small as possible.

Also, you can leave out portions in the middle of the scale line. So for example, if you have a button with a sharp glossy edge across the middle, you can leave out a few pixels in the middle of the LEFT guide. The center horizontal axis of your image won’t scale, just the parts above and below it, so your sharp gloss won’t get anti-aliased or fuzzy.

Fill area guides are optional and provide a way define the area for stuff like your text label. Fill determines how much room there is within your image to place text, or an icon, or other things. 9-patch isn’t just for buttons, it works for background images as well.

The above button & label example is exaggerated simply to explain the idea of fill – the label isn’t completely accurate. To be honest, I haven’t experienced how Android does multi-line labels since a button label is usually a single row of text.

Finally, here’s a good demonstration of how scale and fill guides can vary, such as a LinearLayout with a background image & fully rounded sides:

With this example, the LEFT guide isn’t used but we’re still required to have a guide. The background image don’t scale vertically; it just scales horizontally (based on the TOP guide). Looking at the fill guides, the RIGHT and BOTTOM guides extend beyond where they meet the image’s curved edges. This allows me to place my round buttons close to the edges of the background for a tight, fitted look.

So that’s it. 9-patch is super easy, once you get it. It’s not a perfect way to do scaling, but the fill-area and multi-line scale-guides does offer more flexibility than traditional 9-slice and scale9. Give it a try and you’ll figure it out quickly.

Items are evaluated in the order they are defined, and the first item whose specified states match the current state of the view is used. So it's a good practice to specify a catch-all at the end, without any state selectors specified.

Each item can either use a color literal, or reference a color defined somewhere else.

In above declaration colorPrimary, colorPrimaryDark and colorAccent are used to define Material design colors that will be used in defining custom Android theme in styles.xml. They are automatically added when new project is created with Android Studio.

Define dimensions

Dimensions are typically stored in a resource file names dimens.xml.
They are defined using a <dimen> element.

This definition can be accessed from Java code by using the getQuantityString() method of the Resources class, as shown in the following example:

getResources().getQuantityString(R.plurals.hello_people, 3, 3);

Here, the first parameter R.plurals.hello_people is the resource name. The second parameter (3 in this example) is used to pick the correct quantity string. The third parameter (also 3 in this example) is the format argument that will be used for substituting the format specifier %d.

Possible quantity values (listed in alphabetical order) are:

few
many
one
other
two
zero

It is important to note that not all locales support every denomination of quantity. For example, the Chinese language does not have a concept of one item. English does not have a zero item, as it is grammatically the same as other. Unsupported instances of quantity will be flagged by the IDE as Lint warnings, but won't cause complication errors if they are used.

Define strings

Strings are typically stored in the resource file strings.xml. They are defined using a <string> XML element.

The purpose of strings.xml is to allow internationalisation. You can define a strings.xml for each language iso code. Thus when the system looks for the string 'app_name' it first checks the xml file corresponding to the current language, and if it is not found, looks for the entry in the default strings.xml file. This means you can choose to only localise some of your strings while not others.

Once a string is defined in an XML resource file, it can be used by other parts of the app.

An app's XML project files can use a <string> element by referring to @string/string_name. For example, an app's manifest (/manifests/AndroidManifest.xml) file includes the following line by default in Android Studio:

android:label="@string/app_name"

This tells android to look for a <string> resource called "app_name" to use as the name for the app when it is installed or displayed in a launcher.

Another time you would use a <string> resource from an XML file in android would be in a layout file. For example, the following represents a TextView which displays the hello_world string we defined earlier:

In above example,
%1$s '%' separates from normal characters,
'1' denotes first parameter,
'$' is used as separator between parameter number and type,
's' denotes string type ('d' is used for integer)

Note that getString() is a method of Context or Resources, i.e. you can use it directly within an Activity instance, or else you may use getActivity().getString() or getContext().getString() respectively.

Translate a string

Strings can be internationalised by defining a different strings.xml for each language you support.

You add a new language by creating a new values directory with the ISO language code as a suffix. For example, when adding a German set your structure might look like follows:

When the system looks for the requested string it first checks the language-specific xml, if it is not found, the value from the default strings.xml file is returned. The key remains the same for each language and only the value changes.