DIPIEN

6 steps to stop using Jetifier and increase your build speed Jetpack is a set of libraries, tools, and guidance to help you write high-quality apps more easily. Jetpack makes coding easier through best practices, limiting boilerplate code, and simplifying complex tasks. All with the goal of enabling you to focus on the code that you really care about. AndroidX is the package name for all the libraries within Jetpack. Think of AndroidX as the open-source project used to develop, test, version, and release Jetpack libraries. Back at I/O 2018, Google announced that Support Library would be refactored into the AndroidX namespace, which was completed with Support Library 28 and the announcement of AndroidX 1.0. Jetifier helps migrate third-party dependencies to use AndroidX. Jetifier will change the byte code of those dependencies to make them compatible with projects using AndroidX. Having Jetifier enabled on your project ( android.enableJetifier = true on your gradle.properties ) impa

This article will explain why I believe that generating the BuildConfig class for Android library modules is a bad idea. It’s important to highlight that I am not talking about the app module BuildConfig , I am talking about all the other BuildConfig files generated by each android module. First of all, I would like to clarify some terms, so you better understand this article: when I say debug code, I am talking about the code available on the local builds used by developers when they pick the debug variant. It is typically located at src/main & src/debug source sets. when I say release code, I am talking about the code distributed on your release APK/AAB. It means the release variant. It is typically located at src/main & src/release source sets. The Reasons These are the main reasons to disable BuildConfig.java generation: Generating the BuildConfig file for each module has a build speed penalty BuildConfig is generated as a Java file. But having a module with mi

  Using more and more dependencies on Gradle projects is a common practice. Keeping your Gradle project dependencies up to date can be a huge manual task if you have a big project. It’s a bit tedious for developers to manually check for dependencies upgrades, causing a lot of waste of time. Furthermore, developers don’t perform dependencies upgrades as frequently as they should, harming project quality and security. In particular, Android projects are not an exception. Google offers a lot of official libraries, in some cases with linked versions, like Firebase or Play Services. The Releases Hub Gradle Plugin helps developers to keep their dependencies up to date, reducing some tedious manual tasks like remembering to look for dependencies upgrades, upgrading the dependencies on the Gradle configuration and creating a PR with the changes. The plugin automatically upgrades your Gradle project dependencies and send GitHub pull requests with the changes. The Plugin Features Automatic Gi

Google offers lots of official libraries and tools to help developers integrating with their products and also to simplify complex tasks. Staying up to date with all of them is a bit hard for android developers. You can use Android Studio warnings on your build.gradle when a new artifact version is released, but sometimes this is not enough. If you have your artifacts declared on multiple build.gradle files, it’s expensive to verify each of them. The same happens if you work on multiple projects at the same time. This problem was increased after Google decided to decouple the release of each Play Services and Firebase SDK libraries. Now, each library has its own version and we have many releases to be aware of. Based on this, We would like to introduce the first two of a series of tools to help developers stay up to date with all these releases: Releases Hub on Twitter & Releases Hub on Slack . On this Twitter account and Slack workspace, you are going to get real-time notifica

There are so many ways to work with git branches and they usually vary according to the kind of project, development process and technologies being used. In this story, I want to propose an approach to git branching for android apps that are published on Google Play. As you know, Google Play offers the ability to have multiple releases of your app published at the same time and targeting different user segments. I’m talking about the Alpha/Beta testing and the Staged Rollout tools. If you are currently using them, I suggest you take into account some considerations when defining your git branches. Main branches I call main branches the ones that represent a certain phase in your development cycle. Let’s talk a little bit about my suggestions. master This is the branch where the development progresses. It always contains the latest cutting-edge version of the project, but therefore may also mean the most unstable version. staging This is the branch where the next version to be rele

If you are developing an android library (open source or not), it’s a good idea to follow some guidelines to guarantee high quality and also simplify your users and collaborators life’s. Here are some examples of best practices I recommended and also, tips you can follow. 1. Resources Prefixes If any of your users override an android resource of your library by mistake, it can be very dangerous. For example, they could create a string resource with the same name you defined inside your library. One way to avoid this (or at least reduce the chances of a name conflict) is to assign a prefix to all your library resources. The prefix could be for example your library name or package name. You should add it to all the files inside the following directories res/drawable res/layout res/menu res/xml res/raw Additionally, prepend the prefix to the name of these resource types string plurals color dimen declare-styleable style bool You can also declare your library’s prefix on your build.gradle