1 page.title=Drawable Mutations 2 @jd:body 3 4 <p>Android's drawables are extremely useful to easily build applications. A 5 {@link android.graphics.drawable.Drawable Drawable} is a pluggable drawing 6 container that is usually associated with a View. For instance, a 7 {@link android.graphics.drawable.BitmapDrawable BitmapDrawable} is used to display 8 images, a {@link android.graphics.drawable.ShapeDrawable ShapeDrawable} to draw 9 shapes and gradients, and so on. You can even combine them to create complex 10 renderings.</p> 11 12 <p>Drawables allow you to easily customize the rendering of the widgets without 13 subclassing them. As a matter of fact, they are so convenient that most of the 14 default Android apps and widgets are built using drawables; there are about 700 15 drawables used in the core Android framework. Because drawables are used so 16 extensively throughout the system, Android optimizes them when they are loaded 17 from resources. For instance, every time you create a 18 {@link android.widget.Button Button}, a new drawable is loaded from the framework 19 resources (<code>android.R.drawable.btn_default</code>). This means all buttons 20 across all the apps use a different drawable instance as their background. 21 However, all these drawables share a common state, called the "constant state." 22 The content of this state varies according to the type of drawable you are 23 using, but it usually contains all the properties that can be defined by a 24 resource. In the case of a button, the constant state contains a bitmap image. 25 This way, all buttons across all applications share the same bitmap, which saves 26 a lot of memory.</p> 27 28 <p>The following diagram shows what entities are 29 created when you assign the same image resource as the background of 30 two different views. As you can see, two drawables are created but they 31 both share the same constant state, hence the same bitmap:</p> 32 33 <img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 307px; height: 400px;" src="images/shared_states.png" alt="" id="BLOGGER_PHOTO_ID_5331437883277472082" border="0"> 34 35 <p>This state sharing feature is great to avoid wasting memory but it can cause 36 problems when you try to modify the properties of a drawable. Imagine an 37 application with a list of books. Each book has a star next to its name, totally 38 opaque when the user marks the book as a favorite, and translucent when the book 39 is not a favorite. To achieve this effect, you would probably write the 40 following code in your list adapter's <code>getView()</code> method:</p> 41 42 <pre>Book book = ...; 43 TextView listItem = ...; 44 45 listItem.setText(book.getTitle()); 46 47 Drawable star = context.getResources().getDrawable(R.drawable.star); 48 if (book.isFavorite()) { 49 star.setAlpha(255); // opaque 50 } else { 51 star.setAlpha(70); // translucent 52 }</pre> 53 54 <p>Unfortunately, this piece of code yields a rather strange result: 55 all of the drawables have the same opacity:</p> 56 57 <img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 267px; height: 400px;" src="images/all_drawables_changed.png" alt="" id="BLOGGER_PHOTO_ID_5331438978390342066" border="0"> 58 59 <p>This 60 result is explained by the constant state. Even though we are getting a 61 new drawable instance for each list item, the constant state remains 62 the same and, in the case of BitmapDrawable, the opacity is part of the 63 constant state. Thus, changing the opacity of one drawable instance 64 changes the opacity of all the other instances. Even worse, working 65 around this issue was not easy with Android 1.0 and 1.1.</p> 66 67 <p>Android 1.5 and higher offers a very easy way to solve this issue 68 with the new {@link android.graphics.drawable.Drawable#mutate()} method</a>. 69 When you invoke this method on a drawable, the constant state of the 70 drawable is duplicated to allow you to change any property without 71 affecting other drawables. Note that bitmaps are still shared, even 72 after mutating a drawable. The diagram below shows what happens when 73 you invoke <code>mutate()</code> on a drawable:</p> 74 75 <img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 307px; height: 400px;" src="images/mutated_states.png" alt="" id="BLOGGER_PHOTO_ID_5331440144116345074" border="0"> 76 77 <p>Let's update our previous piece of code to make use of <code>mutate()</code>:</p> 78 79 <pre>Drawable star = context.getResources().getDrawable(R.drawable.star); 80 if (book.isFavorite()) { 81 star.mutate().setAlpha(255); // opaque 82 } else { 83 star. mutate().setAlpha(70); // translucent 84 }</pre> 85 86 <p>For convenience, <code>mutate()</code> 87 returns the drawable itself, which allows to chain method calls. It 88 does not however create a new drawable instance. With this new piece of 89 code, our application now behaves correctly:</p> 90 91 <img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 267px; height: 400px;" src="images/correct_drawables.png" alt="" id="BLOGGER_PHOTO_ID_5331440757515573842" border="0"> 92
