The constraints of building a universal tooling framework for Android developers

Tools for Android developers are not legion. We can count Android Studio of course, Leak Canary, Facebook’s Stetho, a few websites for color theming, icons, and animations like materialdesignicons. And probably a few other less known tools.

But we, Android developers, don’t have access to some kind of “Play Store of tools for developers”. Wouldn’t it be great to have access to dozens of tools to help you fight every day against the ever-growing complexity of the Android ecosystem? And be able to build your own special tools for your project(s)’ special needs while we’re at it?

Well, that’s the sole purpose of FAST SDK. “FAST” stands for “Friendly Adaptable Support Toolkit”. Well, to be honest, the name came after we found the acronym, literally meaning “Quick”.

The idea behind FAST SDK is to make Android developers’ life easier by providing a lot of simple but time-saving tools.

One other major goal of FAST SDK is to allow any Android developer to build its own tools (or extensions) quickly and simply thanks to our platform.

The objective of this article is to describe the major constraints that have been defined from the start before starting building the SDK.

In-app tools you will build

Being Android developers, we know how to do one thing: Android apps. So how to build tools then?

We could have built an android app, or several android apps. But there are a few inconvenient:

  • You have to install the app(s) on every device/emulator
  • You get limited interaction with the app (that you are developing)
  • Switching between your app and our(s) can quickly become frustrating
  • We can’t interact with the app’s code (nor UI) without having to add a lot of extra code

So external apps aren’t good. How about some overlay app like Window VQA?

  • It’s still a third-party app, meaning you get all the convenient listed above
  • You have to define the app as your device/emulator System Assist app, meaning that it will be replacing Google Assistant (not great if you are using your personal device)

Not good either. How about we build in-app tools then? In-app tools you say? What is that?

Well, it’s a tool that would display in your app, over your app’s layout. Wait a minute, don’t tell me that you want to alter my layout!?

Fast’s tool launcher
The “Tool Launcher”

Rest assured, we are not. It will seem like magic to you, but we have actually managed to do it without altering your activities’ layout.

Since it’s integrated (and compiled) in your app, we can:

  • Interact with your UI
  • Interact with your code
  • Access mostly everything in your app (like databases, shared preferences, files, etc…)
  • Display UI tools in your app, over your layout(s)

And that would be perfect. The only downside, of course, is, well, it’s in an Android app, on an Android device/emulator. Meaning that the tools are displayed on the not-so-large screen of the device.

But you will quickly see that the many advantages outweigh this tiny inconvenient.

Dependency nightmare avoidance

One of the key constraints was to not depend on any third-party libraries, Android/Google’s included.

There’s one simple reason for that: dependency conflicts. Of course, one of the main goals of FAST is to be adopted by as many developers as possible. Meaning being usable on as many projects as possible.

One question that comes immediately to mind is the following: “How are we supposed to know which version of the androidx (to only take this example) libraries will our users use in their projects?”.

I’m sure you all know that it’s almost impossible nowadays to make an Android application without relying on the androidx libraries (or the old appcompat versions for older projects) or material design components.

Android dependencies
Just looking at this dependency tree hurts…

Since it’s impossible for us to know in advance which version of which library your project use, how did we manage to make an SDK working with all versions?

Well, the answer is quite simple: we don’t rely on any third-party library, androidx and material components included.

This way, we are 100% certain to be compatible with all projects because we only rely on the core android framework. No dependency conflict possible.

While the answer is simple, the implementation required a lot of work. Since we couldn’t use the newer widgets nor theming capabilities of the last Google libraries, we had to build our own from scratch.

We ended up having to write quite a few components of our own, and find a few hacks to theme the “old” widgets as we needed to.

Android Compatibility

Being backward compatible with Android 4 was out of the question. It would have required way too much work while gaining next to no advantages as most apps don’t support this version anymore.

Gold old Nexus 4, with Android 4.2, released at the end of 2012.
Does anyone still have one of those?

