android - Kotlined.com

Why you should be using OpenAPI right now?

In Karumi, we are always looking for technologies and tools that help us and help our clients to produce, evolve, and maintain their products with the highest quality and robustness in mind. Most of the time, we have to develop some mobile clients that will consume an already established backend API; or develop both the backend services and the clients using them.

One tool that has been hanging in our belt for the last couple of years is OpenAPI, previously known as Swagger and we are more than pleased with it, so now, it’s my turn to convince you about why you should be using it if you work at any side of an API.

This first blog post is the beginning of a series that will guide you in defining, offering, and consuming an API built from scratch.

What’s OpenAPI?

OpenAPI is a specification that defines a standard that can be used to describe RESTful APIs in an agnostic language manner that helps programmers to understand and modify it.

Based on that specification, several tools will help you to automatically generate the code that exposes that service, the code consuming it, and even the documentation about it.

Why should I use OpenAPI?

Automatization.

The feature that got our attention to invest time in OpenAPI was the ability to generate the API clients automatically, so we don’t have to bother anymore about model changes and parsing issues for an updated response. Instead of that, once the specification is modified, we run our client generator, and our project is ready to be using the latest changes offered.
You may end up changing some parts of your code to adopt that new client changes, but that’s something you would have to do anyway.

If your API client is generated automatically out of your project, it can be integrated, handled, and consumed like any other third party dependency. Besides that, it avoids all the usual boilerplate you have to program in every project.

OpenAPI can generate the code for most of the programming languages out there, so once you’ve defined the API, you can build in a matter of seconds the client for iOS and Android, to name some platforms.

Single point of truth.

Once you describe your API (that means endpoints, objects, path, etc.) using one single file, you could convert that description into a specific implementation; it does not matter if it’s server-side or client-side. That code will be a product of that description, once you change it there, all the “artifacts” produced out of that file could be regenerate to be used.

That avoids API integration failures like errors parsing invalid responses due to a misalignment between the back-end-offered API and the client-consumed API.

Definition first.

Suppose you decide to go all the way down with OpenAPI and produce the API integration automatically for both the backend and the clients; you will be forced to define your API before implementing anything about it, in any of the sides of it, obtaining a 100% framework biases-free API.

What does it mean? It means that the API definition will be the product of a well-thought process instead of just returning the models the backend already have around. This will force both sides to adapt themselves to work with the API being defined; this approach will put in a 50/50 relationship the client/server weight to describe how they communicate.

Another benefit of having the API definition first is that you can implement both sides without interacting with each other. As you know, there is a contract that is being respected at both sides of the API. If you are implementing a mobile client, you can even develop your tests using HTTP stubs to respond with responses that will be the same as the server will respond.

100% Human readable with the documentation always up-to-date.

The OpenAPI definition file can be described in JSON or YAML, being both quite easy to read as a human and easy to modify if required. This is quite important. It’s way easier to discuss how to make some changes over an easy-to-read document than discuss those changes over a specific programming language or framework.

There is something worse than having no documentation, and that is having out-of-date documentation. As a side-effect of the single point of truth, if you whole API specification is kept in just one format, and several tools can automatically process it, and one of that tools is the documentation generator, so your API documentation (even if it is just for internal usage) won’t be outdated ever again.

Industry standard.

OpenAPI is the current defacto industry standard for API definition, so offering your API using this specification guarantees that any other company will be able to use your services out-of-the-box without any extra setup. That could seem uninteresting for a lot of companies that create their API to be closed, but this technology does not force you to open anything, it will help you to have your API specified using a well-known tool so it can be published if required.

Open-Closed principle down to the roots.

What if I need a specific implementation for my client/server, and it’s not present in the current languages? No problem at all, you can define your own template.
OpenAPI under the hood will use a templating-engine to transform any custom template into some source code. This isn’t as easy as invoking it for Kotlin or Scala, but you can create your generation without substantial modification in the generator.

What’s next?

