Potential problems
I strongly recommend avoiding adding external libraries to your project. However, this does not mean that using libraries is evil, and your Gradle file should be completely cleaned of any external dependencies! I want to convey the idea that a very serious analysis needs to be done before adding a new library. To understand how to parse libraries, let's look at some of the potential problems you might face when adding a new library to your project.
Application size
Most libraries do not greatly increase the size of your application. But there are such libs, after adding which your application will increase significantly! For example, the Realm library can increase the APK size from 4MB to 12MB. On average, the application weighs 100MB-200MB and the extra 8MB may not be noticeable. But keep in mind that Realm isn't the only library that negatively impacts APK size. Is it possible to reduce the size of the APK using this dependency? Yes, you can split apk by processor architectures. But this leads to the next problem (point 2).
Code maintainability
Projects grow, are covered with more and more logic and sometimes it becomes more difficult to understand them. So that after several years of project development, any new developer can easily get used to the project, a clear project architecture is needed. However, some libraries can nullify project maintainability. For example, incorrect work with EventBus can greatly confuse the logic of your application. It is important to clearly distinguish between where and in which cases you use this lib. And also to be sure that no one will ever deviate from these rules. But what happens in practice? Almost every developer starting with EventBus uses it everywhere. As a result, the project becomes completely unreadable.
Time to explore the library
When adding a new library, you need to learn how to interact with it. There are libraries that can have a very negative impact on the speed of development in the future.
For example, Google's PagingLibrary takes a lot of effort to figure out how to interact with it. It will take every new developer from 12 to 20 hours to figure out this library. You are losing almost 3 days! In just these 3 days, you can write down your pagination and be independent of third-party solutions.
Build speed
The build speed of modern applications is poor. However, if you want to increase your build time even more - use Dagger ! I don't know why the library is still actively used after the advent of Kotlin. In most cases, Dagger contains all 4 problems that were described above.
Bugs, bugs, bugs ...
In my experience, in just one project, I sawed out 5 libraries due to the presence of bugs in them. Remember that there are almost always bugs in libraries. For instance:
- AndroidPdfViewer leaves memory leaks, incorrectly handles some cases with null, which causes a NullPointerException to be thrown
- Android Navigation Component does not work correctly with Shared Elemant animations in some cases
- Cicerone sometimes crashes the application due to
executePendingTransactions()
Does this mean that libraries are not worth using? No, libraries can and should be used, but it is important to at least make sure that there are no critical bugs for your project in the issue list.
The presence of vulnerabilities in the library
Do you know the easiest way to hack several applications at once by examining only one source code? We need to find a bug in a large library that is used by many developers. And through the vulnerabilities of this lib to get access to the data of your application. If you are not developing an application that requires increased attention to user safety, then you can turn a blind eye to this point. If not, look for an issue that addresses potential vulnerabilities.
Library support
If the library has not been updated for a year, ask a question whether it is worth using it. The fact is that there are bugs in the libraries on a regular basis. If these bugs are not fixed, then is it worth using this library? It is quite possible that in the near future you will stumble upon a library bug and you will have to look for alternative ways to implement the feature. There are some libraries that need to adapt to the capabilities of the current Android API. For example, if a new element has appeared in Android, then you need to add support for it. These libraries include Anko , which is no longer supported. Now it makes no sense to use this library in large projects.
The library is present in all layers of the project
Libraries such as RxJava or PagingLibrary force the developer to use their API on every layer of the application. If you are sure that the library will always be in the project, then there is no problem. But if for some reason you have to cut out the library, then you will spend colossal efforts! You will have to rewrite half of the project.
Library limitations
Each lib provides an API that is limited by both the availability of public methods and internal implementation. Make sure that the library's capabilities are fully sufficient for you. For example, the popular Android Navigation Component library ties the developer's hands very tightly. It does not provide show, hide, add methods (which FragmentTransaction has). In addition, the library complicates the work with the BottomNavigationView when you need to store the history of tabs.
Huge Gradle file with dependencies
When I come to a new project, the first thing I do is look at the dependencies in the Gradle file. It makes it clear what the application can do and how certain tasks are solved. But I was surprised when I saw that OkHttp, Retrofit, and Volley (fork) are used to work with the network. And that's just networking. The Gradle file itself consists of a huge number of libraries, support for which has ended long ago. When a developer is alone, he can keep the whole project in his head, but when new developers come, it becomes extremely difficult to understand such a project.
Checklist of questions before implementing the library
- What issue does this library have? Are they critical to my project?
- How tested is this library / technology by the developer community? How many stars does she have on GitHub?
- How often does a developer respond to an issue?
- How often does the developer update the library?
- How much time will new developers spend learning the technology used?
- How will the library affect the size of the application?
- How will the library affect the speed of the application?
- How will the library affect build speed? Does it help you save development time?
- Does the library have vulnerabilities?
- Will the library be present on every layer of the project? How critical is this?
- How the library limits the developer's options (it almost always limits). Is it good or bad?
- Will I be able to write a solution myself that will be sharpened for my project within a reasonable timeframe?
It is very interesting to hear what else you can look for when choosing a library. I look forward to comments, feedback and questions!