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.
Color Transparency(Alpha) Level
Hex Opacity Values
If you want to set 45% to red color.
hex value for red - #FF0000
You can add 73 for 45% opacity in prefix - #73FF0000
Define a color state list
Color state lists can be used as colors, but will change depending on the state of the view they are used for.
To define one, create a resource file in
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.
Define a menu resource and use it inside Activity/Fragment
Define a menu in res/menu
For more options of configuration refer to: Menu resource
For invoking the methods above during showing the view, call
Fragment one additional call is needed:
Colors are usually stored in a resource file named
colors.xml in the
They are defined by
Colors are represented by hexadecimal color values for each color channel
(0 - FF) in one of the formats:
- A - alpha channel - 0 value is fully transparent, FF value is opaque
- R - red channel
- G - green channel
- B - blue channel
Defined colors can be used in XML with following syntax
Using colors in code
These examples assume
this is an Activity reference. A Context reference can be used in its place as well.
In above declaration
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.
Dimensions are typically stored in a resource file names
They are defined using a
You can use different units :
- sp : Scale-independent Pixels. For fonts.
- dp : Density-independent Pixels. For everything else.
- pt : Points
- px : Pixels
- mm : Millimeters
- im : Inches
Dimensions can now be referenced in XML with the syntax
Define integer array
In order to define an integer array write in a resources file
and use it from java like
Integers are typically stored in a resource file named
integers.xml, but the file name can be chosen arbitrarily. Each integer is defined by using an
<integer> element, as shown in the following file:
Integers can now be referenced in XML with the syntax
@integer/name_of_the_integer, as shown in the following example:
Define string array
In order to define a string array write in a resources file
and use it from java like
Define String Plurals
To differentiate between plural and singular strings, you can define a plural in your strings.xml file and list the different quantities, as shown in the example below:
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
Possible quantity values (listed in alphabetical order) are:
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.
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:
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:
You can also access
<string> resources from the java portion of your app. To recall our same
hello_world string from above within an Activity class, use:
Getting resources without "deprecated" warnings
Using the Android API 23 or higher, very often such situation can be seen:
This situation is caused by the structural change of the Android API regarding getting the resources.
Now the function:
should be used. But the
android.support.v4 library has another solution.
Add the following dependency to the
Then all methods from support library are available:
Moreover more methods from support library can be used:
Import array of objects defined in resources
There are cases, where custom objects need to be created and defined in the resources of the application. Such objects can be composed of
Java simple types, for example
Here is the example of how to import an object defined in application resources.
Category constains 3 properties of category:
POJO has it's equivalent in
categories.xml file, where each of array has the same properties defined for each category.
- Create a model for you object:
- Create the file in
- Compose each model consisting of resources:
Define an array in resources file:
Create a function to import them:
String formatting in strings.xml
Defining Strings in the strings.xml file also allows for string formatting. The only caveat is that the String will need to be dealt with in code like below, versus simply attaching it to a layout.
In above example,
'%' 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)
getString() is a method of
Resources, i.e. you can use it directly within an
Activity instance, or else you may use
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.
Working with strings.xml file
A string resource provides text strings for your application with optional text styling and formatting. There are three types of resources that can provide your application with strings:
And to use this string in layout:
Quantity Strings (Plurals)