In the next blog post, we will define a basic API to show how this technology work, and we will generate the API interface for a Spring Boot server and an iOS client that will consume it.

Photo by Neven Krcmarek on Unsplash

JetPack Compose — State Management

IJetPack Compose 🏹 — State Management

It refers to manage the state of the user interface while interacting with widgets like text fields, buttons, radio buttons, etc.

State Management in Android is a complex concept and to know the reason you have to first understand the architectural design of Android and to learn why it’s the key requirement to manage state. The Marcelo Benites article Managing State in Android defines the best description of the state:

The state is an object that is connected/subscribed to one or more widgets, contains data, and eager to update the widgets from that data. If there’s any change happens in data, it notifies all widgets to whom it’s connected. The values of the state are changed at runtime.

In jetpack compose the concept of state management is the same as Observable pattern which stated that if there is any change that occurs in the subscribed object, it triggers all of its dependent objects automatically.

In addition to the above concept, jetpack compose has some functional change, which states that the subscribed @ composable function(s) recomposes itself with the new data when the state/object value is updated and doesn’t affect or update the whole UI.

According to the state management document, jetpack composes support state using two ways:

remember { mutableStateOf(…) }
MutableStateOf

In the past, we used @Model annotation but it was deprecated in 0.1.0-dev12. Then state{} annotation deprecated in 0.1.0-dev16.

Let’s discuss it in detail:

remember { mutableStateOf(…) }

It’s an extended version of State

This approach is the same as what we did in state the only change we see is the calling. Let see what composable team said about it:

Mark the state composable as deprecated and promote the direct usage of remember { mutableStateOf(…) } instead for better clarity and understanding of the Compose state management API surface. This reduces the overall API surface and the number of concepts for state management and matches the `by mutableStateOf()` pattern for class property delegation.

In this concept, the object is initialized in the same scope where the mutation is implementing. The best possible initialization is inside the @compose function. It also follows the same Kotlin object hierarchical pattern like to pass as a reference to another function. Now, you have a scenario in which you want to mutate the object that’s initialized outside of the scope, then the next approach mutableStateOf is useful.

How to use remember { mutableStateOf(…) } approach

MutableStateOf

mutableStateOf and property delegates

mutableStateOf API allows us to create MutableState instances outside of class. In this approach, each property is observed individually, so the recompositions you see after this refactor could be more narrow. 🤔

In simple words, it says that read and write operation on each property is watched by compose and if there’s any property change, the composable triggers all of the composed indexes where this property is observed. It also gives us the value property on execution.

See the whole concept of mutableStateOf from the below-defined example:

https://medium.com/media/37747fbc39db213d521e6a1fa8c3bba1/href

If you want to get more clarification then route to my Scaffold tutorial:

AliAzaz/PracticeComposeExamples

The output of scaffold is:

I hope this article was useful to cover the basic questions regarding Jetpack Compose state management and explore the benefits behind it. Follow me on Twitter for more updates:

Thanks for spending your time reading this article. Please share if you’ve enjoyed it!

Connect with me on my socials and become my friend on Medium, Github, and LinkedIn.

Click 👏 to say “thanks!” and help others find this article.

To be up-to-date with great news on Kt. Academy, subscribe to the newsletter, observe Twitter, and follow us on Medium.

If you need a Kotlin workshop, check how we can help you: kt.academy.

JetPack Compose 🏹 — State Management was originally published in Kt. Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kotlin DSL — know your limits

Kotlin DSL —defining mandatory parameters

Or why I wrote another Android library

Since Kotlin was introduced, multiple libraries have opt-in for DSL implementation of their API.
Kotlin DSL is a great tool, it makes your API more readable and easier to use, and if you haven’t gotten around to play with it, I strongly encourage you to give it a try.

But this article is not meant to explain how to implement an API based on Kotlin DSL, there are some great articles about it out there.
Nor am I going talk about how awesome Kotlin DSL is (and it is).
Instead, I’ll focus on the problems I faced when I tried to apply it to my own use cases.

