How to become a better Android Developer | Take your Android Development Game to a whole new level

So, you’ve got yourself familiar with android development and can develop an app pretty easily. You know about all the utility libraries like ButterKnife, Glide, Gson etc…?

And you want to take your development game to the next level? So, this is exactly the post for you. Sit back and enjoy as this is going to be a long one but I promise it would be worth your while.

When I started Android Development initially, I wrote all my code in the Activity itself, put all my files under one folder/package, declared global constants in the activity itself. Basically, it was a mess. If you came back after a month and had a look at my code, you’d have no ideas what on earth is going on. That’s why I never updated my apps or added any new features to them. WHY? Because they were not scalable. The code was all over a place and it would take atleast 2-3 days to figure out what was going on.

So, then I decided that something had to change. I wanted to write modular, maintainable, and scalable code. Basically, TAKE MY ANDROID DEVELOPMENT GAME TO THE NEXT LEVEL!!

I learnt things the HARD way but I want to make sure that your apps don’t suffer the same fate. So, here I have jot down 5 steps that you need to follow to become better at android development and write scalable apps. I guarantee that if you follow these steps religiously, you would definitely become better at android development.

We will be focusing on 5 things today:

1. App Architecture
2. Code Distribution
3. Best Practices
4. Reinventing the Wheel
5. Industry Experience

App Architecture

I cannot stress enough on how important this is. If you ignore everything else and just focus on this one thing, you’ll notice the difference in yourself as a developer.

Let’s first understand what an Architecture is:

According to Wikipedia, software architecture refers to the high-level structures of a software system, the discipline of creating such structures, and system. Each structure comprises software elements, relations among them, and properties of both elements and relations.

In simple terms, it is a contract which you need to abide by when creating your apps. You can no longer just do: dialog.show() or dialog.hide()

You can no longer write everything in one activity or one class. You need to abide by the principles that the architecture follows. For example: If I talk about MVP Architecture, which I personally like a lot, you would need to call presenter.showDialog(); and presenter.hideDialog() which would then command your View class to show and hide the dialog. This helps you write more modular and maintainable code.

The whole point of using an Architecture is SEPARATION OF CONCERNS.

The business logic of the app is separated from the presentation logic. Any change in the UI will not affect the business logic of the app. This gives you more freedom to play around with the UI and if you want to change anything in the future, your business logic can remain the same.

There are 3 major Architectural Patterns followed by Android Developer’s all over the world:

1. MVP (Model View Presenter) Architecture: This is the simplest and the most commonly used architecture all over the world. It consists of 3 layers, the Model, the View and the Presenter. You get your data from the Model, it can be your SQLite Database, REST API call, Shared Preferences etc.… The View class is your activity or fragment and the Presentation class is a separate class which handles what happens when your user interacts with the app. For Example: If a user taps on a Floating Action Button, then what happens next will be handled by the presentation class. I’ll be creating a separate blog post on this article and explain each and every detail with code as well. So, be on the lookout.
2. MVVM (Model View ViewModel) Architecture: This architecture is a bit difficult and takes a while to get a hang of, but this is the most popular architecture now-a-days and is being recommended by Google itself. But I don’t recommend going straight into this architecture. Once get a hang of what software architectures actually do and then you can move into more advanced stuff.
3. CLEAN Architecture: This is not something new and has been around for a long time. It is also referred to as Uncle Bob’s Clean Architecture. It is a layered architecture having three layers:
   1. Data Layer: It consists of all the POJOS and Utilities to get data from local or REST API.
   2. Domain Layer: It includes all the business logic. The brain of your app.
   3. Presentation Layer: It includes Activities and Fragments.

I’ll be creating a separate article on CLEAN architecture as well. But first I recommend that you start with MVP Architecture and get a complete grasp over it.

TODO: Study MVP Architecture and start using it in your apps.

Code Distribution

I absolutely hate it when I see code with all the utility methods written in the activity itself, no separate packages for different task, and finally lots and lots of Global Variables and Constants.

I understand that there is a need for utility functions and Constants, but instead of declaring all of it in the activity follow the below steps:

1. Create an empty package named Utils.
2. Create class file for your task, for example, if you have methods for formatting/handling strings, create a file named StringUtils.java

This will contain all your utility methods related to string operations. The methods will be static and would be callable from anywhere in your app.

1. Whenever you want to use the method just call StringUtils.methodName(), and there you go!!

You just removed all the unnecessary code from your activities, and the best part is, they can be called from anywhere and not just a specific activity.

Similarly, if you want to use constants for shared preferences, passing intent data, adding fragment tags etc… It can be done in a utility class named Const.

TODO: Start separating your code into logical modules and pacakges to reduce boilerplate and redundancy.

Best Practices

Imaging seeing this all over the place in you app. The variables make no sense whatsoever.

Now take a look at this.

What would make sense when you come back to this code 2 weeks later? Unless you are Lucy and can use 100% of your brain, most of you would prefer the second code than the first one.

In the second code the variable names make perfect sense and their usage is clear by their name, whereas in the first example, the variable names are arbitrary and make no sense.

Be careful as to what naming conventions you use in your android apps. You can either use an underscore to separate the names or the recommended camelCase. I personally prefer camel case than the underscore.

To know more about such best practices, I highly recommend that you take a look at this github repository.

It would help you in not just being a better android developer, but a better software engineer altogether.

TODO: Learn about all the best practices in Android Development and start implementing them in your apps.

Reinventing the Wheel

This may sound rather obvious but I see people make this mistake in their android apps every other day. Keep yourself updated about the latest android libraries, start using ButterKnife if you haven’t already (unless you certainly need to use findById calls), start using Retrofit for your API calls.

I made this mistake early on where I kept on writing redundant code for things like Custom AlertBoxes, Toggling CardViews etc… These functionalities have already been created in the form of Android Libraries and a simple Google Search will reveal all the best libraries in the game. So, whenever you find yourself doing some redundant task, then instead of starting from scratch, do some google search and find out if a solution has already been created. Use that instead.

TODO: Take a look at your code, and find out what have you written that could have been replaced by a pre-built library. Do some google search.

Industry Experience

There is nothing that can beat actual industry experience.

Take on some internships, do some freelance projects, work on some ideas, but don’t sit idle and just hope to become good someday.

I have listed out all the points that can help you become a better android developer but if you don’t act and put these into practice, then there’s nothing much I can do. No book or article can help you become better by just reading.

Unless and until you try this, stumble across some problems, get stuck, and then Google your way out, you cannot better yourself. You have to be willing to slash and burn. Sure, it might take some time, but I guarantee that these skills would make you stand out from the competition. It would definitely be worth in the long term.

TODO: PUT THESE PRINCIPLES INTO PRACTICE!!

Hope these points help you in your journey. All the best!!

TOP 10 BOOKS ON ANDROID DEVELOPMENT IN 2018

I’ll soon be writing detailed posts about MVP, MVVM Architectures in Android and also about advanced stuff such as RxJava, Data Binding, and Unit Testing. To get notified about all these posts, subscribe to the mailing list by entering your name and email in the top right hand corner form.

Like what you read ? Don’t forget to share this post as much as possible on Facebook, Whatsapp and LinkedIn. You can follow me on LinkedIn and GitHub.