If you're building an Android app, you should consider adding animations. They can improve your app's user experience and increase retention.

These days, if you see an app that has no animation, it can feel odd and out-dated. And since interactive experiences are kind of the new norm, you'll want to figure out ways to set your app apart.

What We'll Build Here

Now, it might seem difficult to make your app stand out if you just have something basic like a quote sharing app (which is what we are going to work on here). It can be hard to hook the user and keep them interested.

Of course, you could just add two simple buttons to load the next/previous quote and call it a day. But that's pretty basic and any app could do that! Even if you're just building a simple side-project, there's no trade-off for good UX :)

So what we'll do in this tutorial is drop the buttons, and instead have logic where a user can swipe the card to the left. When they've swiped far enough, the app will load a new card with a new quote.

By the end of this post, you will learn how to make a really smooth animated card which a user can swipe that can perform whatever action you choose. Here's a demo of how it works:

Amazing, right? Let's get into it!

Prerequisites

For this tutorial, we will use Kotlin as the programming language for our app – but you can easily translate the code to Java and it would work the same.

For reference, this is the quote card that we wish to enable the swipe feature on.

It is an androidX CardView with a bunch of TextViews and an ImageView. There's also a ProgressBar that gets shown while loading a new quote.

We won't be making the XML code for the user interface. You can get the layout I used here from the GitHub repository, or build your own.

Here's the complete code for our Quotes app, if you wish to check it out. It uses the MVVM design pattern, but this article doesn't rely on what pattern you use for the business logic of your app, as we'll just be working on the UI part.

Now, we're ready to make that awesome swipe interface!

How to Handle Swipes in Our App

To handle swipes, we first need to set a touch listener on the card. Each time an action is performed on the card, the touch listener is called. Within the listener, we will add the logic to do the math and perform the animations.

Here is the blueprint of the touch listener we will be using:

quoteCard.setOnTouchListener(
    View.OnTouchListener { view, event ->
        when (event.action) {
            MotionEvent.ACTION_MOVE -> {
                // TODO: Handle ACTION_MOVE
            }
            MotionEvent.ACTION_UP -> {
                // TODO: Handle ACTION_UP
            }
        }

        // required to by-pass lint warning
        view.performClick()
        return@OnTouchListener true
    }
)

Here, we are specifically listening for 2 actions on the card – the ACTION_MOVE and the ACTION_UP.

• The ACTION_MOVE event is called when a user starts swiping the card, that is, moving it.
• The ACTION_UP is called when a user lifts their finger from the card, basically, when they release it.

There are many other action events that we can override, such as ACTION_DOWN that's called when a person gets hold of the view, but we don't need them for this feature.

The basic setup for the card is done, so let's figure out the swiping logic.

The math behind the swipe action

First, let's re-think what we want to achieve. Implementing functionality is easier when you know exactly what you wish to have. Your code will also make more sense when your requirements are clear.

Here, we have a quote card. We want users to be able to swipe it only to the left, and if the minimum threshold to load a new quote is reached, it should move back to its original position and load a new quote.

Now, to achieve this, let's think of it in terms of the card. Let's define the mean position as the center of the card.

Mean Position of the Card

We want the card to swipe if and only if the user swipes it to the left of the mean position.

Swipe only if moved towards the left of mean position

So how can we make this happen?

You guessed it – we will calculate the mean position and on the ACTION_MOVE event, we will check if the user swiped to the left and move the card accordingly.

How to implement the swipe logic

To implement the logic, we first need to have the starting position of the card, which is fairly easy to calculate. We will just make sure that it is calculated with respect to the full-screen width, not just the card's width.

Place these lines of code before the when(event.action) statement:

quoteCard.setOnTouchListener(
    View.OnTouchListener { view, event ->

        // variables to store current configuration of quote card.
        val displayMetrics = resources.displayMetrics
        val cardWidth = quoteCard.width
        val cardStart = (displayMetrics.widthPixels.toFloat() / 2) - (cardWidth / 2)

        when (event.action) {
            ...
        }
        ...
    }
)

First we get the displayMetrics from resources, which will give us the width of the screen using displayMetrics.widthPixels.toFloat().

Then we get the cardWidth using the width property of the quoteCard.

Finally, we calculate the starting position of the card using the formula (width of screen/2) - (cardWidth/2). Essentially, this gives us the x-coordinate of this position of the card:

Starting position of card.

Now, let's implement the code for the ACTION_MOVE event.

How to handle the ACTION_MOVE event

Inside the ACTION_MOVE block, we first initialise the newX variable that holds the new x-coordinate that the card has been swiped to.

val newX = event.rawX

event.rawX gives us the absolute value of the new coordinate with respect to the screen width.

newX will contain the x-coordinate where the user's finger is, at any given moment. The value 0.0 for newX means that the user swiped to the left-most part of the screen. And for my emulator, 1080.0 represents the right-most edge of the screen.

Since, we want the card to swipe only if newX is less than the mean position of the card, we will place an if-condition here to verify that this is the case.

