At the moment, at work, I mentor juniors, as well as those who are just starting to roll into the profession of Android developer. Beginners tend to make the same mistakes.
This is an article about things that beginners undermine, they forget to emphasize this in books and articles. Four bugs, four horsemen of the apocalypse that hurt senior developers. By avoiding these mistakes, you will significantly speed up your journey and make life easier for yourself and your colleagues.
A very common mistake is storing data in an Activity. Why is this a problem? We work within the framework of the Android framework, which provides us with application components. This means that we have little to no control over these components. The main components of the application are managed by the system. At any moment, the Activity can simply cease to exist and you can’t do anything about it.
In order for the application to work really stable, always think about what will happen if the Activity is recreated! A lot of bugs are due to the fact that developers forget about it. Always keep in mind that the system is a knife-wielding psychopath who will take components from you at the most inopportune moment.
The same applies to working with lists. It is obvious that the lists will somehow work within the framework of the Activity. There is no need to make any variables in the ViewHolder, because Adapter is also a framework that we do not control. Use the approach with Adapter DelegateThis will make your life much easier.
Of course, you can save variables in a Bundle, but not everything can be saved there, not to mention that it is limited in size (≈1Mb per process, a popular question on social security). Bundle is best used to transfer all sorts of Ids and similar small things.
To sum up this advice: if it is possible to avoid variables in Activity, Fragment… it is better not to do so. If you want to store variables, store them in the ViewModel or something else that is not related to the application components. However do not save data to static.
Someone once said: “the best jun is the jun that burned out, he won’t do too much, after which he will have to rewrite.” We all have ambitions to become cool developers, to show that we can solve any problem and write complex code. I understand, I was like that myself, I wanted to write the whole project for the evening, fasten cool animation even if it is not needed, write more optimized code sacrificing readability – DO NOT DO THIS!
Believe me, everyone in their career will still have the opportunity to show that you are cool, do not run ahead of the engine. There is a very high probability that you will break firewood and have to redo or cut out something superfluous. If you just want to play around with some complex technology or cool animations, it’s better to do it as part of a pet project. In this case, when such a task from the business arrives to you, you will know what to do.
Overcomplicating code is a ticking time bomb. When you write code, always keep in mind that you are writing it for another person. Even if you are alone on the project, in six months you are already a different person who will not remember anything about this section of code. In a sense, you become the author of the book, and I would not want to read a book where the action is spread out over time and you have to take notes to understand the plot (Netflix sins quite often these days). Try to put yourself in the place of a reader of your code who doesn’t know what you know.
The question arises, “How to understand what I am overcomplicating?”. It’s best to follow logic. If for solving a simple task, such as changing an element in a list or recoloring a button, you get a lot of code right, it’s worth thinking about. All tasks have already been solved before you, google it, look at the code of other projects, reading the code of others is very pumping.
The bottom line is that you don’t need to write complex code, you need to write as simple code as possible. The less code needed to solve a problem, the better. Look at the principle KISS.
You can often notice that the exception that arrives when requested on the network is either hammered or doing something like printStackTrace. Do not do this, at least send an exception to the log.
This is where Murphy’s law works at all to the maximum, everything that can fall will fall. Moreover, everything is real, any network call, a trip to the database, and even a call to the system API can fall with an exception.
The application should continue to work even if there is no network, and the disk has run out of memory. To continue working means not just swallowing the error, but informing the user about it and telling him what to do next.
Surprisingly, even experienced developers are undermined by this. Always keep this in mind, especially if you have multiple queries in a row. Managers and designers often miss these points. Get to the bottom of business analysts and designers so that they describe what to do if the request falls.
The bottom line is that you do not need to write super fast code, you need to write the simplest and most understandable code. If you’re not writing a game, operating system, or video editor, then you don’t need to worry too much about performance at all. Yes, of course, you don’t need to use obviously stupid solutions like bubble sort, or go to the database on the UI thread. At the same time, at the initial stage, you don’t need to worry about how to make mega fast rendering or how to make a parallel algorithm where a single-threaded one is enough.
A common mistake is to make a class mutable to save memory. It is better to make the class immutable and create a new instance when it changes. Because you will definitely be sure that no one will change your class in another part of the program or another thread. The Android JVM can effectively dispose of such objects.
Stroustrup said “Premature optimization is the root of all evil”, so you better worry about the readability of the code and its brevity. A good architecture allows you to rewrite those parts of the program that slow down in the future. The main problem is that you cannot know in advance what will slow down.
In order to understand which parts are slowing down, you need to do a profiling otherwise you will just play the lottery based on your guesses. Optimization will be done later, when it becomes a problem and you will definitely know the root of this problem.
If you liked the article and the fucking illustrations for it, subscribe to my telegram channel. I write about Android development and Computer Science, there are more interesting posts about Android development on the channel.