Checking student projects after working for more than a year as an Android Engineer (Part 2)

Checking student projects after working for more than a year as an Android Engineer (Part 2)

The previous part was more general, the tips could be applied to any programming language. In the following post, I will talk more specifically about Android development, things that I wished I did or knew as a student, and before starting my first job.

Don't repeat yourself

In situations when you need a code snippet that you wrote previously, it is much easier to copy-paste it. This is particularly the case with student projects that are usually small. You will be done faster and there won't be any side effects. But when you enter the industry, this is a huge red flag. It is better if you start early and avoid turning this practice into a habit, that might be hard to correct later. The need for copying a code from somewhere should be an indication that something is wrong. This code smell should be enough to pause for a moment and think of a better, cleaner solution. In my experience, in Android development, the following are things to consider:

Helper function and utility classes

If you need a code snippet, that you wrote previously in the class, it is good practice to take that code and put it in a private method inside of the class. It can be only 2 lines of code, if it is used in multiple places, it will make the code much nicer and cleaner. If you need a code snippet that is in a separate class, then you should consider putting the code snippet in a new utility class. That way it can be used in multiple places without code duplication.

Include tag

If you find the need to copy a code from an XML layout, then you should consider using the include tag (or merge tag). The tutorial from Android developers can be helpful. The way I do it, and I would recommend it to others as well, is by naming the shared layout content_something. For example content_header, and every time you see an XML layout starting with content, you will know that it is a shared layout between multiple layouts. I started doing this very early because I saw that when you start a new Android Studio project, inside activity_main, there was an include tag with a layout named content_main.

Learn how to create custom views

As my friend and colleague mentions at the beginning of a blog post, creating a custom view can seem overwhelming for the first time you have to do it. To help your future self, it is a good idea to see the process of making custom views as early as possible. So that later you can impress your colleagues effortlessly. Copy-pasting an XML code can be a code smell for that, but you don't need a code smell to implement a custom view. If you have a section in your design that has its own behavior and logic, it can be exported to a custom view. The example in the previously linked blog post can be used as a reference.

Do research and start using an architectural pattern

All my Android student projects were consisting of 2-3 activities and all of the code was inside them. Around 300-500 lines of code, were hard to navigate and especially debug. Architectural patterns were mentioned in the Android course lecture and we had sample codes with them. As architectural patterns were not a requirement in our student assignment, it is natural for every student to avoid unnecessary complications that will not affect the grade. It is much later when I was preparing for job interviews and following an online course, that I started using architectural patterns. This short overview from Geeks for geeks is a good starting point, and also Android recommends using MVVM as an architectural pattern for projects.

Write unit tests

Software quality is very important and in some cases, minor bugs can cause serious problems and consequences. Once you have an architecture, one of the benefits is the separation of concerns. Each part of your architecture, depending on which one you decide to use, can be tested separately. Having an architecture makes testing earlier and it is a good practice to test as much code as possible. I wrote my first Android unit test when I first started working. It was a very frustrating experience, writing the code for a feature and then needing twice as much time to write unit tests. Try to invest time in writing some unit tests early, it will prove very beneficial in the future for sure.
Some projects don't do it, but I should mention UI testing here as well. Try to write UI tests as well with libraries like Espresso. You should definitely do research and at least be familiar with the topic. It can help you score some bonus points on an interview :)

Use animations

Android applications, in my experience, are known to be not so fancy and flashy comparing to iOS. When I started working, at one of the lunch breaks our team leader mentioned that Android developers never think about animation, and making the application cooler. This was true and I saw it in one of our refinement meetings. The iOS team was instantly thinking and asking questions about possible screen animations and component animations, while the Android team never asked anything. On a couple of occasions, I witnessed the iOS engineers did animations just to see how it will look, while Android engineers never did anything unless explicitly requested.
In my previous blog post, I was talking about going back to the old project and implementing something new. That can be improving the design and adding a couple of animations. Let's beat this bias, and make Android fancier.


Hope you enjoyed the blog post and find it useful. I am starting to get active on social media, so let's connect and share things online. If you have some ideas and you would like to hear about something particular in part 3, feel free to drop me a message on Instagram, Twitter, LinkedIn