Think of this with simple values. Let's suppose that the mean position of the card is at x-coordinate 540.0 (small x-coordinate) and the user swipes to 710.0 (bigger x-coordinate). But we don't want them to be able to swipe to the right. And if the user swipes to 320.0 (smaller x-coordinate), then we need to carry out the swipe and move the card to the new position.

Here's the code to implement the above logic:

if (newX - cardWidth < cardStart) { // or newX < cardStart + cardWidth
    quoteCard.animate().x(
        min(cardStart, newX - (cardWidth / 2))
    )
    .setDuration(0)
    .start()
}

We subtract cardWidth from newX because newX is an absolute value which is not relative to the card. It has a higher value because cardStart is towards the start of the screen, and newX is initially somewhere in the middle (a user would generally swipe from the middle).

We want to compare the value of shift in the x-coordinate and median to the value of cardStart, not the value of newX, so we take this into account by subtracting cardWidth.

Then, we carry out the animation using quoteCard.animate() and we change its x coordinate using the x() function.

Now, why do we do min(cardStart, newX - (cardWidth/2))?

This is very interesting and intuitive to understand. From the beginning, we are emphasizing that the card should move only to the left and not to the right.

newX - (cardWidth/2)) is nothing but the swiped distance towards the left (so subtraction is involved – for the right side, it should be added).

The min() function here returns the minimum of the two values provided. If the swiped distance is less than the cardStart, it is returned, otherwise cardStart is used. This is the condition we want to meet and min() makes it really easy to handle.

setDuration(0) ensures that the animation is carried instantaneously (which keeps swiping from feeling laggy). start() actually starts the animation with the given properties.

This animation will clear any doubt your have on how this works:

Visualisation of the aforementioned concept

