A long, long time ago, I wrote a blog post about how I was using Flipper as one of my favorite development tools. Since then, Android Studio has come a long way adding tons of features like a new Logcat and Layout Inspector.

However, there are often times that you’ll need a tool more specific to your own workflow that Android Studio doesn’t provide, and that’s exactly where Flipper’s extensibility really shines. As an example, I’d like to go through building a custom plugin for Flipper, similar to one that I’ve used on my own projects, that demonstrates how easy it is to get started building these tools.

Late last year, Google announced the Android Developer Challenge, a contest for Android developers to show off new experiences made possible by on-device Machine Learning. Since then, tons of developers have submitted their ideas and been hard at work developing their apps. Today, the winners of the challenge have been announced!

Some time last year, Facebook released a new mobile debugging tool, named Flipper. It’s essentially the successor to the widely popular Stetho. Although after talking to many developers, it seems like this newer tool is relatively unknown.

Like Stetho, Flipper has many built-in features – including a layout inspector, a database inspector and a network inspector. Unlike Stetho though, Flipper has a very extensible API which allows for tons of customization. Over the next few articles, we’re going to take a look at Flipper and its plugins, the APIs it provides, and how we can leverage them to help us debug various parts of our app. This post will focus on getting set up with Flipper, as well as taking a look at two of its most useful default plugins.

Getting Started

Getting started with Flipper is really easy:

• Download the desktop client,
• Add the dependencies in your build.gradle:

1
2
3
4
5
6
7
8
9
10

repositories {
  jcenter()
}

dependencies {
  debugImplementation 'com.facebook.flipper:flipper:0.33.1'
  debugImplementation 'com.facebook.soloader:soloader:0.8.2'

  releaseImplementation 'com.facebook.flipper:flipper-noop:0.33.1'
}

• Initialize the Flipper client when your application starts:

1
2
3
4
5
6
7
8
9
10
11
12

class SampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        SoLoader.init(this, false)

        if (BuildConfig.DEBUG && FlipperUtils.shouldEnableFlipper(this)) {
            val client = AndroidFlipperClient.getInstance(this)
            client.addPlugin(InspectorFlipperPlugin(this, DescriptorMapping.withDefaults()))
            client.start()
        }
    }
}

And that’s it! Opening the desktop client should show you an overview of your app with the Inspector plugin configured.

Inspector Plugin

The Inspector Plugin is similar to the one found in Android Studio 4.0, but has a few neat features. I like it because it operates in real-time, and doesn’t require any attaching to process in Studio every time you want to inspect a layout.

Another thing you can do in the Layout Inspector that’s really cool is actually edit properties! Pretty mind blowing to make tweaks in the inspector and watch the views change in realtime. It’s really handy for experimenting with changing padding, and text colors. It doesn’t actually edit any of your xml files, but this allows you to iterate quickly to make sure everything looks right.

Let’s find a view we want to update (like our repository name):

We can click on the the color swatch to open a color picker:

And now when we look over at our device:

Neat!

Database Browser / Plugin

Something I’ve wanted for a long time was a way to view the contents of my database from Android Studio. Right now, if you want to visualize your data or try out some queries – the best solution is to pull the sqlite database file off your emulator/device and run sqlite locally. But with Flipper, there’s a better way!

All we need to do is configure the database plugin, and our tables should show up right away:

1

client.addPlugin(DatabasesFlipperPlugin(context))

Now we can easily inspect the contents of our tables, and even run queries on the live running application!

I’ve pushed a branch of the Github Browser Architecture Component sample with these changes to GitHub if you’d like to try it out. Next time we’ll take advantage of Flipper’s extensibility to create our own plugins to make debugging our app easier!

Recently, I was doing some code cleanup and noticed that there were some data in the database that was no longer needed. I think most developers clean up their codebase of deprecated patterns and unused code, but I personally have not done a good job of ensuring that the same cleanup happens for unused columns in my databases.

Dropping tables that are no longer used is pretty easy (especially if you can just use something like Room’s Migrations) but when trying to remove unused columns, I ran into an unexpected problem. I thought to myself, it’s pretty easy to add or rename a column, why would dropping one be any harder? The existing database library I was using already had a convenient “drop column” method, so I simply called that and tried to run the migration. During the process, I ended up with a ForeignKeyConstraintException! I quickly scanned the schema to see what could have caused that, and didn’t see anything obvious. The table I was trying to modify didn’t have any foreign keys itself, and the column I was dropping was not a foreign key. Curious to understand what was happening, I started to dig into what this method call was doing.

It seems like nowadays, the best advice is to modularize your Android app. It’s a great suggestion for many reasons, including but not limited to:

- improved build performance
- enables on-demand delivery
- pushes you to build reusable, discrete components

Sounds great, right? Are there any downsides? There is one in particular which has been a a pain point for many.

Often times when you’re writing tests, you’ll want to use some test doubles like fakes or fixtures in order to help simulate the system under test. Maybe you have a FakeUser instance that you use in your tests to avoid having to mock a User every time your test calls for one. Generally these classes live alongside tests in src/test directories and are used to test out your code within a module.