First

https://medium.com/media/850a7346dec798d01d2c96efa93a19a1/href

A nice example for DSL can be found in an Android library called Anko, which allows laying out UI components programmatically (might look familiar to Flutter/Jetpack devs):

verticalLayout {
   editText {
    hint = "Name"
    textSize = 24f
  }  
   button("Say Hello") {
    onClick { toast(“Hello!”) }
  }
}

Looks pretty easy to understand, right?

So, where’s the catch?

Let’s take a closer look:

button("Say Hello") {
    onClick { toast("Hello!") }
}

As you can see, the button text is supplied as a parameter since it’s mandatory for the creation of a button, as opposed to the onClickListener which is optional and therefore defined inside the lambda block.

For a single parameter, this still seems quite readable, but what if there were multiple mandatory parameters?

After giving DSL a try, what I soon found out is that I had the same problem as with plain old Builders — receiving mandatory parameters.

What’s the solution then?

The obvious solution is to verify all mandatory parameters are set as part of the final object build, but that’s a runtime solution and a sign of bad API in my books.

Another solution I would use in builders was to define mandatory parameters in the constructor.
The same trick works for DSL, but I found it contradicts one of the purposes of DSL — being readable.

The final option I tried is using Kotlin Contracts, which I quickly ruled out for two reasons:
1. I didn’t feel it was mature enough.
2. They only apply for top-level functions, not exactly what I was looking for.

https://medium.com/media/b524e2fd23b6d1b3287bb1bc5bdd2f55/href

My goal was clear — a compile-time verification of mandatory parameters.
I wanted a simple solution to this common problem.

Introducing DSLint

Eventually, I decided to be my own best friend and implement a solution to this problem using a custom Android linter library (sorry non-Android devs).

So here’s how it works, let’s say I was to implement a Person builder using DSL and wanted to make sure the person’s name was set.
All I need to do is annotate the class and the name property and let my custom linter do the magic:

@DSLint
class Person {

    @set:DSLMandatory
    var name: String
}

Clean and simple.
I made it open source, so you can either use it in your project or clone the repo and create your custom solution based on it.

You can grab a look here:

ironSource/dslint

To sum up

As I previously said, DSL is a great tool and I encourage you to try it but also be aware of its limits.
I hope you enjoyed reading and I look forward to hearing about the challenges you faced when trying out DSL and how you approached them.

Click the 👏 to say “thanks!” and help others find this article.

To be up-to-date with great news on Kt. Academy, subscribe to the newsletter, observe Twitter and follow us on medium.

If you need a Kotlin workshop, check how we can help you: kt.academy.

Kotlin DSL — know your limits was originally published in Kt. Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Method references and lambdas in lazy properties

Method references and lambdas in lazy properties was originally published in Kt. Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Implementing Pagination for fetching Instagram photos

Before starting this tutorial, I recommend you to read about Pagination Library in Android.

Here, we are going to implement pagination for fetching user photos from Instagram using the MVVM pattern. Let’s start now.

https://medium.com/media/657a47571fda328576c2459a3715a7af/href

1. Configuration

To configure pagination in our project use

https://medium.com/media/1f814c2600b4f67a2bfdff0c5500ce21/href

for integrating Instagram please follow these steps.

Go to the next step when you have the required access token for Instagram.

2. Setting up network calls

Setting up Retrofit client

https://medium.com/media/d5c7a5ab893de5db1f8941a7817a22b9/href

Creating our media model

https://medium.com/media/069daead14ebe22689b54bf78f8d198a/href

3. Create a Repository for fetching data

We will be displaying only photos, so we need:

media_type -> to filter images/album

media_url -> to load images from URL

children -> used only in case of a carousel album. We will define the same fields for children nodes too

https://medium.com/media/9adf75fa87dc88cac1a2150e8918354f/href

4. Creating a Data source

There are 3 types of Data source available. You can use any of the below Data source as per your requirement.