(I don't have expertise on making animations, this was the best I could come up with.)

Here is the final code for the ACTION_MOVE event:

MotionEvent.ACTION_MOVE -> {
    // get the new coordinate of the event on X-axis
    val newX = event.rawX

    // carry out swipe only if newX - cardWidth < cardStart, that is
    // the card is swiped to the left side, not to the right
    if (newX - cardWidth < cardStart) {
        quoteCard.animate()
            .x(
                min(cardStart, newX - (cardWidth / 2))
            )
        .setDuration(0)
        .start()
    }
}

You can also include a TextView to the UI that reflects when the user should release the card. Place this code inside the above if statement too:

if (quoteCard.x < MIN_SWIPE_DISTANCE) textView.text = getString(R.string.releaseCard)
else textView.text = getString(R.string.infoText)

where MIN_SWIPE_DISTANCE is -250:

// -250 produces best result, feel free to change to your liking
const val MIN_SWIPE_DISTANCE = -250 // User should move alteast -250 from mean position to load new quote

Now, the ACTION_MOVE event is handled properly. Let's write the code to handle the ACTION_UP event, that is, when the card is released.

How to handle the ACTION_UP event

For the ACTION_UP event, we want the card to come back to its original position, wait for about 100 milliseconds, then load a new quote.

The logic to animate the card is similar, but this time we will make its animation duration about 150 millisecond to make it look smooth.

First, create a variable currentX that holds the current value of the x coordinate of the quote card. We'll use this variable later.

var currentX = quoteCard.x

Then, start the animation on the card. Pass the cardStart variable to the x() function to make it return to its original position and set the duration to 150.

quoteCard.animate()
    .x(cardStart)
    .setDuration(150)
// continued below

This time, we set a listener on the animation. A listener is something that keeps an eye on the animation. By using it, we can perform actions on various animation events such as start, end, resume, and more.

// continuation
.setListener(
    object : AnimatorListenerAdapter() {
        override fun onAnimationEnd(animation: Animator) {
            viewLifecycleOwner.lifecycleScope.launch(Dispatchers.Default) {
                delay(100)
                // check if the swipe distance was more than
                // minimum swipe required to load a new quote
                if (currentX < MIN_SWIPE_DISTANCE) {
                    // Add logic to load a new quote if swiped adequately
                    viewModel.getRandomQuote()
                    currentX = 0f
                }
            }
        }
    }
)
.start()

We set a listener to look for the ending of the animation by overriding the onAnimationEnd() function.

As soon as the animation ends, we launch a coroutine (similar to Threads in Java but much more efficient) with a delay of 100 milliseconds. It then checks if the user had swiped further than the MIN_SWIPE_DISTANCE needed to load a new quote. The variable currentX is used for the comparison here.

If the user actually swipes passing the minimum distance, the coroutine is delayed for 100 milliseconds. Then the view model loads a new random quote from the API, also resetting the currentX variable to 0f.

The final code for the ACTION_UP event looks like this:

MotionEvent.ACTION_UP -> {
    var currentX = quoteCard.x
    quoteCard.animate()
        .x(cardStart)
        .setDuration(150)
        .setListener(object : AnimatorListenerAdapter() {
            override fun onAnimationEnd(animation: Animator) {
                viewLifecycleOwner.lifecycleScope.launch(Dispatchers.Default) {
                    delay(100)
                    // check if the swipe distance was more than
                    // minimum swipe required to load a new quote
                    if (currentX < MIN_SWIPE_DISTANCE) {
                        // Add logic to load a new quote if swiped adequately
                        viewModel.getRandomQuote()
                        currentX = 0f
                    }
                }
            }
        })
        .start()
    textView.text = getString(R.string.infoText)
}

Final Code

This is the final code for the complete onTouchListener():

quoteCard.setOnTouchListener(
    View.OnTouchListener { v, event ->

        // variables to store current configuration of quote card.
        val displayMetrics = resources.displayMetrics
        val cardWidth = quoteCard.width
        val cardStart = (displayMetrics.widthPixels.toFloat() / 2) - (cardWidth / 2)

        when (event.action) {
            MotionEvent.ACTION_UP -> {
                var currentX = quoteCard.x
                quoteCard.animate()
                    .x(cardStart)
                    .setDuration(150)
                    .setListener(
                        object : AnimatorListenerAdapter() {
                            override fun onAnimationEnd(animation: Animator) {
                                viewLifecycleOwner.lifecycleScope.launch(Dispatchers.Default) {
                                    delay(100)

                                    // check if the swipe distance was more than
                                    // minimum swipe required to load a new quote
                                    if (currentX < MIN_SWIPE_DISTANCE) {
                                        // Add logic to load a new quote if swiped adequately
                                        viewModel.getRandomQuote()
                                        currentX = 0f
                                    }
                                }
                            }
                        }
                    )
                    .start()
                textView.text = getString(R.string.infoText)
            }
            MotionEvent.ACTION_MOVE -> {
                // get the new co-ordinate of X-axis
                val newX = event.rawX

                // carry out swipe only if newX < cardStart, that is,
                // the card is swiped to the left side, not to the right
                if (newX - cardWidth < cardStart) {
                    quoteCard.animate()
                        .x(
                            min(cardStart, newX - (cardWidth / 2))
                        )
                        .setDuration(0)
                        .start()
                    if (quoteCard.x < MIN_SWIPE_DISTANCE) 
                        textView.text = getString(R.string.releaseCard)
                    else textView.text = getString(R.string.infoText)
                }
            }
        }

        // required to by-pass lint warning
        v.performClick()
        return@OnTouchListener true
    }
}

Congrats! In this tutorial, we've implemented animation that lets a user swipe a card containing a quote to get a new quote.

Don't forget to download the app and test it out yourself. Stars and contributions on the GitHub repository are welcomed!

Conclusion

Now you have learned how to animate a card and handle animation listeners on it. This helps create better UX that makes your app stand out.

Using the knowledge you gained in this post, you can now create most of the following animations for views in Android:

• Programmatically create sliding animations for Android views.

Just as we did in this tutorial.

• Left to right animation

This is fairly simple, just turn the subtraction in the variables to addition and < signs in the if statements to > signs. With these few tweaks here and there, the right to left animations in card view can be turned into left to right ones!

• You can also show and hide views using animations.

For this, you have to keep track of the start position and end position then animate them with alpha() from 0 to 1. For an example, you can refer to my library Accolib to create animated FAQ accordions.

• Basic animated layout changes can be achieved with view animations.

Thanks a lot for reading so far, I hope this post added some value. Subscribe to my newsletter at Genics Blog to stay updated with my future articles!

Each one has a specific use case and code that goes along with it. To learn how to use them, read on.

Each menu must have an XML file related to it which defines its layout. These are the tags associated with the menu option:

<menu> - This is the container element for your menu (similar to LinearLayout)

<item> - This denotes an item and is nested inside of the menu tag. Be aware that an item element can hold a <menu> element to represent a submenu

<group> - This is used to signify a certain property or feature to a couple of menu items (I.E. state/visibility)

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:actionProviderClass="http://schemas.android.com/tools">
    <item android:id="@+id/item1"
        android:icon="@drawable/ic_baseline_check_circle_24px"
        android:title="item1"
        app:showAsAction="always"
        />
    <item android:id="@+id/item2"
        android:icon="@drawable/ic_baseline_copyright_24px"
        android:title="item2"
        app:showAsAction="always"
        />
    <item android:id="@+id/item3"
        android:icon="@drawable/ic_baseline_favorite_24px"
        android:title="item3"
        app:showAsAction="always">
    </item>
</menu>

As shown in the code snippet above, each menu item has various attributes associated with it. I’ll detail the main ones here, but if you want to see what else you can add, go here.

• id - This is a unique identifier for the item in the menu. You can use this to see exactly which item the user clicked
• icon - If you want to show an icon associated with that menu item
• title - Text that will be shown in the menu for that item
• showAsAction - This attribute should only be used when using a menu in an activity that uses an application bar(or as it is also referred to, the action bar). It controls when and how this item should appear as an action in the application bar. There are five values: always, never, ifRoom, withText, and collapseActionView

android:showAsAction="always|never|ifRoom|withText|collapseActionView"

I’ll elaborate on the meaning of each of these values in the next section.

In addition, you need to add the relevant onCreate menu method to your activity.

//Options Menu
@Override
public boolean onCreateOptionsMenu(Menu menu) {
    MenuInflater inflater = getMenuInflater();
    inflater.inflate(R.menu.options_menu, menu);
    return super.onCreateOptionsMenu(menu);
}

//Context Menu
@Override
public void onCreateContextMenu(ContextMenu menu, View v,
                                ContextMenu.ContextMenuInfo menuInfo) {
  super.onCreateContextMenu(menu, v, menuInfo);
  MenuInflater inflater = getMenuInflater();
  inflater.inflate(R.menu.context, menu);
}

Options Menu

This menu is usually found at the top of your application and in it, you should place actions that affect the application as a whole. These could be the application’s settings or a search box.

Using the menu layout from above, we get the following options menu:

As promised, let’s go over the values that can be given for the showAsAction attribute:

• always - will always show in the action bar
• never - will never show, and therefore will be available through the overflow menu
• ifRoom - only if there is sufficient space in the action bar, then it would be shown. Keep in mind that per the documentation, there is a limit to how many icons you can have on the action bar.
• withText-will include the item’s title in the action bar
• collapseActionView - if this item has an action view associated with it, it will become collapsible(from API 14 and above)

If we go ahead and change the last item in our menu to showAsAction=”never”, we get the following:

The third menu item moved to the overflow menu

Contextual Menu

This menu appears when a user performs a long click on one of your UI elements. The options found in this menu affect what UI element the user made the click on. It is common to use this type of menu in list or grid views, where the user’s interaction with each item can lead to a specific action.

Imagine a scenario where you have an application with an image, and you want to present to the user several choices when they click on the image.

A context menu can appear in two ways :

1. A floating menu
2. An action bar at the top of your application

We will only demonstrate how to use the first option, but you can read more about the second option here.

Using the following XML:

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item
        android:id="@+id/share"
        android:title="Share"/>
    <item
        android:id="@+id/Mail"
        android:title="Mail"/>
    <item
        android:id="@+id/MoreInfo"
        android:title="More Information"/>
</menu>

And adding the following code to our main activity:

 @Override
    protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.activity_main);
       TYPE_OF_LAYOUT layout = (TYPE_OF_LAYOUT)findViewById(R.id.main_layout);
       registerForContextMenu(layout);
  }

