Thoughts after two years as an Android Developer
Two years ago I have started my journey with Android programming. I was a bachelor’s degree student at the time, looking for the programming language that I could learn in order to get an internship. I tried a little bit of frontend but I have quickly figured it out that it wasn’t really my thing.
So why did I choose Android? Because I found tutorials on Udacity which were super nicely prepared. They were free, easy to get into and fun as hell. It was the first time tutorials gave me so much fun. I wanted to check out more and more. Two months after setting upon the path of mobile development I have started an internship at RSQ Technologies.
Yeah, so it is two years later and I’m still an Android Developer at RSQ. I love Android and the dev community more than I did at the beginning of my journey. On this anniversary I have some thoughts that I wanted to share with people who are just starting with native mobile development. Some of them might be obvious for most of you, but they probably weren’t when you started.
1. Always check what's new in Android environment/community
This is the best thing you can do when becoming a programmer. If you jump into the river, you have to go with the flow. It is always valuable to check out what new library releases or new articles which highlight Android parts you never heard of. Even if you don’t need them right now or in the nearest future, you will probably remember them and will recall when a similar problem or need will occur.
It has happened to me multiple times. I have read an article, bookmarked it or shared with friends and then left it without using any of the ideas presented. But I cannot count how many times when I wanted to implement some idea for animation or unit testing, I came back to them after some time while I was looking for a solution or widening horizons on some stuff.
In our RSQ team, we started a Friday education routine. Each team member is presenting one article which he found interesting this week and then we are discussing if they are valuable for the project or just give us new ideas for future solutions. Thanks to these systematic meetings we are always up to date with all the Android actual trends.
Where to start?
2. Avoid using external libraries whenever possible
This is probably the thing which not everyone will agree with. Too many times this story repeated in the projects that I was working on— we are producing Minimal Viable Product (MVP) of some feature and found library that looked perfectly fitting the case. This resulted in difficulties whenever we had to upgrade something or introduce some not obvious visual changes, we could see that we have reached the limit of the library’s possibilities.
Sometimes this may apply to the case when you are adding Floating Action Menu and then try to add some fancy shadow which may not be possible. In another case, you may use some cool external library for your Model View Presenter (MVP) architecture, but after some time you will be converting a project to Kotlin and not everything will work as it should with null safety and annotations.
3. Introduce an Architecture to your every project, no matter the size
When I was taking part in some beginner online courses for Android, no one was talking about applying any architecture to the project. I’m aware that we should not introduce fresh developers into Android with Model View Intent (MVI) project structure. We may start with splitting code into small parts divided into two files where we work on visual parts and data processing/server connection.
It is important because every maintained project comes very quickly to the moment when adding everything to the Activity causes zero readability what at the end causes bugs. Converting your project afterwards from no architecture to some architecture gives you and your team a vast amount of work.
4. Test your code as soon as possible
This may be obvious for people who have been in the community for some time already, but it was not that obvious for me at the beginning. It may be not that clear also for the people who are working for the companies that have never introduced testing to longly maintained products.
What can I say to the people who are not testing their code? It is not that confusing and hard as it seems to be. You do not have to jump into the testing train with all testing stack and use all of the possibilities like Espresso, Robolectric, JUnit 5, mockk/Mockito. You can always start with just some basic unit tests for your utils package, without mocking data and checking views. A small number of tests is better than no tests at all.
5. Connect your repository to CI as soon as possible
This point may be even more surprising than the previous one for some of you. Let’s say that I am just doing first small Hello World projects and you tell me that I should connect it with CI? Yes, do it, please!
If you are going to search the Internet for information about continuous integration you will probably read that you should connect also continuous delivery and continuous deployment. Do not worry about that just yet. Start at the basic level and get to know the whys and hows.
When I started writing my bachelor’s degree project, I have checked some Android articles and one of them contained information about CircleCI. The article was saying that there is a new version of it, it is for free and no server is needed. I cannot describe how surprised I was when one hour after reading this article my projects CI was up and running — building and unit testing an app after every Git push.
6. Code reviews are super helpful
This may not be within the reach of every junior developer, but it is one of the best things that can happen to the programmer. No one is writing perfect code, especially when he/she is in hurry or just wants to get rid of ridiculous task. It is always good to check your code twice, even when it is just a oneliner.
Your code reviewer doesn’t have to be a senior programmer, even people who are juniors can point you to a better solution.
Of course, remember to triple check yourself to not waste your colleagues time! There are a lot of defects you can detect on your own just by checking yourself multiple times.
7. Kotlin for the win
Google made a big announcement at Google I/O 2017 saying that Kotlin is going to be the new official language for Android Development. All of us in our team knew about Kotlin before, but that was the moment when we have finally realized, that we really should try it out. In our case, it was probably a little bit easier, because our backend team has converted fully from Java to Kotlin a few months earlier, so we had always someone to ask for advice.
Kotlin gives you a huge amount of cool features, like:
- null safety
- lambdas (out of the box, without external libraries)
- awesome higher order functions
- interoperability
(and much, much more, but that's not the goal of this article)
Now moving to Kotlin is easier than ever with help of Android Studio converter, very good Kotlin documentation and tons of talks about it. There is no reason to clutch to Java 7.
8. You don’t have to always introduce all of the newest ideas
Don’t blame yourself if your codebase does not include Dagger/Koin dependency injection, Android Architecture Components, and RxKotlin and any other newest technologies. Everything will work itself into your projects over time. Maybe your project is just okay with MVP and parts of RxJava. Understanding all of these libraries and concepts is always helpful when you are looking for the best solution, but it is not necessary at the beginning. There‘s always going to be something new that is very hyped at the moment and everyone are talking about it.
You have to always learn about new solutions, but you don’t have to adapt everything to your projects.
9. Sometimes visual part is harder to code than reactive programming
That was one of the biggest pain points for me while working as an Android developer. I have just coded first lines of networking with reactive programming (Retrofit + RxJava) but then I almost lost the fight with the system while trying to add a shadow to the Floating Action Menu. Remember that sometimes the task might appear trivial or easier than others, it is not always your fault. It is just Android visuals.
10. Attend your local Android meetups (also international if possible)
This point is somehow connected to the first one. It is all about communication with the community, sharing your experiences and gaining as much knowledge as possible from such events. Some talks are less interesting than others, but you can always get familiar with new ideas. You can talk about them and sneak your question for someone with broader knowledge.
Besides this, you can always check out the best talks from Android/Kotlin events on YouTube:
All of the things I mentioned above, I discovered at different moments during my 2 years of Android Development. Most of them seem unattainable at the beginning, but remember — you don’t have to implement them all at once with all the features in every project. You can always just check them out and try to do the minimal plan.
I hope that these thoughts are going to just make new developers less scared of checking out new things and more open for sharing their views with others.
