1page.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 6container that is usually associated with a View. For instance, a 7{@link android.graphics.drawable.BitmapDrawable BitmapDrawable} is used to display 8images, a {@link android.graphics.drawable.ShapeDrawable ShapeDrawable} to draw 9shapes and gradients, and so on. You can even combine them to create complex 10renderings.</p> 11 12<p>Drawables allow you to easily customize the rendering of the widgets without 13subclassing them. As a matter of fact, they are so convenient that most of the 14default Android apps and widgets are built using drawables; there are about 700 15drawables used in the core Android framework. Because drawables are used so 16extensively throughout the system, Android optimizes them when they are loaded 17from resources. For instance, every time you create a 18{@link android.widget.Button Button}, a new drawable is loaded from the framework 19resources (<code>android.R.drawable.btn_default</code>). This means all buttons 20across all the apps use a different drawable instance as their background. 21However, all these drawables share a common state, called the "constant state." 22The content of this state varies according to the type of drawable you are 23using, but it usually contains all the properties that can be defined by a 24resource. In the case of a button, the constant state contains a bitmap image. 25This way, all buttons across all applications share the same bitmap, which saves 26a lot of memory.</p> 27 28<p>The following diagram shows what entities are 29created when you assign the same image resource as the background of 30two different views. As you can see, two drawables are created but they 31both 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 36problems when you try to modify the properties of a drawable. Imagine an 37application with a list of books. Each book has a star next to its name, totally 38opaque when the user marks the book as a favorite, and translucent when the book 39is not a favorite. To achieve this effect, you would probably write the 40following code in your list adapter's <code>getView()</code> method:</p> 41 42<pre>Book book = ...; 43TextView listItem = ...; 44 45listItem.setText(book.getTitle()); 46 47Drawable star = context.getResources().getDrawable(R.drawable.star); 48if (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: 55all 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 60result is explained by the constant state. Even though we are getting a 61new drawable instance for each list item, the constant state remains 62the same and, in the case of BitmapDrawable, the opacity is part of the 63constant state. Thus, changing the opacity of one drawable instance 64changes the opacity of all the other instances. Even worse, working 65around 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 68with the new {@link android.graphics.drawable.Drawable#mutate()} method</a>. 69When you invoke this method on a drawable, the constant state of the 70drawable is duplicated to allow you to change any property without 71affecting other drawables. Note that bitmaps are still shared, even 72after mutating a drawable. The diagram below shows what happens when 73you 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); 80if (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> 87returns the drawable itself, which allows to chain method calls. It 88does not however create a new drawable instance. With this new piece of 89code, 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