We will get the following:

When performing a long click on the text, the context menu appears

Popup Menu

A popup menu is a type of menu that displays items in a vertical list. This list is attached to the view the user has clicked on to invoke this menu. It is important to keep in mind, that when choosing a popup menu, you do not want the user’s choice to affect the previous content the user pressed.

We will use the same menu XML layout as before, but we will need to add the following code to our activity:

void showPopupMenu(View view) {
  PopupMenu popup = new PopupMenu(this, view);
  MenuInflater inflater = popup.getMenuInflater();
  inflater.inflate(R.menu.actions, popup.getMenu());
  popup.show();
}

We will get the same result as the previous screenshot, but without the need for the user to perform a long click.

Icons In Popup Menus

Now I know what you are probably here for: you want to know how you can add icons to the menus.

While I will show an example of how to do this, it is wise to understand that this is a feature that is not enabled for popup menus and may cause unexpected behavior. You can achieve this by using reflection to turn on a flag called setForceShowIcon.

//popup is an instance of PopupMenu

try {
      Field[] fields = popup.getClass().getDeclaredFields();
      for (Field field : fields) {
          if ("mPopup".equals(field.getName())) {
              field.setAccessible(true);
              Object menuPopupHelper = field.get(popup);
              Class<?> classPopupHelper = Class.forName(menuPopupHelper
                      .getClass().getName());
              Method setForceIcons = classPopupHelper.getMethod(
                      "setForceShowIcon", boolean.class);
              setForceIcons.invoke(menuPopupHelper, true);
              break;
          }
      }
  } catch (Throwable e) {
      e.printStackTrace();
  }

I’ve just scratched the surface with Android menus, but hopefully, it is enough to inspire you to dig deeper.

Push Notifications fail on specific Android phones. Here’s why.

I recently added support for Push Notifications in the Kayako App. I tested and shipped it. And I thought I did pretty good job.

But then one by one, my users start commenting that the the app doesn’t show any notifications about 95% of the time. At first, I thought it was a mistake because the Push Notifications were working as intended on my emulator and devices. But as I dug deeper, it became clear how serious and valid this problem was. This was but the tip of the iceberg. Close to 50% of our Android app users were affected but only few informed us about it.

So, what’s the problem?

Push Notifications are not working properly on specific Android phones.

I use the word ‘properly’ because users receive push notifications when the app is open but not when it is closed, which defeats the purpose of push notifications.

I use the words ‘specific Android phones’ because this issue is noticed only on phones by manufacturers like Xiaomi, Oppo, One Plus, Vivo, Lenovo, Huawei, Samsung, and a few others.

