Minute of Pain #3. Shadows

Small thing I’ve never noticed earlier

The point of the post in one picture

Sometimes when I developing on the Android platform, I face with some small problem. And after, let’s say, an hour of an exploration I start to realize that this problem is not as obvious as it could be. And then I stunned with a question: What? Then I start to think: But maybe it isn’t the problem at all? Maybe it was conceived in such manner? And finally, I come to the question: Why? followed by acceptance of reality.

I think we all have such moments in our life, not only in developing. My problem was started around a week ago when designer told me that I have different shadows for the same button on different pages. As this is a part of our future changes in app, I can not show screenshots right now, because of commercial secret, so I will emulate the problem. Here are screenshots of pages.

Two same textViews show little bit below the center of the screen (left), and on the top of it (right)

Note that both text views have the same style:

<style name="AppButton">
    <item name="android:background">@color/colorAccent</item>
    <item name="android:elevation">4dp</item>
    <item name="android:gravity">center</item>
    <item name="android:padding">16dp</item>
    <item name="android:textColor">@android:color/white</item>
</style>

Both have elevation = 4dp but TextView on a left screenshot has significantly sharper shadows than right one.

To demonstrate it quite a bit better you can see two gifs below. One demonstrating sample application ScrollView filled with TextViews described above. And second demonstrating Google Keep app, which has a list of CardViews and such effect:

Two examples of demonstrating changing shadows with changing views positions. Left: test app, Right: Google Keep

After several minutes of astonishment (there were questions what is going on? or why I didn’t spot it earlier?), I decided to post a question on StackOverflow. And after a while I received next answer:

Shadows generated by Elevation API are positioned in 3D space, which means that the look of each shadow is affected not only by its elevation value, but also by shadow caster’s x and y position on screen. It’s pretty much like in the real world — objects beneath a light source cast shorter shadows than objects further away.

And if the source of light is positioned on the top of the screen, then everything falls into place. Since the source of light is on the top of the screen elements with same elevation have different shadow visibility, since a difference of the light beam angle and thus positioning of shadow: bottom elements (they positioned further than top elements) will have a bigger shadow, and the top will have smaller one.

What about pain? Pain is that I didn’t find any info about that in Android documentation, in Material Design documentation. Answer from StackOverflow is just an assumption since there is no official confirmation. Yeah, it very strong and reasonable, but an assumption.

Next thing, is that all posts of these series (links to the first and second) are not about some broken logic in android, is not about something completely new. It just about things, that can be easily forgotten. And shadows with such behavior (that looks for some unprepared people as bug) is one of the moments, when you sit and think: “Why? Did I everything right? Why it is not working?” and then: “Damn it, I just forgot about that behavior”.

The key point of this micro-post is: When you working with shadows, remember, that your elevation is not a guarantee of same looking shadows.