So we chose to be backward compatible with Android 5 (API 21) as our oldest supported version.

The main issue here is that we don’t rely on the support libraries (androidx), hence we don’t have access to the “Compat” classes.

So we had to actually import a few bits of code here and there so that we could get rid of theming issues mainly.

Androidx Compat classes are actually quite simple, they just use the newest methods of the Context class mainly when the API level is high enough. A good chunk of the methods are checking against Android 4 and since we are only backward compatible with Android 5, we didn’t have to reimport whole classes.

Extension in mind

Being able to build tools for common use cases or painful areas of the Android ecosystem is great. But what if a developer needs a special feature or a completely dedicated specific tool for his specific project?

The good thing here is that we’re building Android tools using the Android ecosystem. Meaning any Android developers should be able to do some Android code to build some compatible stuff right?

Since we can’t possibly build tools for every special use-case of every app, we did two things.

So the first thing is called “extensions”. It’s a quick and easy way to add functionality to an existing tool. For example, you can enable the support of your custom widget in the View Inspector by adding a small extension that will just add a few lines of code to cover your widget’s custom properties.

The View Inspector plugin
The View Inspector. We should probably have called it “View Editor” since you can live edit all your views’ properties…

This second is to offer the possibility to every developer to build its own “plugins” (that’s how we call the tools) on our framework.

This way, we can build some sort of Play Store of tools for Android developers, with public and private tools.

Ease of use and small time-saving features everywhere

No one loves a complex UI or a counter-intuitive UX. And it’s not because we are developers that we should have it the old hard way. That’s why one of the key constraints is the ease of use and time-saving features.

That’s why we replicated the back stack (not easy when you don’t have access to the androidx lifecycle library) by searching through the inners of the Android framework. This way, you can easily navigate through the tools screens without interfering with the default back stack of the Android framework.

We also added keyboard shortcuts, so that you can quickly open your favorite tools or get access to your favorite feature (when using the emulator or a screen-mirroring app).

You can use the keyboard shortcut indicated on the right of each item to select the desired option of the Restart Options plugin

We added a copy feature so that you can copy a chunk of information from the app (if using the emulator) and paste it in Android Studio (or elsewhere on your computer).

We added a code generator feature so that you can quickly see the changes you need to add to your code.

An example of generated code

Our color picker is probably one of the best available Photoshop-like color pickers, and also includes tabs to quickly access material colors or your app’s color resources.

Fast’s color picker
The color picker tab of the color picker dialog

Most of the tools include a sorting feature for data lists. Others include options like filters, add/remove, refresh, unit conversions, etc… when relevant.

We try to do everything so that you can save time (but your ideas are most welcome 😉 ).

Coding simplicity

We built FAST because we think Android development becomes more complex every day instead of becoming simpler.

That is why, when a tool requires some extra code, we try our best to make it as simple as possible for you to interact with a plugin’s base code, or to build an extension.

We try to take advantage as much as possible of the new simplicities brought by Kotlin.

Kotlin, my new best friend

We had already made the transition from Java to Kotlin. And we think a lot of Android developers did too. We won’t list all the advantages of Kotlin over Java. Suffice to say that we didn’t see ourselves coding this big framework in Java.

As of today, being Java-compatible is not our top priority as less and less Java projects should subsist.

That being said, most tools don’t require extra code from the developers and can be used as-is, so they are already Java compliant.

We will try our best to add Java compatibility to the tools that require some extra code.

Conclusion

It took more than half a year to build the core framework supporting our 13 tools. It has become enjoyable not having to worry about theming, fragments, activities, Google and third-party libraries, etc…

While it still requires to pay attention to a new tool’s architecture, we can now build most tools simply and easily as most components are already available.

We will continue to build new tools and features and are hoping you will start building yours, so that, together, we’ll build the largest framework of tools for Android developers.

Share

Share on twitter
Share on linkedin
Share on reddit
Share on facebook
Share on email