Why is this happening and how do we fix it?

To understand the problem, let’s first understand the Android UI and the expected behavior of Push Notifications.

On Android, we have three buttons at the bottom as part of the Navigation Bar. The square button, on click, opens the Recents screen. The Recents screen lists all the ongoing tasks or apps recently opened. We can clear these applications at any time, as shown below.

Recents Screen

Yet on certain stock ROMs (Android operating system customized by device manufacturers), clearing an application kills that application and its background services. This is bad because we need background services to show Push Notifications.

When the server informs the Android device of a new Push Notification, it would normally re-start the application’s background services to show the notification to the user. That’s good because background services will automatically start to show push notifications.

The image below shows the expected behavior which is the case for vanilla ROMs. This is the original Android firmware that is not customized by manufacturers.

Expected Push Notification Behavior

Yet despite this, some Android phones using the Kayako app are not receiving Push Notifications when the app is cleared from Recents screen. The reason is that phone manufacturers like Oppo, Xiaomi, and One Plus use a stock ROM that disables the re-starting of background services for most apps. This is bad because we’re back to where we started with no way to show Push Notifications.

Thankfully, these stock ROMs have a Settings page to enable the re-starting of background services. Although the auto-starting of background services are disabled by default, users can manually enable this feature by following some instructions. This is good because now background services can be automatically started to show Push Notifications. But, it’s an ugly solution because it involves some manual work that the user has to do.

The intentions of the manufacturers are to conserve battery and improve performance. The app users now have to open their settings app, navigate to the correct page, scroll through a list of apps, and then enable the feature for the Kayako app.

But wait, why don’t apps like Gmail and Slack have these problems?

Top-popular apps like Gmail, Slack and Whatsapp are whitelisted by these stock ROMs. That means these apps have auto-launch enabled for them by default.

However our app, along with many many others, have auto-launch disabled by default.

One Plus ‘Apps auto-launch’ Settings page

I can’t find the settings to enable auto-launch. Where are they located?

The steps to enable auto-launch for an app are different for different manufacturers. This is because this is not a native Android feature and is very specific to stock ROMs.

It should also be noted that the terminology used by each manufacturer is different. The auto-launch feature can be referred to as app auto-start, start-up manager, auto-start manager, app optimisation, protected apps, or background app management.

To make matters worse, the auto-launch settings page is not easy to find. For One Plus devices (using Nougat or below), you need to open up Settings, click Apps, then the gear icon located on the toolbar, and then Apps Auto-launch under the Advanced sub-category at the very bottom.

Alright, what’s the solution?

In the end, the user will have to perform the steps manually. This can not be programmatically enabled for all devices. The best we can do is to make it as easy as possible for app users to do so.

Create a support article

Kelly O’Brien and I wrote an article which makes an attempt to identify all the device manufacturers with this problem and explain the steps to enable Push Notifications on those devices. You can read about it here.

Inform users in-app

As I mentioned before, not everyone takes the time out to complain. I can not expect users to contact the support team or search for the support article online. At the same time, there’s no easy way to automatically identify if Push Notifications aren’t working when the app is closed.

I decided to show a small footer on the Push Notifications Settings page where the article is available to the user at all times.

Push Notification Settings Page

Open the concerned settings page in-app

I’ve found many Stack Overflow answers like this one which recommend programmatically opening the concerned settings page by detecting your device manufacturer. While I like the idea, I have not implemented this. I haven’t had the chance to test if the device-specific code actually works which puts me at unease.

If you have other suggestions or ideas, I welcome them.

Developers will continue to add new features throughout an application’s lifetime. More code means not only longer build times — it means longer incremental build time.

For teams with big projects, waiting for new builds could eventually take up 10-15% of their workday. This not only wastes precious developer time — it also makes test-driven development extremely tedious, which hurts overall code quality.

Splitting an application into modules could be a solution to this problem. I was tempted to just split our codebase by feature, by layer, or in some other quick and obvious way. But first, I decided to create an experiment and collect some data, so I could make a better-informed decision. This article will explore the results I collected and my findings.

Before we dive into my experiment, I’d like to talk about the theory behind all this, and explain how we can decrease incremental build time.

A bit of theory

When you create an Android application you have to have at least one application module, it is a module that applied the Gradle application plugin in his build.gradle file:

apply plugin: 'com.android.application'

As a result of building this module you will get an .APK file.

One application module cannot depend on another. It can only depend on a library. It is the module that applied the Gradle library plugin:

apply plugin: 'com.android.library'

As a result of publishing such a module you will get an .AAR file (Android Archive Library). Comparing to .JAR file .AAR has some Android-related things, for example, resources and Manifest.

Building process for any library or application module can be roughly split into five phases, that could be represented with a certain Gradle tasks:

1. Preparation of dependencies. During this phase Gradle check that all libraries this module depends on are ready. If this module depends on another one, that module would be built as well.
2. Merging resources and processing Manifest. After this phase resources and Manifest are ready to be packaged in the result file.
3. Compiling. This phase started with Annotation Processors, in case you use them. Then source code is compiled into byte code. If you are using AspectJ, weaving also happens here.
4. Postprocessing. All Gradle tasks with a “transform” prefix are part of this phase. Most important ones are: transformClassesWithMultidexlist and transformClassesWithDex. They produce .DEX files.
5. Packaging and publishing. For libraries this stage means creating an .AAR file in the end, for applications — .APK.

As I mentioned, our goal is to minimize incremental build time. It’s difficult to speed up all the phases in one experiment, so I decided to focus on the longest ones. For a project with a single module, those were the compiling and postprocessing phases. The merging resources and processing manifest phase can also sometimes be time-consuming, but if the Java code is untouched, than incremental build is quite fast.

We all know, that Gradle runs task in consequent builds only if input isn’t the same. It also doesn’t rebuild a module if it wasn’t changed. That leads to the following hypothesis:

“The Incremental build time for a project with multiple modules is faster than for a single-module project, because only modified modules are recompiled.”

All right, lets find out whether this is true!

Experiment Setup

Project uses Gradle plugins v2.2.2. Minimal Android SDK is 15, that covers most of the devices according to API level dashboard. All modules have a dependency on Butterknife, to make project a bit more “alive”, since all projects has external dependencies.

In all variants application module is called “app”, while library modules are called “app2”, “app3” and so on.

Each variant has in total around 100 packages 15,000 classes 90,000 methods. Assembled that is two DEX files, almost three. Generated code is dummy, to keep all the methods in the .APK file, minifying and shrinking were disabled.

All measurements was done with Gradle build-in profiler. To use it you just need to add “--profile” in the end of the command, like this:

./gradlew assembleDebug --profile

As a result you will get a .HTML file with measurements.

For each setup I repeated each measurement 4 to 15 times, to make sure that my results were reproducible.

Java Code Generator

Writing all 15,000 classes by hand is time consuming, so I wrote a simple code generator in Python. It is available in Gist. Below you can find a schema of the code it generates.

As you can see, every next generated method called the previous one, and every first method of the next class called the last method of the previous class. That makes code more coupled, and increased compilation time.

Pure Java modules

I didn’t make a special experiments for pure Java modules. But I played with them a bit, and I can say that usually they are faster then Android ones. That happens because during build less tasks are executed, for example, there is no resources to merge.

If you’re interested in results for pure Java modules, please write a comment. Or you can clone the project from GitHub and modify it according to your needs. But don’t forget that actual results depend on hardware. To be able to compare your results, please repeat some experiments in your environment as well.

Small losses here and there

It’s no surprise that doing something in parallel does slow down the build. Even having a second project open in Android Studio can make build 5–10% slower. Listening to music, watching YouTube, or browsing the internet increases the build time a lot! I personally saw a speeding up of a build process by up to 30% after just closing everything except Android Studio.

All experiments were done with only necessary browser tabs and a single Android Studio project open.

Let’s do the experiment

Initial State

As a starting point I took a project with a single module that contains all 15 000 classes. For this setup incremental build time is 1m 10s.

3 Modules

First step is splitting one module into three: one application module and two library ones. Application module depends on libraries, but library modules are independent from one another. Each module has about 5 000 classes and 30 000 methods.

If changes are made only in application module, then build time is about 35 seconds. Almost 30 seconds win compare to initial state. But when one of library module is changed, even if application module is untouched, incremental build time grows to 1m 50s. 40 seconds longer!

Let’s take a look into profile report and see what took so long:

Profile report of an incremental build with changes in library module (“:app2”). Since application module (“:app”) depends on the library one, it is also recompiled.

In the screenshots above, you can see that most of the time was spent on building the library module. You might also notice that for library modules, both debug and release tasks were executed. Gradle wasted time executing two sets of tasks instead of one! This is why it took an extra 40 seconds longer than the single-module project.

We can avoid this and make this build even faster than our initial 1m 10s by splitting our code into modules.

But that’s not the only problem. Let’s look into how our application module depends on library modules:

dependencies {    compile project(path: ':app2')    compile project(path: ':app3')}

There’s an important problem in the code above: if a library is added like this, then the application always depends on the release variant, independent of it’s own build type. It also doesn’t matter which variant is chosen in Android Studio. Here’s what the Gradle Plugin User Guide says about all this:

By default a library only publishes its release variant. This variant will be used by all projects referencing the library, no matter which variant they build themselves. This is a temporary limitation due to Gradle limitations that we are working towards removing.

Luckily, it’s possible to change the variant our application depends on.

First, add the following code to libraries’ build.gradle file. It will allow library to publish debug variant as well:

android {    defaultConfig {        defaultPublishConfig 'release'        publishNonDefault true    }}

Second, application module should depend on library ones like this:

dependencies {    debugCompile project(path: ':app2', configuration: "debug")    releaseCompile project(path: ':app2', configuration: "release")    debugCompile project(path: ':app3', configuration: "debug")    releaseCompile project(path: ':app3', configuration: "release")}

Now the debug variant of our application depends on the debug variant of the libraries, and its release depends on their release. So lets make some changes to the module app2 and rebuild it. After these changes, we can check our profile report again:

The most significant difference is the absence of :app2:packageReleaseJarArtifact, which saves us about 15 seconds. In addition, the time is reshuffled a bit between rest of the tasks, and we end up with 1m 32s. That is 18 seconds faster then before, but still 22 seconds slower then our initial configuration. For changes only in the application module, build time stays almost the same — 36 seconds vs 35 seconds in our previous configuration.

Unfortunately I didn’t found a proper explanation for why it builds both flavors. I hope that once this Gradle limitation is resolved, then this problem will just go away as well. The same issue is discussed in AOSP Issue Tracker.

I’m also planning to spend some time experimenting with Gradle tasks to find a workaround for this problem. One possible way is to exclude all release tasks for debug builds.

5 Modules

Obviously, build time depends on the amount of code. If you reduce amount of code by half then the build should also be roughly two times faster. If instead of 3 modules project is split in 5, then build time should be approximately 40% faster.

It is almost true.

If changes are made only in application module then incremental build time is approximately 24s. For changes in a library module incremental build takes 50s. Compare to initial 1m 10s that is already a win. But I have a few more tricks at my disposal.

Reduce Size of The Application Module

Independently of what module is changed, application module will be recompiled every time. So reducing it’s size makes total sense. Ideally, it should just assemble whole application from a separate modules and might also provide a splash screen, because splash screen often depends on lots of features.

That is how idea about 3+1 and 5+1 configurations was born. In both cases project has a small application module that depends on 3 and 5 library modules accordingly. All library modules are independent from one another and has equal sizes. Let’s see what that gives us:

We can observe further drop in incremental build time. Even with changes in library module 5+1 configuration is build almost twice as fast as an initial single-module project. This is a decent progress.

Why does project actually depends on Butterknife?

This is a point where I have to make a confession. There was one very strong reason to add a dependency on Butterknife.

In the initial configuration incremental compilation takes 45s out of 1m 10s, but if Butterknife is removed then project is compiled in 15s only! Three times faster! Whole incremental build without Butterknife is 40s.

Is it a problem in the library?

As it appeared — no. Without Butterknife project compiles so fast because of actual Java incremental compilation, which is disabled for projects that use Annotation processors. You can find related issues in Gradle Jira, in AOSP Issue Tracker, it is also tracked in Gradle design docs. If you will take a closer look into the issue from ASOP Issue Tracker, one of the comment says:

“Annotation processors is not yet supported with incremental java compilation. It will depend on changes in Gradle.

We disabled it for project that apply com.neenbedankt.android-apt, so it's no longer a significant issue.”

That is why build just becomes slower without a notification.

Personally I won’t remove Annotation processors from the whole project. I find libraries like Dagger and Butterknife useful. But having a couple of modules without them could be a good idea, that would make their builds so much faster!

One More Trick — Rump Up API Level

Compilation is not the only thing that slows down build process. Producing .DEX files could also be time consuming. Especially if an application is above DEX Limit. Using multidex configuration increases build time, build system need to decided which classes go to which .DEX file. With introduction of Android Runtime the way how Android OS works with application that has multiple DEX files has changed. This is what Android Studio documentation says about it:

“Android 5.0 (API level 21) and higher uses a runtime called ART which natively supports loading multiple DEX files from APK files. ART performs pre-compilation at app install time which scans for classesN.dex files and compiles them into a single .oat file for execution by the Android device.”

That leads to decrease in build time. The reason is that each module produces its own DEX files, that are included into APK without modification. If you take a look into the tasks that run during build, you will notice that transformClassesWithMultidexlist is no longer executed. Also compilation itself became faster. You can find more information and instructions how to make a flavor that uses API 21 here.

Fastest Build Configuration Achieved.

Using API 21 for debug is an easy gain for every project. I tried it for 5+1 configuration and results were amazing:

Even for changes in library module incremental build time was only 17 seconds! But take into account that all modules are independent from one another. Once dependency between modules is introduced, build time increases from 17s to 42s (last row in the table above)!

Developing Library Module in a Test Driven Way

One of the main reasons why test-driven development (TDD) is difficult for single-module project is build time. TDD encourage to run test often. Running tests multiple times in a minute is a normal practice. But when build takes a minute or two, working in Test Driven way couldn’t be very productive.

With introduction of modules that problem is automagically resolved. Building a single module in the last configuration took only 9s! It make possible to run tests as often as needed.

Conclusion

First and most important, the hypothesis was correct, modularizing project can significantly speed up build process, but not for all configurations.

Second, if splitting is done in a wrong way, then build time will be drastically increased, because Gradle build both, release and debug version of library modules.

Third, working in test-driven way is much easier for a project with multiple modules, because building a small library module is way faster then the whole project.