ItemKeyedDataSource -> if you need to fetch data from last fetched item id.
PositionalDataSource -> if you need to fetch data from a specific position/page.
PageKeyedDataSource -> if pages you load embed next/previous keys

We will be using PageKeyedDataSource as we get next/previous pointers in response from Graph API.

Initially, we will pass them the next cursor as null. Then the adapter will load data until the params.key or next is null.

On getting InstagramMediaModel in API response we supply the data along with previous and next keys to the callback object. In case of error, we simply pass an empty list and the next pointer as null.

https://medium.com/media/e3d6f26016982aa03d5ef01bd6212dda/href

getFilteredList method filters the response list and provides a single list consisting of all photos from an individual post as well as from an album post.

5. Creating a Data Source Factory

Data-loading systems of an application or library can implement this interface to allow LiveData<PagedList> to be created

https://medium.com/media/19dc788034a45e5137f52297bfb83c36/href

6. Creating List Adapter

A simple PagedListAdapter to inflate the photo item into our layout. PagedListAdapter internally extends RecyclerView.Adapter. It takes 2 parameters:

data -> the type of list. Here, InstagramMediaModel.Data? is our item type,
ViewHolder.

We also provide a DiffUtil class. It is a utility class which is used to calculate the difference between old and new list supplied to the adapter and outputs the update operation to convert old into a new list. It uses an efficient mechanism to communicate with updates to the recycler view.

https://medium.com/media/9539ee8d375e424ef0bfabea283637b5/href

7. Creating ViewModel

This ViewModel will be used for creating the paged list. That PagedList will ask InstagramPhotosDataSource to load all the photo list and also will hold the photo item. For fetching the data it uses background executors.

To build PagedList we use:

DataSourceFactory -> to fetch data form,
PagedList configuration -> configuration of pagedList such as initial page size, size of loaded items when the list is first initialized, enable/disable placeholders, etc.

https://medium.com/media/7fbf19c9e84334df40236a97761ec668/href

8. Presenting list inside Activity

Initializing adapter inside our activity. If we receive a null list than we can check if there is an error. If the adapter does not hold any list previously, then we can handle our error case on the view (for now, I am showing a snackbar), otherwise we submit the list to our adapter and it appends the new list to the current list.

https://medium.com/media/a76afe2d7c2e97b8d515d2a180fd7b23/href

That’s all! Now you can try this inside your app.

Suggestions are always welcome! Happy Coding!

Implementing Pagination for fetching Instagram photos was originally published in Kt. Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Concatenate Strings in Kotlin…Behind the scene(1/4)

Concatenate Strings in Kotlin…Behind the scene🎃

The pandemic situation in the world, but #Kotlin is here to facilitate developers in string concatenation.

Concatenate Strings in Kotlin…Behind the scene(1/4)🎃 was originally published in Kt. Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our Android 2020 development stack

One of the questions we face when talking with Android developers all around the world is related to the tools we use 🤔 The selection of libraries and frameworks used by our Android team is one of the most interesting details in our development pipeline, so we will try to answer this question in this blog post 😃

When listing the libraries we use, we need to focus on various types of tools based on different topics: static analysis utilities, build tools, networking, persistence, permissions, user interface, core components, and testing. We have a bunch of tools we’ve used for years, and we will review them one by one.

Static analysis utilities & build tools:

These tools are really helpful for us. All they help us to go faster in our daily tasks by automating tasks or any other checks we want to do in our codebase 😍

Ktlint: Best Kotlin linter in town.
Android Lint: The best safeguard for your Android apps.
Lin: An awesome tool used to simplify the usage of the Android Linter created by @serchinastico. Really handy when we want to create custom rules!
Ribbonizer: Simple but powerful tool to add a ribbon to launcher icons.
Play publisher: Needed to automate our release process for internal and public releases.

Networking:

It’s been a while since we started using tools to generate our networking layer based on a Swagger or OpenAPI yaml file, so the libraries we use under the hood are not so relevant. For our latest project, we’ve used this gradle plugin to generate our API client. However, when there is no chance to generate the API client, and there is no way we can create an OpenAPI file, we use these libraries:

Retrofit: If you don’t know this library, you are going to love it! It generates a lot of code for you just from an interface 🤩
OkHTTP: The best HTTP client you are going to find. Simple, but powerful 🙂
Gson: We’ve been using this library for years! There are other alternatives if you want, but we have to admit we always use this one when using automatically generated code 😃

As the code generated is completely coupled to the libraries used by the generator and the models created by this tool, we always wrap it with an adapter to avoid coupling issues.

Persistence:

We all know how handy our loved shared preferences can be… However, when we need a database, we have two choices:

Room: Officially maintained by Google, this is one of the best choices when you need a database.
SQLDelight: Generates typesafe Kotlin APIs from SQL queries.

For years we used Realm, but nowadays, the tooling for SQLite is excellent now, so we moved to one of the previous alternatives.

Permissions:

After years developing and maintaining a library to simplify the usage of permissions, we keep using Dexter! This library simplifies a lot the usage of the permissions API, letting you get the answer of a permission request in a callback instead of using the famous onActivityResult method.

User interface:

There is a bunch of libraries we use to build our applications user interface, so we are going to drop here just the most relevant ones:

Data Binding: The key to success when talking about the usage of MVVM four our presentation layer.
Lifecycle Observer: Handy when you want to listen for the events related to the component’s lifecycle without coupling the implementation to any concrete component.
Appcompat: Useful when we need to use components in old Android APIs.
ConstraintLayout: The best way to create a responsive layout.
Glide: Useful when you need to download and show images asynchronously.
Renderers: We’ve been using this library for years and is one of the best libraries to work with recycler view.
Calligraphy: Nice library if you want to use custom fonts and for some reason you had no idea this was supported since 2017 🙂 (Thanks random reddit user for pointing me this detail out)
Material Components: We try to use standard material components when possible, so this library is really helpful because there is a bunch of them already implemented.
Snacky: World-class library if you want to show a snackbar.
Lottie: Render After Effects animations natively on Android.

Core components and other useful libs:

There are always a bunch of libraries we need deep down in our architecture, and we them use in every project. Let’s talk about these:

Kotlin: Of course!!
Coroutines: Asynchronous programming with the best syntax in town.
Timber: A small and extensible logger.
Libphonenumber: When working with phone numbers in international formats, this library is the best option.
OneSignal: One of the best push notifications provider. Depending on the projects, we use the native support, but when possible we use OneSignal.
Kodein: For the last projects, we’ve used this dependency injector. However, we recommend you to choose your dependency injector based on your needs!
ThreeTenABP: Do you have to work with different regions for your dates? Take a look at this JSR-310 backport for Android.
Crashlytics: We’ve used this crash reporter for years, and we never regret.
Arrow: We tend to use more and more functional programming concepts in our software design, and we have to admit lenses, the core component, and the effects API are in all our Android projects.
Leakcanary: The best memory leak detection library.

Testing:

Prepare your speed face! This is going to be intense:

JUnit: Classic test runner.
Shot: Handy screenshot testing library.
Kotlin Snapshot: If you are looking for snapshot testing, this is your kotlin lib!
Kotlin Test: Because sometimes we need to use property based testing and this framework provides an awesome support.
Mockito: If you write unit tests, you’ll need a mocking library.
MockWebServer: Really handy when we want to write tests to ensure our API client is implemented properly.
Robolectric: Needed to run our instrumentation tests as fast as possible.
Espresso: Needed to be able to interact with the user interface in our UI tests!
Barista: Espresso’s best friend.
Jacoco: Needed to get a unified code coverage report.
Bitrise: The best CI & CD platform we’ve tested for mobile for now. Even when we prefer any platform we can configure using a yaml file like Travis CI. Bitrise’s emulator performance is way better in this platform than any other competitors.

