Posts

Effective handling your tech debt

-
Image
 A simple guide to help you effectively handling the tech debt on your project. As you may know, all the projects have some kind of tech debt. It’s normal, not a signal of bad developers. It’s also important to understand that even if you don’t touch your code for a while, your tech debt can increase. This can sound strange but constantly there are: new ways to do things, some of them can be official recommendations of the platforms you use external libraries are deprecated or upgraded If you don’t have an effective process to handle this, your tech debt is going to grow to the infinite. Even if you have such a process, that’s not a guarantee of success. You need to follow it, define goals and reach them if you want to reduce your tech debt across time. This guide is focused mainly on Java / Kotlin projects, but most of the tips can also work on other platforms too. Kinds of tech debt Let’s start defining some types of tech debt. These are just some examples. There are more, of course
Post a Comment
Read more

Circle CI + Android configuration tips

-
Image
8 ideas to improve your Circle CI configuration on android projects 1. Define executors for each resource class Sometimes you need to quickly change the resource class you use on your job’s executor. For example, you could need to do that to measure the performance impact or because you need more memory/CPU. You can simplify those changes by defining one executor per resource class. Each executor could have for example custom GRADLE_OPTS defined. references: android_config : &android_config working_directory : "/path" docker : - image : circleci/android:api-30 executors : android_executor_small: << : *android_config resource_class : small GRADLE_OPTS : -Dorg.gradle.jvmargs="-Xmx2g -XX:MaxPermSize=2g" android_executor_medium: << : *android_config resource_class : medium GRADLE_OPTS : -Dorg.gradle.jvmargs="-Xmx4g -XX:MaxPermSize=4g" android_executor_medium_plus: << : *android_config
Post a Comment
Read more

Say bye-bye to Android Jetifier

-
Image
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
Post a Comment
Read more

Stop generating the BuildConfig on your Android modules

-
Image
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
Post a Comment
Read more

Automate Dependencies Upgrades With Releases Hub

-
Image
  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
Post a Comment
Read more

Stay up to date with Android libraries releases

-
Image
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
Post a Comment
Read more

Semantic Git Branching for Android apps

-
Image
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
Post a Comment
Read more