Forth, doing many things in parallel slows down the build. So having more powerful hardware is a good idea.

Below you can find results of all experiments described in this article:

Please vote for mentioned issues. Resolving any of those would be a huge step towards faster builds. Below you can find all links:

• https://code.google.com/p/android/issues/detail?id=52962
• https://issues.gradle.org/browse/GRADLE-3259
• https://code.google.com/p/android/issues/detail?id=200043

All code is published on GitHub.

Nikita Kozlov (@Nikita_E_Kozlov) | Twitter
_The latest Tweets from Nikita Kozlov (@Nikita_E_Kozlov): “https://t.co/wmGSJ7snW1"_twitter.com

Thank you for you time reading this article. If you like it, don’t forget to click the ? below.

This post, like Kent Beck says in his book Implementation Patterns, “…is based on a rather fragile premise that good code matters…”. But we all know that clean code matters as we’ve had to deal for so long with its lack. And so does Kent.

Kent Beck

The Total Cost of Owning a Mess

A few years ago, like every naive Android developer working in an early-stage startup in India, I tried to “hack” real world problems, to “disrupt the industry” and to put a “dent in the universe”. Without a care in the world about good software design or architecture, I started writing code to build an Android app that would one day become one of the biggest consumer heath-care apps in India.

Sprint after sprint, hack after hack, features were built in a mad rush. Build. Measure. Learn. Time-to-market was important and every day mattered. Time flew by, we were growing at the rate of 1 team member every 6 months and the app had hit the million downloads mark.

Our app’s Google Play store downloads and rating.

By this time, the app had stopped being trivial and it had become a multi-tenant client, if that’s even a thing. Features that would take hours when we started now took days, sometimes weeks. Every Activity was 1000+ lines of spaghetti code as Android inherently doesn’t worry too much about the separation of concerns. The total cost of owning a mess had significantly slowed us down.

The Android Conundrum

The code looked ugly, Activities managed everything:

• Threading
• I/O
• Computation
• Layouts
• Config changes
• What not

After all, Activities are Controllers, right? Or are they Views? I didn’t know anymore.

MVC

The Grand Redesign In The Sky

We needed to design the app in a way that changing a line of code somewhere did not break something somewhere else. The app had to be, as Uncle Bob says, “robust but not rigid, flexible but not fragile”.

Robert “Uncle Bob” Martin

This was when my mentor and friend Kashif Razzaqui joined the team to help us alleviate the mess. The grand redesign never happened, but we refactored the hell out of our code:

• We added a “service” layer and moved all the non-UI code into them, one service at a time.
• We chucked AsyncTasks and moved to ListenableFutures using Guava.
• We dumped AsyncHttpClient for OkHttp.
• But more importantly, we started reading a lot: Clean Code, Clean Architecture, SOLID, DRY, The Pragmatic Programmer, Java Concurrency In Practice, Domain Driven Design, etc.

Soon we started seeing the benefits of our efforts. Productivity increased, we were writing things faster, everyone was happy.

This was until we unified our apps and all hell broke lose. Just having an additional service layer didn’t cut it.

The Art of Clean Code

After watching Uncle Bob’s videos on Clean Architecture multiple times and reading a lot on Android app architecture, I decided to experiment with the MVP design pattern and RxJava.

A few days into the experimentation, we decided to switch to RxJava and implement MVP using Clean Architecture. We made sure we encapsulated all layers behind interfaces and separated concerns well.

• The View, usually implemented by a Fragment, contains a reference to the presenter. The only thing that the view will do is to call a method from the Presenter every time there is an interface action.
• The Presenter is responsible to act as the middle man between View and Model. It retrieves data from the Model and returns it formatted to the View. But unlike the typical MVC, it also decides what happens when you interact with the View.
• The Model is only the gateway to the domain layer or business logic.
• The Interactor deals with I/O and is the provider of data to be displayed in the View.

Now it’s much easier to switch out one layer with a completely new implementation. Redesigning the UI, a part and parcel of Android app development, has become much easier. Things can finally move fast without breaking.

The Boy Scout Rule

It’s not enough to write code well, the code has to be kept clean over time. The fact of life is that software has a tendency for entropy. We’ve all seen code rot and degrade over time so we borrowed the simple boy scouts rule: “Leave the campground cleaner than you found it.”

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of duplication, clean up one composite if statement.

Conclusion

Our way of building a scalable app might not be “correct” and you might not agree with this post. After all, not all martial artists agree about the best martial art, or the best technique within one ;)

There are many different approaches towards MVP and a lot of interesting solutions to adapt it to Android. The one fact that we can’t deny is that Clean Code matters and you just can’t sweep it under a rug.

This post borrows heavily from Uncle Bob’s Clean Code and steals the title from Kashif’s Droidcon talk from 2011.

If Clean Code matters to you, let’s chat :)
_Twitter: @_arunsasi_
LinkedIn: https://www.linkedin.com/in/arunsasidharan

If you liked this post, please hit the little heart! ❤