Libraries are used in most, if not all, projects. They help us to develop software, save time and facilitate work. However, it is not easy to choose a library, as there are a number of them, and often several libraries are designed to solve the same problem. Different Android libraries have advantages and disadvantages. In this article we will look at them in an objective manner and think about how to avoid getting confused. First of all – is it worth reinventing the wheel in our projects?
Android libraries – yes or no?
There are plenty of possibilities for developers. As I mentioned, we can choose between many solutions to given problems:
- OkHttp, Retrofit, Volley – REST API support,
- Picasso, Glide, Fresco – picture downloading and management,
- Dagger, Coin, Kodein – dependency injection,
- Realm, ObjectBox, Room – Database service,
- Moshi, Gson, Jackson – JSON parsing,
- RxJava, RxKotlin, RxAndroid – stream support, reactive programming.
“Application development involves combining these solutions into one whole to have as little work in the project as possible” – we can come across such a statement more and more often. Is it true, and is it really worth using all these facilities? Or perhaps libraries are overrated and lead to more problems than benefits?
Android libraries – why are they worthwhile?
One of the biggest problems in writing applications for Android devices is so-called “fragmentation”. This means that the application, or rather the written code, does not behave the same way on all Android devices. Most device providers modify the system significantly according to their needs. When making such modifications, they sometimes change the functioning of some system functions, sometimes to a great extent. They may also stop working completely. In addition, it is worth bearing in mind the variety of versions of the system that need support in the application. Libraries address this problem because their providers improve and adapt them to changes in the system.
Reinventing the wheel
Another reason is “reinventing the wheel” – as taken from the title. Is there any point in writing solutions that already exist and are used by millions of users around the world? The majority of popular libraries are used in hundreds, if not thousands, of applications in the store. These, in turn, often have tens or hundreds of thousands of users. By using such code, we are sure that we will be able to avoid problems that could arise if we tried to write the given functionality on our own.
The clock is ticking…
The last, but still a very important reason, is saving time. Even the best developers can make a mistake while writing code. If you add a few words that developers are familiar with, such as “deadline” and “ASAP”, it turns out that saving time is an important reason to use ready-made libraries. We cannot deny that using ready code, especially if we have used it before, will save us many hours which we would otherwise spend writing this code from scratch. We can be sure that the quality of the code will not suffer, as we take advantage of the benefits of proven code used by thousands of developers around the world.
Android libraries – disadvantages
Libraries are not infinite. Given solutions are no longer up-to-date and developers are choosing newer approaches. Often, the library providers themselves create another version of a given library or suspend further support and development for various reasons. This can be a problem when there is no one to offer further support for such code and repair errors that may arise with new systems or devices.
Fortunately, despite the fact that they are open-source tools, behind many popular libraries there are major companies like Facebook (Fresco library for photo support) or Square. Such libraries are usually supported even when work on them is completed. The RxJava2 library is such an example. Despite creating version 3.0, its providers claim that they will support it until the end of February 2021!
Smaller libraries equal uncertain support
When choosing a library, it is worth taking into consideration its size and support. In the case of smaller libraries, when there are no well-known people from the world of technology standing up for them, their providers can be unable or unwilling to work on them any longer. When we carry out a project that will have to undergo development for years, the end of support can be a real problem. How to cope with it then? The developer may try to maintain the library on his own, improving the code based on errors found by users, to ensure that it works correctly. However, here and in many other solutions, we may be limited by licensing issues.
Fortunately, when choosing a license for their software, many library providers decide on one that allows them to be used both in projects with paid closed source code and those with public access. Furthermore, the license very often also allows you to modify and redistribute the library code without any issues. An example, and in my view the most frequently chosen license, is Apache License 2.0.
Barriers to entry
So-called barriers to entry are also a risk when using libraries. The point is that not every new project team member has previously used a given solution. Therefore, it will take some time before they start using it fluently. This is troublesome, of course, but the same is true of the application code written by developers. Every new person joining the project must be familiar with the way it is developed.
The last counterargument that comes to mind is the size of the application. There are two problems here. The first concerns the limits to the number of methods an application can have before it exceeds the allowable size of the .dex file (Dalvik executable). This problem occurs when we exceed 65,536 methods. This value seems to be inconceivably large and it doesn’t seem possible to exceed it, but it often happens in projects that are:
- incorrectly configured,
Android provides many solutions to this problem, of which ProGuard is one. It allows you to remove unused methods and classes, including in libraries. Another solution is to run multidex support for the application.
The real size of the application
The second problem is the real size of the application. Library providers do their best to help developers by dividing their libraries into several components. Not all of them require additions to the actual application. Some of them are only required during the application building process, and are not used later on. The correct configuration can also help – then we can remove some dependencies and files from the library if we don’t need them.
We use ready-made libraries because of the ease and convenience of use. However, before deciding on a particular one, it is worth considering how to use its full potential. Libraries enable us to save time and extra effort. I wanted to take a closer look at them in an objective way. Although they do have some defects, I don’t think anyone would like to have to write such functionalities as managing pictures, network connections or any others that can be found in the most popular libraries. In my experience, it’s not worth deciding on a big library that solves a lot of problems, and then using only a shred of its capabilities. It is better to choose a library that solves one specific problem or a set of the same type of problem. Also, try to choose libraries which are suitable for the project. If we are sure that projects will be maintained and developed, we can use libraries from certain providers for a very long time.