For example, maybe you have a model object like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class User {
    private final String firstName;
    private final String lastName;

    public User(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    public String getFirstName() {
        return firstName;
    }

    public String getLastName() {
        return lastName;
    }
}

You might have some code in src/test that creates a bunch of fake users for your tests like:

1
2
3
4
5

class TheOfficeFixtures {
        public static User manager = new User("Michael", "Scott");
        public static User assistantToTheRegionalManager = new User("Dwight", "Schrute");
    }
}

This works great if you’re testing code within a module, but as soon as you’d like to use these fake users in other modules, you’ll note that these classes aren’t shared!

This code can’t be shared between modules because Gradle doesn’t expose the output of your test source set as a build artifact. There are all kinds of solutions for this problem out there, including creating a special module for all your fixtures, and using gradle dependency hacks to wire up source sets.

However, that’s not necessary anymore! As of version 5.6, Gradle now ships a new ‘test-fixtures’ plugin! This plugin creates a new testFixtures source set, and configures that source set so that:

- classes in this set can see the main source set classes
- test sources can see the test fixtures classes

Using the Plugin

You can apply the java-test-fixtures plugin in your build.gradle script:

1
2
3

plugins {
    id 'java-test-fixtures'
}

This plugin will define the necessary source set, and handle all the wiring up of test artifacts. We can now move those test fixtures from src/test/java to src/testFixtures/java, and that’s it! These classes will be ready to be consumed by other modules.

Wiring it all together

Finally, we need to use a special keyword to pull these new fixtures in as a dependency for our tests. In our gradle configuration, we add a test dependency (either API or Implementation) like so:

1
2
3

dependencies {
    testImplementation(testFixtures(project(":lib")))
}

And that’s it! Our other module can now consume these test fixtures without any sort of intermediate modules or workarounds.

If you’d like to check out the complete configuration with examples sharing fixtures between both Kotlin and Java modules to a shared “app” module, I’ve uploaded a sample project demonstrating how to use this new configuration here.

Important Caveat

It’s important to note that this feature is currently only available with the java-library plugin, and has limited functionality in Kotlin modules, and not yet available for Android modules. There are currently feature requests on YouTrack and the Android Issue Tracker to take advantage of this new functionality.

Today Google released their alpha of ViewPager2, a signal of the nail in the coffin for the original ViewPager, originally released in 2011!

Since then, I think it’s safe to say that most developers have needed to make a ViewPager. Despite how prolific it is, it certainly isn’t the most straightforward widget to include. I think we all have at least once wondered whether we should use a FragmentPagerAdapter or a FragmentStatePagerAdapter. Or wondered if we can use a ViewPager without Fragments.

And API confusion aside, we’ve still had long standing, feature requests. RTL support? Vertical orientation? There are numerous open source solutions for these, but nothing official from the support library (now AndroidX)…until now!

Let’s dive in and try to set up ViewPager2! You’ll need your project configured with AndroidX already, as well as supporting minSdkVersion 14 or higher.

If you’re like me, you loved the Night Mode feature that was added to the Nougat Developer Preview a few months ago. You might have been disappointed when you found out that it was missing in later preview builds, and was probably going to be removed because it wasn’t ready.

When the source code for Nougat was released this morning, my friend Vishnu found this interesting snippet in the SystemUI source (better known to end users as the System UI Tuner):

1
2
3
4
5

boolean showNightMode = getIntent().getBooleanExtra(
    NightModeFragment.EXTRA_SHOW_NIGHT_MODE, false);
final PreferenceFragment fragment = showNightMode ? new NightModeFragment()
    : showDemoMode ? new DemoModeFragment()
    : new TunerFragment();

Long story short, if you pass the right extras to this activity, and you’ll get access to the Night Mode settings (as well as the infamous Quick Tile!).

Fortunately for us, this is pretty trivial to accomplish with adb via adb -d shell am start --ez show_night_mode true com.android.systemui/.tuner.TunerActivity, but not everyone who wants this feature is familiar with adb. So I published an app to the Play Store that does exactly that – click one button, and get access to those settings! You can find the app on the Play Store here.

If you want to integrate your Android app with most of Google Play Services nowadays, you’ll find that you are instructed to set up the Google Services Gradle plugin to handle configuring dependencies. The plugin allows you to drop a JSON file into your project, and then the plugin will do a bunch of the configuration for your project, such as handling the API keys.

This is all well and good—unless you’re like me (and countless others) and want to use a different configuration for your debug and release builds. This would be useful, as an example, if you use Google Play Services for GCM and would like to have development builds recieve pushes from non-production systems.

It seems that the plugin is configured in such a way that it supports build flavors, but it does not yet support build types. However, with a little Gradle magic, we can hack that support in.

Pssst! If you’re an Android developer, you might not have heard yet…the N Preview started today! As part of the festivities, a new alpha version of the support libraries was released. There was no changelog that I could find, so I decided to make one. Here’s what has changed (so far) in the public API of a few of these libraries:

Unless you’ve been hiding from all the news about Android development, you’ve likely heard about Kotlin (which hit version 1.0 on Monday!). I’ve been toying around with it lately (the Kotlin Koans are a great place to start for a beginner) and wanted to try building an app with it – that is, until I hit a few road blocks.