I’ve always been interested in performance testing, back in February I gave a talk about how to write and automate performance tests at MobOS. Today I want to show you what the majority of talk was about which is how to use and improve the test jank library that you probably didn’t know Android provides us.

You can find all the code from this article and much more at this GitHub repository which I created for this talk:

https://github.com/marcosholgado/performance-test

You should be able to follow the different approaches and enhancements step by step looking at the tests in that repo but I will point to different files in this article so you don’t get lost. …

Last week I gave a talk at MobOS about writing and automating performance tests in Android. As part of the talk I wanted to demonstrate how you could detect memory leaks during your integration tests. To prove that, I created an Activity using Kotlin that was supposed to leak memory but for some reason it didn’t. Was Kotlin helping me out without me knowing it?

Before I begin, the code of this article is available at the kotlin-mem-leak branch of my performance-test repo:

https://github.com/marcosholgado/performance-test/tree/kotlin-mem-leak

The whole premise was simple, I wanted to write an activity that would leak memory so I could detect that during an integration test. Because I was already using leakcanary I copied their sample Activity to recreate a memory leak. …

In the fourth part of this series we learnt how to integrate a third party API like Jira Cloud Platform in our plugin and to use patterns like MVP or MVC to do so. In today’s article I’m going to refactor some parts of our plugin to clean up the code a little bit so we can localize our plugin and use notifications in an easier way.

What are we going to do?

Today’s goal is quite simple, we are going to try to clean up the code of our plugin. To do that I’m going to focus on two areas: notifications and strings.

We will explore a way of removing all the hardcoded strings that we currently have and move them into a single place, a little bit like the strings.xml that we all know which will also give us internationalization and localization for free. …

A few days ago I started building a simple app to explore clean architecture a little bit. One of the features was for the user to be able to select two items and then take her/him to another screen. I didn’t want to spend time on implementing the multi-selection part so I decided to try the recyclerview-selection library. This article explains how I implemented it and the problems that I encountered.

Step 0: Building the app

To begin with we are just going to implement a simple app that will show a list of 10 random numbers. This should be a simple exercise but just in case here is the code of the Activity and the adapter. …

In the third part of this series we learnt how to create a new Settings screen using components to persist its data. In today’s article we are going to use that data to quickly integrate Jira with our plugin.

Remember that you can find all the code for this series on GitHub and you can also see the relevant code for each article on its own branch, this article’s code is in the branch Part4.

https://github.com/marcosholgado/plugin-medium

What are we going to do?

The goal for today’s article is to explain how you can integrate third party APIs and libraries into your plugin. …

In my last article I talked about how to use Dagger in a multi-module project, if you haven’t read it yet, I would recommend you do it so before continuing since we will be reusing the same project. After I published the article I got a lot of questions about how I would approach a multi-module project using dagger-android instead. In this article I will talk about dagger-android and re-implement what we did in the last article but this time using dagger-android instead.

Before I begin, remember that you can find the code of the previous article in the following GitHub repository (multi-module…

A bit more than a year ago I started to modularize our codebase. Back then, there was a lot of talking around the subject but no one really focused on how you could use Dagger in a multi-module environment which was one of the main problems I had. In this article I want to explain the approach we ended up taking a year ago and that we are still using.

Note: This article assumes you already know the basics of Dagger.

What we had

I started (like many others) with a monolithic codebase where everything was built within the same module, the main app. In our case, that was even more complicated because we were in fact building 4 different apps using the same codebase but that is a different story. Inside that monolithic app we had our features kind of separated using a feature-package approach (check that awesome article by Joe Birch). Dagger wise, our app had a MainComponent with shared dependencies. …

In the second part of this series we learnt how to persist data using components and also how to use that data to trigger a notification when users updated our plugin to show them what’s new. In today’s article we will see how we can use the data that we are persisting to create a settings screen.

Remember that you can find all the code for this series on GitHub and you can also see the relevant code for each article on its own branch, this article’s code is in the branch Part3.

https://github.com/marcosholgado/plugin-medium

What are we going to do?

The goal of today’s article is to create a settings screen for our plugin. This is going to be our first step towards creating an action to move tickets on Jira. Our settings screen will just have a username and a password field that our plugin will use to interact with the Jira APIs. We also want to be able to have different settings per project allowing the users to have different Jira accounts depending on the project (this may be useful). …