9-patch: bad patches everywhere…
You’ve created a nice, little 9-patch…
It’s working beautifully on your device. Even Android Studio ensures you that it can be scaled perfectly:
But if you get enough courage up to click this one, little, devilish check box…
… you’ll end up seeing this:
If it’s already been a few times that you’ve used different 9-patch images, you’ve most certainly seen those scary red borders a few times as well. Why do they appear? What is this twisted game Android Studio is playing with us — showing it can scale the 9-patch correctly but saying our patches are bad?
If you came here because you were expecting a 9-patch tutorial, it’s not the right place for you. I’m not gonna explain what 9-patch does, how useful it can be, other people did this before me and did it well. If you’re completely new to the concept head straight for the 9-patch bible - Radley’s simple guide to 9-patch. Others: follow me.
Bad patches starter pack
a few things you need to know before starting the journey into the amazing world of bad patches
Just to get our terms straight: there are 4 guides/markers/lines. One on each side of the image. They create two pairs, that define two areas:
Any future references to left and top or scaling guides should be understood as about those that define scalable area. References to right and bottom or filling guides are about those that specify fill area. Although there probably won’t be many references to fill area because:
Bad patches only apply to scalable area. A bad patch is a:
Bad patches indicate that the stretching process might cause unexpected results. Fill area is not responsible for the stretching of the image, it specifies the way the image is filled with content. Filling guides do not matter at all, at this point. And a simple proof of that can be this:
There is absolutely no correlation between any of those bad patch boxes and right or bottom guide. From now on (until the end of this explanation) you can completely ignore fill area markers. Pay attention only to the left and top markers. I will keep filling guides in all of my illustrations, just not to confuse anybody, but I will try to make them as meaningless as I can.
Logic behind bad patches
The one thing you really need to understand is the way Android Studio decides whether it should show the bad patch or not. And that is actually not that complicated.
First, the whole scalable area needs to be divided into slices (at least I call them that way), or even more so - into groups of slices.
Intersections of both horizontal (specified by the left marker) and vertical (specified by the top marker) scalable areas define (slice) groups.
In my example there are exactly 8 groups (from A to H):
Horizontal scalable area should be divided into 1 pixel height rows (horizontal slices):
Vertical scalable area (specified by the top marker) should be divided into 1 pixel width columns (vertical slices):
Android Studio checks if all slices within a slice group are the same. If there’s even a slightest difference between those slices — the slice group becomes a bad patch (and gets a beautiful, red stroke). And I really mean “even a slightest difference”. From the Android Studio perspective, those colors are completely different:
Any difference, even if you can’t see it with your bare eye, must be spotted. Android Studio is not able to tell if a particular inequality produces wrong results from the 9-patch scaling point of view, or not.
Vertical slices are checked only within those groups that are vertically-relevant (A, B, C, E, G and H in my example).
Respectively, horizontal slices are checked only within those groups that matter from the horizontal scalable area perspective (C, D, E and F).
If a specific group represents an intersection of scalable areas (C and E), both vertical and horizontal slices have to be checked for differences within this group. If either of those comparisons fails — the group becomes a bad patch.
Bad patch examples
I’ve created 10 test 9-patch drawables. One for each of the previously mentioned slice groups (from A to H) + two additional ones for intersections (C and E). In every single one of them there is one slice that is different from others (within the particular slice group).
What should you do when there is a bad patch inside your drawable?
Don’t panic.
The discovered bad patch might not even have a noticeable impact on the scaling of your drawable. Use the Android Studio’s 9-patch tool. It’s right side to be exact. It let’s you see what your drawable will look like when scaled (in different ways):
If you can’t see any visual issues with the scaling of your image — you should be just fine.
Important: if you have more versions of your drawable (for different screen resolutions, /res/drawable-hdpi, /res/drawable-xhdpi/ etc.), you need to check ALL versions. It’s possible that 9-patch for only one resolution isn’t working correctly. You need to take care of that.
Identify the direction
If you decide to correct your 9-patch drawable, first you need to identify the direction of the patch that is bad.
- If it’s related only to the top guide — vertical.
- If it’s related only to the left guide — horizontal.
- If it’s related to both top and left guides, you will need to analyze slices within the problematic slice group. To do that follow the logic from previous steps of this post.
Find the cause
Try to find a distinctive slice (of an identified direction) in the particular group.
Watch out for shadows and rounded corners
Unless you messed up your 9-patch pretty badly, there is a huuuuge chance your bad patch is related either to a shadow, or to a rounded corner (or to both of them).
It’s good to pay attention to the spot where the rounding begins, because that’s where the shadow bending usually happens, and that causes the color of the shadow to vary.
Repair.
Adjust your guides to remove bad patches. Sometimes resizing your guide by even 1px can completely fix your issue.
If you enjoyed this post, please show your support! Recommend, follow, comment. This means a lot!
