DEV Community: David Bojkovski

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

David Bojkovski — Sun, 11 Jul 2021 10:30:23 +0000

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

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

David Bojkovski — Wed, 07 Jul 2021 21:36:07 +0000

I have been working as an Android engineer for more than a year now, I can say that I have learned a lot during that time and I was promoted a couple of times. I wanted to update my Github profile with a project for a blog post that I was writing at the time and I stumbled upon my old student projects. What can I say, it is a mess and a very unpleasant code to look at. But in some way, it made me appreciate my humble beginnings and the path that I have passed ever since.

I graduated from university 2 years ago, and at that time I already had an Android internship. I knew that I wanted to work with Android, but that was not always the case.

In this blog series, I am going to talk particularly about Android development, but most of these tips you can apply to any technology.

Follow language guidelines and use code reformatting

I was coming from a semester focused on C# development, Windows Forms, and UWP. The next semester I was starting my mobile development class in university, which was about Android. Even though I had completed a Java course before, I liked the C# style of opening and closing function braces.

public void foo() 
{
    //code
}

So every time when I started a new Android project, override a function, or write a new function I would go to the function definition and put the opening brace on a new line. I am not very proud of this, and my course instructor wasn't happy with the formatting of my homework assignments. Luckily that didn't affect my final grade.
Follow the language guidelines of the language that you are using, there are a lot of resources online and good examples.

Another important thing is to always have a very structured code. I cannot stress this enough but it is very important to learn the code reformatting shortcut of your IDE of choice and always reformat the code before committing or posting your code somewhere. Also, another tip would be not to have many empty lines between the code. I did this, a lot of beginners do this. I have seen a lot of Stackoverflow questions looking like that, it is very distracting and people may pass answering because of that.

Done is better than perfect, but ...

In our primitive minds the reward for something new is bigger than to keep improving the ongoing thing.

I have read this quote somewhere and in my experience that has been proven correct times and times again. There is always a but somewhere if you think something for long enough. And the statement that I quoted should not be the case. Finishing a project or implementing a library that you wanted to try out makes you feel great, and then you move on to the next thing. That is how I have been working till now and this it is one of my regrets. I have started or cloned more than 100 Android Studio projects. They have been a very simple idea, trying out a new library or closing and completing some Google codelab source code. I don't have a good and solid project that is a bit more complex, that I can show to a potential client or employer to prove my knowledge and skills. That is what I have been trying to improve lately, and I would highly recommend you to start very early. Add a particular feature to an old project even if it doesn't make sense, it is your project and you get to make the rules. Here are some of the examples that I could think of: add a weather functionality to the note-taking application that you have built before or implement a Hilt dependency injection. It will help you improve your skills and you will always have something ready to show.

Another good thing about going this way is that you will always check your old code and you can have a particular feeling about your progress. So if you learn something new or see a better way to implement that, you can get back and refactor that code. Doing this your project will always be up to date.

If it works, it does not mean that it is correct

We are all happy when we see that our solution works, but it is always good to get back in the code and check everything all over. Some solutions are hacky and not maintainable in the long run because only you understand the solution. After a while, there won't be anyone who can understand that, not even you. So always go back and make sure everything is correct.

I saw something embarrassing in one of my projects. It was the classic weather application when you learn how to connect to an API for the first time. There were 2 screens. The first one was a list of cities' names and the second one was the weather information for the city that you select on the first screen. You could add a city by a simple popup and when you click a city in the list, the second screen was opened. An API was called on the second screen and the details were displayed. Everything is working fine on the "happy" path, but the problem starts when you test the edge cases. Let's say you enter some nonce like "kqwoeiqwe", then that is added as a city, it will be added successfully. When you click on it, a second screen is opened and there is a Toast message saying that there was an error from the API. Was this solution working - YES, was it correct - I would say NO. The correct approach would be to validate the city before it is entered into the list of cities. You won't have nonce inside the list and later end up on the details screen with an error. The error could have been displayed when trying to enter it in the first place.

Maybe my example got you thinking about the recent projects that you worked on, so you better go give them a second look :)

This is my first blog and I have a couple more sections to add. But I was procrastinating on finishing the article, so I decided to make it a blog series. Hope you find this useful and I would like to hear your feedback.

Cover photo by Ales Nesetril on Unsplash