10 Things You (Don’t) Want to See in Legacy Android Code
Android is a highly customizable platform, it’s free, and it evolves quickly. Furthermore, it’s available everywhere around us — on phones and tablets, smartwatches, TVs and in cars too. What’s not to like? Every day brings some innovation to Android and to its users, making Android a very dynamic environment. I will not talk about technical details; you can find a lot of articles on the Web on those topics, so I would rather share personal experience.
It started when I joined a cool company, focused on its own products, with a team of highly experienced developers, and a codebase which had well-organized architecture for projects.
That was what I thought.
I was curious, full of enthusiasm and excitement to find out how will my work look like over the next couple of months. The disappointment came when I learned that one of the older projects finished two or three years ago was never touched again, not even maintained. I found out that the client was happy with it, used it daily and never asked for any changes. That was until they came up with a new list, some “easy fixes” from the user’s perspective. As you might imagine, these were not as easy as they thought — it required a lot of development and going deeper into details.
Guess who got assigned to this project!
At first, I thought: “Oh no, seriously, I came here for some Kotlin coding, to do some new stuff, do I really have to work on that thing?!”. The project was developed by an elder colleague some time ago, and a great thing was that he’s great developer and still at the company (I was very lucky, otherwise I would have had to do research by myself which would take at least 50% more time). One look at the project, and I knew I will have to work in legacy code.
Long story short, they wrote the code in Java (Kotliners know what I mean 😁), some design patterns were very recognizable, but some parts (as always when you need to hurry) were so messy. I accepted the challenge and got hands dirty. After I reviewed the code, the colleague answered many of my questions, explained some concepts and ideas behind the code. I was ready to start grinding.
Having a good project overview and understanding it is crucial to provide accurate time estimations which in turn allows preventing complications in the future.
Working on someone else’s code can be frustrating, that is why you should always try to understand why was the code written in such a manner. Something which seems unclear at first can be understood by diving deeply into it. There is always a way to understand it if you are creative enough.
But even if the code is written in Java, like in my case, you do not have to drop-off Kotlin’s fancy features. As Kotlin language creators say, the language is interoperable with Java. This means that you can implement new stuff in Kotlin, which will be much more concise if written in Java.
Also, that’s the best practice for Android, which I follow when refactoring or getting deeper into legacy code. Furthermore, Kotlin helps a lot in the case of re-factorization. It can take much more time to rewrite some code from scratch by using Java. So consider extracting some code to new Kotlin class, simplify it and use it in Java code.
So, you got an Android project codebase and you are about to work on it but you don’t know what to expect.
👉 Look at a Gradle file
Gradle files are sometimes ubiquitous for Android developers, yet they’re often treated as a necessary evil, or at least as a magic black box that does things but can always be a good point to discover your project. Before you start, check build configuration script with a bunch of useful information giving you a good project overview.
👉 External dependencies
Dependencies will help you understand why the code is written the way it is. Also, allows you to include an external library or local jar files or other library modules in our Android project. It is worth to look at external dependencies along with the versions they are using. They will tell you what technological stack was used and familiarize you with concepts used in the code you will work on.
👉 API level requirement
Google Play requires that apps target at least Android 8.0. Sometimes this and different Gradle upgrades are mandatory changes before the next release.
👉 Support Library
The next potential source of issues can be the Support Library used in the app which can be outdated. For that, Support Library Revisions can be helpful.
👉 Check a Manifest file
It is worth to look at the Manifest file and analyze the important information.
👉 Check Architecture and try to recognize Design pattern
All clear here. :)
👉 Check Using of Deep View Hierarchy
If a layout has been inflated once, the system reuses it. But even so, inflating the layout must happen at some point.
👉 Check Using of Fragments/Activities
Android introduced the concept of fragments in Honeycomb. In many apps, we can simply use Fragments instead of Activities, depending on background work, and as separate building blocks with their own life cycles can exist inside an Activity.
👉 Check usage and implementation of Intents
Intents are one of Android’s key components. It’s a way of passing data between different parts of the app, but sometimes can be implemented in the wrong way.
👉 Null Pointer Exceptions — The billion-dollar mistake
One of the most common types of crashes are in the wild while you develop, is caused by trying to run methods on objects that are not instantiated (a.k.a. NullPointerException).
👉 Code Reuse
We are developers and because of that, we love creating new pieces of code. It is also common to think writing a new code will be easier to understand, implement, and many other things. The truth is that by reusing code we contribute to keep the app’s code simpler and avoid having new crashes on production.
👉 Simplified Layout
One of the trickiest parts of Android development is to keep simplified layouts and stick to what the design team has designed. It is important to pay attention to the number of views and nested views used to keep the layout simple without compromising what was designed.
Wrapping Up…
I can’t say that working with legacy code is trivial. Of course, it is much nicer to work with Android Jetpack, write the entire code in Kotlin, without the need to support very old Android System versions. But after some time, and many issues resolved, keep in mind that’s just something that makes you a better developer.
