This is a series of articles about Android’s stupid design. Android is a mobile operating system packed with unpleasant design, unfinished features and a platform full of bugs and fragmentation. No wonder the dynamic layout system that Android is using is based on Fragments. Coding with Android is already a pain in the ass, designing for it is even more so.
And this article is particularly about dealing with status bar.
Status bar is used across various mobile platforms. It is usually located at the top of the screen, dedicated to displaying information including time, network status, cellular activity and various notifications from 3rd party apps. On an sophisticated mobile operating system on which apps are plenty, it is very common to find your notification area jammed with various icons, making the whole thing even more frustrating.
Originated from Android, the notification center is usually summoned by swiping down from the status bar. This method of interaction was then adopted to iOS and Windows, thus making Android The Father of All Notification Swipes. But being the father of all doesn’t mean it would always provide the best experience. It was not until Android 5.0 Lollipop that Google has finally decided to make individual notifications interact-able, not long before Windows Phone (an infamously well criticized mobile OS if you don’t already know it) adopting this feature.
Ever since the very early stage of Android, the status bar has been there hosting information for you. Sadly, Google seemed never card about the look of the most constant element of the entire UI. Developers and users were always longing for a unified look and distinct design language for the status bar.
There are three major methods of implementing the status bar, as shown below:
Ever since Android 3.0 Honeycomb, with the introduction of the Holo Theme, brought with the dark status bar. What’s worth pointing out is that dark style of the status bar isn’t Android exclusive: there were versions of iOS where Apple encourage developers to implement a dark or grey-ish status bar. It wasn’t until iOS 6 that Apple has finally acquired immersive status bar, it is thus understandable why many developers out int the wild still prefer this simplistic look. Smartisan OS, for example, overhauled the entire UI of Android, use dark status bar as the default look unless 3rd party apps were programmed to use other kinds of status bars.
One good thing about dark status bar is that it looks very independent from the app main content, making it a perfect area to be populated with notification icons and what not, especially if you’re that kind of person who never takes care of app permissions. But if you’re using a device whose forefront is white or light-colored, you may find the seam between content and device forehead to be too thick.
Apple allowed developers to tint the status bar since iOS 6, making it more immersive. Then along with the UI redesign that came with the iOS 7, Apple is finally encouraging developers to color the status bar with the same color of the navigation bar. Google, however, implemented a workaround in Android 4.4 Kitkat, allowing developers to make the entire status transparent when developing full-screen apps. It was then possible to mimic the same feel of the iOS immersive status bar by constantly putting a virtual app bar (the one with controls) on the display, and giving it the same function as the app bar.
But as it turned out, methods of realizing a immersive status bar on Android isn’t always as elegant as it seems. If you simply set the ColorPrimary and ColorPrimaryDark properties to the same value in style.xml, as shown:
<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar"> <!-- Customize your theme here. --> <item name="colorPrimary">#00BCD4</item> <item name="colorPrimaryDark">#00BCD4</item> <item name="colorAccent">@color/colorAccent</item> </style>
you will get:
Apparently whatever rendering engine Android is using has shaded the status bar with a slight shadow, thus making it feels like Google wants the status bar to have a darker color than the app bar. Also, this method only works with Android 5.0 (API Level 21) and above.
You can also declare the color of the status bar in Java code, as shown:
The status bar is now without the shadow, but it will no longer dynamically change color ever again. Summoning the navigation drawer (the hamburger menu) will no longer shade the status bar. It became solid.
But in the real world conditions, almost not a single developer chose to implement an immersive status bar using methods described above. They would always make a fullscreen app instead, then write an app bar manually.
Finally, the Material Style which is the very reason to write this piece of article at all.
Google recommends using the Material Theme which is the default theme of Android when you’re developing apps targeting Android 5.0 Lollipop and above. You might also witness App Compact theme in the default template if you used Support Libraries to maintain backward compatibility. It’s OK. They look identical on Android 5.0 and 6.0. Normally, the color of the status bar is darker than the app bar as Google recommends using Color 700 on the status bar and Color 500 on the app bar as explained here. Also, as mentioned above, Android will shade the status bar with a shadow by default which further strengthened the theory.
It seems, that the status bar should be located underneath the app bar.
Referring to Google Design guidelines, the Elevation value (which is used to describe the z-axis position of a view) of the status bar is larger than the app bar.
Another proof is when you draw the navigation drawer from the left side, it looks as if it slides underneath the status bar.
This causes confusion. There was a slice of hope that the status bar is actually a semi-transparent dark stripe if the shadow is not rendered (left), however, with the shadow presented (right), this kind of hope is nothing but in vain.
What’s worse, when you pull out the navigation drawer:
It has at least two explanations:
- The status bar is on top of the main activity as well as the the navigation drawer, and is shown as a semi-transparent dark stripe.
- The status bar is on top of the main activity, and is as shown as a semi-transparent dark stripe; the navigation drawer, however, is on top of everything, but has it’s own status bar overlay, and is shown as a semi-transparent dark stripe.
Apparently, the second explanation is more self evident (although not being as intuitive), but as Google stated in its official guidelines, the first explanation is the correct one.
To overcome this unnecessary difficulty in understanding the status bar incident, a number of developers chose to make the status bar in the navigation drawer invisible, which is not normally possible when coding within Google’s standard. They instead made a full-screen app whose status bar is invisible, then add a fake status bar on the top, whose Elevation value is smaller than the navigation drawer. As shown:
Although the look is way better, it’s also time- and energy-consuming trying to do all of the work just for the status bar. And when the status bar is jammed with icons, it’s just as confusing.
Others tried to tackle the issue more creatively:
Evernote used solid status bar once and for all. If transparency is constantly not a good solution, we simply make it opaque. It’s worth it to bring about just a little bit of confusion if it solves the problem. At least it doesn’t make the app as spatially distorted as default.
Bilibili chose to implement a immersive status bar in the main activity, but instead of making everything solid, it specifically gave the navigation drawer a status bar. This is an excellent approach if only it isn’t so mind consuming to come up with such an idea.
BuzzFeed and Apple Music just sticked with a dark status bar, thus eliminating the confusion caused by the freaking status bar. Although it makes the app feel less modern and interesting, it is the most sophisticated solution.
There might be haters asking: Material Design isn’t Android specific. What about the iOS apps that implement Material Design? Aren’t they facing the same paradox? Isn’t iOS STUPID?