My Hexaville
Spead the Word

Android Best Practices

Android Best Practices
Designed by Freepik


Really want to write about some of the principles I learned and think that beneficial to consider. They are not Android related in particular, you can apply them for any platform/language. Because writing code just so it does the job is first thing, after that you start figuring out how to make it easier to understand. At least for yourself. There’s nothing as frustrating as your own code that makes you stuck wondering what the hell it does.


Prefixes or Hungarian Notations are yet common in Android, I think primary because of the Android source code. Let’s put it this way, what’s the logical reasoning to add m, s to fields? First, let’s get into some history. This thing was introduces in the 70`s. Obviously IDE’s were nothing like they are today. Probably they had a hard time determining fields from local variables, difference by visibility modifiers wasn’t that obvious. But look what we have today – there’s two ways to determine variable type – color/font and just by pressing Ctrl and hovering over it which gives the full information.

There’s clearly no problem with determining types. And in the end you start to ignore those prefixes, they don’t give any value. Just looking at the color you can tell. Yes, it’s cool to eliminate the need of this keyword, but it’s not worth it.

Start Folded

What I found myself if folding everything each time I open some new class to overview it. Or just to review my own ones by pressing Ctrl+Shift+- or + for unfolding instead. What would you better prefer : reading 5 lines of code or 150? I prefer first one! That’s exactly what you get when you fold everything first. You get to the highest abstraction of this class. All those 5 line comments, details of implementation they distract you from understanding the key functionality this class does. You don’t need to know the details right away. Just by reading function names you should understand what this class is doing and by looking at the visibility modifiers you can tell which ones are meant for user use cases. And then you drill down into each function for implementation starting from the most important functions and maybe not even touching the lowest most abstraction level ones if their names is so obvious.

By the way, in Android Studio you can set automatic folding here

Method Extracting

Here comes the rule from it – extract methods. When you start unfolded you get to the lowest level of abstraction in the class. You don’t judge from the user or higher point of view. Have you heard saying ‘stand up and look at the big picture’? That’s just like that. Functions are meant exactly for that. Just by looking down to the ground you can’t make your design great.

Using this principle you can easily tell which class lack abstraction. Just by opening your fragment, activity folding it down. What do you see? If you see just two or three methods, where one on them is overriden one, tells you gotta start method extracting. Unless you’re using Data Binding your functions are most likely cluttered .

If Conditions

Now I’ll give you the principle you can apply right away in your projects. Extract if conditions. There’s nothing simpler than that. Just look at that

Which one takes you less time to understand the context? Although it’s a simple if condition, the second of course. And we all know there’s way larger if conditions in real projects which makes this principle really handy.

In Function Vertical Spacing

You might be tempted to add line spaces inside functions for readability purposes. Yes, visual structuring is definitely a great help for understanding the the thought process. What we do is making small blocks inside a function. Although it’s better than having 80 lines function without any spaces, those blocks are perfect match for function extracting.

Here’s an example refactoring my own code. I have this circular reveal method which shows reveal for two tabs like in Play Store app with different tab colors. It is a highest abstraction level method, although it has the lowest details of implementation which isn’t great. I myself just spent some time understanding what it does.

How about this?


Although it’s more lines of code in the second approach, it’s way more readable, easy to understand without need to read Circular reveal documentation. Function names explain the meaning themselves. But here’s the most value – you’ve just separated animating circular reveal by abstraction levels. You’ll never need to touch CircularReveal low level class stuff, you just write those 6 lines of code. Which makes it easier for you to understand later, It’s like a mini library.


Alright, thanks for reading, don’t forget to subscribe, follow me on Twitter, Facebook, G+ and share with friends if you think they will benefit from it!

About the Author Ihor Klimov

Formerly an Android developer, lately picked up some Flutter. This blog is everything that I find exciting about Android and Flutter development. Stay tuned and hope to see you again!