For us, the key to success in our testing strategy is simple. We need to be able to replace any dependency using test doubles when required. To do this, we use the dependency injector from our UI tests, or we do it manually in our unit and integration tests 😃 If you’d like to know more about it, take a look at these blog posts and also remember to take a look at our testing training.

This is it! 👏 Nevertheless, I’m sure you are missing some libraries while ready this post 🤔 and we miss a bunch too! What about all these jetpack libraries we didn’t mention, and Google released months ago? We use them depending on the projects and the people involved in the project:

LiveData: When we use room, and we want to connect our UI with the database using an observable implementation, we use this library.
Navigation: It all depends on the developer responsible for the project. I don’t personally use it but, I’ll give it a go on my next project!
ViewModel: I use a custom implementation linked with the dependency injector and the lifecycle observer library. However, some of use this library.
WorkManager: We don’t always have to schedule tasks, but when we need to do something like this, this is the library we use.
CameraX: Used only when needed 📸

If you’d like to know more about these Jetpack Libraries remember we have some training about the most relevant components you can request us when needed.

Now we are over Android friends! I hope you enjoyed this 2020 libraries, frameworks, and tools review 😃 If you use a similar stack or you think there is any other library we should use, please, let us know in the comments section! See you soon 🤘

Photos by the Google Andorid Team, the Arrow Team, the Open API Generator organization and Mindorks.

Our Android 2020 development stack

One of the questions we face when talking with Android developers all around the world is related to the tools we use 🤔 The selection of libraries and frameworks used by our Android team is one of the most interesting details in our development pipeline, so we will try to answer this question in this blog post 😃

When listing the libraries we use, we need to focus on various types of tools based on different topics: static analysis utilities, build tools, networking, persistence, permissions, user interface, core components, and testing. We have a bunch of tools we’ve used for years, and we will review them one by one.

Static analysis utilities & build tools:

These tools are really helpful for us. All they help us to go faster in our daily tasks by automating tasks or any other checks we want to do in our codebase 😍

Ktlint: Best Kotlin linter in town.
Android Lint: The best safeguard for your Android apps.
Lin: An awesome tool used to simplify the usage of the Android Linter created by @serchinastico. Really handy when we want to create custom rules!
Ribbonizer: Simple but powerful tool to add a ribbon to launcher icons.
Play publisher: Needed to automate our release process for internal and public releases.

Networking:

It’s been a while since we started using tools to generate our networking layer based on a Swagger or OpenAPI yaml file, so the libraries we use under the hood are not so relevant. For our latest project, we’ve used this gradle plugin to generate our API client. However, when there is no chance to generate the API client, and there is no way we can create an OpenAPI file, we use these libraries:

Retrofit: If you don’t know this library, you are going to love it! It generates a lot of code for you just from an interface 🤩
OkHTTP: The best HTTP client you are going to find. Simple, but powerful 🙂
Gson: We’ve been using this library for years! There are other alternatives if you want, but we have to admit we always use this one when using automatically generated code 😃

As the code generated is completely coupled to the libraries used by the generator and the models created by this tool, we always wrap it with an adapter to avoid coupling issues.

Persistence:

We all know how handy our loved shared preferences can be… However, when we need a database, we have two choices:

Room: Officially maintained by Google, this is one of the best choices when you need a database.
SQLDelight: Generates typesafe Kotlin APIs from SQL queries.

For years we used Realm, but nowadays, the tooling for SQLite is excellent now, so we moved to one of the previous alternatives.

Permissions:

After years developing and maintaining a library to simplify the usage of permissions, we keep using Dexter! This library simplifies a lot the usage of the permissions API, letting you get the answer of a permission request in a callback instead of using the famous onActivityResult method.

User interface:

There is a bunch of libraries we use to build our applications user interface, so we are going to drop here just the most relevant ones:

Data Binding: The key to success when talking about the usage of MVVM four our presentation layer.
Lifecycle Observer: Handy when you want to listen for the events related to the component’s lifecycle without coupling the implementation to any concrete component.
Appcompat: Useful when we need to use components in old Android APIs.
ConstraintLayout: The best way to create a responsive layout.
Glide: Useful when you need to download and show images asynchronously.
Renderers: We’ve been using this library for years and is one of the best libraries to work with recycler view.
Calligraphy: Nice library if you want to use custom fonts and for some reason you had no idea this was supported since 2017 🙂 (Thanks random reddit user for pointing me this detail out)
Material Components: We try to use standard material components when possible, so this library is really helpful because there is a bunch of them already implemented.
Snacky: World-class library if you want to show a snackbar.
Lottie: Render After Effects animations natively on Android.

Core components and other useful libs:

There are always a bunch of libraries we need deep down in our architecture, and we them use in every project. Let’s talk about these:

Kotlin: Of course!!
Coroutines: Asynchronous programming with the best syntax in town.
Timber: A small and extensible logger.
Libphonenumber: When working with phone numbers in international formats, this library is the best option.
OneSignal: One of the best push notifications provider. Depending on the projects, we use the native support, but when possible we use OneSignal.
Kodein: For the last projects, we’ve used this dependency injector. However, we recommend you to choose your dependency injector based on your needs!
ThreeTenABP: Do you have to work with different regions for your dates? Take a look at this JSR-310 backport for Android.
Crashlytics: We’ve used this crash reporter for years, and we never regret.
Arrow: We tend to use more and more functional programming concepts in our software design, and we have to admit lenses, the core component, and the effects API are in all our Android projects.
Leakcanary: The best memory leak detection library.

Testing:

Prepare your speed face! This is going to be intense:

JUnit: Classic test runner.
Shot: Handy screenshot testing library.
Kotlin Snapshot: If you are looking for snapshot testing, this is your kotlin lib!
Kotlin Test: Because sometimes we need to use property based testing and this framework provides an awesome support.
Mockito: If you write unit tests, you’ll need a mocking library.
MockWebServer: Really handy when we want to write tests to ensure our API client is implemented properly.
Robolectric: Needed to run our instrumentation tests as fast as possible.
Espresso: Needed to be able to interact with the user interface in our UI tests!
Barista: Espresso’s best friend.
Jacoco: Needed to get a unified code coverage report.
Bitrise: The best CI & CD platform we’ve tested for mobile for now. Even when we prefer any platform we can configure using a yaml file like Travis CI. Bitrise’s emulator performance is way better in this platform than any other competitors.

For us, the key to success in our testing strategy is simple. We need to be able to replace any dependency using test doubles when required. To do this, we use the dependency injector from our UI tests, or we do it manually in our unit and integration tests 😃 If you’d like to know more about it, take a look at these blog posts and also remember to take a look at our testing training.

This is it! 👏 Nevertheless, I’m sure you are missing some libraries while ready this post 🤔 and we miss a bunch too! What about all these jetpack libraries we didn’t mention, and Google released months ago? We use them depending on the projects and the people involved in the project:

LiveData: When we use room, and we want to connect our UI with the database using an observable implementation, we use this library.
Navigation: It all depends on the developer responsible for the project. I don’t personally use it but, I’ll give it a go on my next project!
ViewModel: I use a custom implementation linked with the dependency injector and the lifecycle observer library. However, some of use this library.
WorkManager: We don’t always have to schedule tasks, but when we need to do something like this, this is the library we use.
CameraX: Used only when needed 📸

If you’d like to know more about these Jetpack Libraries remember we have some training about the most relevant components you can request us when needed.

Now we are over Android friends! I hope you enjoyed this 2020 libraries, frameworks, and tools review 😃 If you use a similar stack or you think there is any other library we should use, please, let us know in the comments section! See you soon 🤘

Photos by the Google Andorid Team, the Arrow Team, the Open API Generator organization and Mindorks.