FAST SDK: How it came to life

The following story has been written by our founder and relates the events that came to the idea of FAST.

I’ve started working on Android during its early stages. It was in 2011 and it was on Android 2.1, a.k.a “Éclair”. I’m pretty sure most of today’s Android developers have never worked on Android below version 4.

Back then, being an Android developer was pretty easy. Our IDE was Eclipse (because Android Studio wasn’t born yet). It was compiling very quickly. Dependencies were easy to manage. First because they were few, second because it was managed the old school way: just copy/paste all of the library files into your own project.

Developing was easy too. You were basically only making a succession of activities containing a list or grid (using ListViews and GridViews). You could use fragments, you could also not use them.

Android features were few, hardware wasn’t as advanced as today. Meaning making an app wasn’t as complex as today. Oh it was the good old times.

Who remembers this animated background!? Source Wikipedia

Still the same old tools

Fast forward in 2019. We got Android Studio and Gradle. I’m going to be honest here. While I realize that both tools are very powerful and are in no way comparable to Eclipse back in the old days, I… hate both of them. Well it’d be more accurate to say that I love them when they work and I hate them when they don’t (or, in the case of Gradle, when I’m fighting for hours to understand why the f*** the build fails).

We also got Kotlin, which is awesome. Seriously, it’s just way faster and easier to code with Kotlin compared to Java.

So that’s it for the tools. 8 years, and we only got Android Studio, Gradle and Kotlin. Sure, Android Studio has packed a lot of tools over the years, but let’s be realistic here, which ones are you using 99% of the time? For me, those are:

  • The code editor of course
  • The project/file explorer
  •  The Play (Apply Changes) button
  •  The Logcat

And that’s it.

I still don’t understand how, in 2019, the logcat is still buggy as hell (unless it only happens to me). For example, why do I see some (a lot actually) system logs even though I’ve selected “Show only current application”? It’s so f**ing annoying.

Where are my logs...? (Answer: they're in green, I don't WTF the others are)

And why can’t I see my crash stacktrace when the app crashes, because the logcat just reset itself and don’t want to show me the dead process logs?

I could continue on an on.

At some point, back in May 2019, I just got tired of this continuous, bad “Android developer experience”. I came to realize that, as Android developers, we didn’t really have any tools to help us design, code or debug our app.

Sure we have AS’s XML design view but it only previews static content, and you can’t preview layouts that are hard-coded in Java or Kotlin.

Sure we now have AS’s Layout Inspector but it’s slow and we can’t edit the view properties, we only get a read-only access.

Sure we got the logcat to see debug messages (when it works) but I can’t say it’s really handy.

Sure we have (name your favorite useless AS tool) but I’ve ever used it once or twice.

Third-party tools

It wouldn’t be fair not to talk about third-party tools, because there are a few that exists. There is LeakCanary from Square (which I haven’t ever used), Stetho from Facebook (which I’ve used a few times before forgetting about it).

I’m sure there are other tools out there, probably some that I haven’t heard of, or that are only available for Mac users (yes, I’m working on Windows…).

A spark born out of frustration

I think I had the idea for FAST when I, as a 8-year experienced Android developer, spent two freaking hours on a RelativeLayout issue and couldn’t understand why it wouldn’t produce the result I wanted (yes, I  know, we now have the ConstraintLayout but for some reason I don’t remember I needed a RelativeLayout). 

So many times in my career as an Android developer, I had to spend days just to make what I considered a “simple” feature. But there was always something in the Android ecosystem that gave me the impression to tell me this, every single time: “Sorry mate, we don’t like simple stuff. Simple is for idiots. So you’ll have to struggle at least a couple days to figure out how to make your simple idea work. We like to make your life challenging every day by making you waste so much time on simple concepts that we’ve rendered overly complex.”

I’m sure many developers have experienced the same thing but would have just answered me: “That’s how it is dude. Stop complaining and deal with it!”. Really? Is there really nothing we can do to make our everyday life easier and stop struggling to make simple things work?

A few fun memes I found looking for “Android developer” on Google Image

So sure, I could complain a lot about the Android ecosystem. I could even write a blog post with a list of complaints so long that no one would read it. But I also know that no platform, OS, IDE, development language, is perfect and that the guys behind those are trying to do their best every day.

The issue with the RelativeLayout (which is the layout I always try to avoid by the way) triggered the following thought: “Oh gosh, I wish there was a live editor for my layout, this way I could understand what’s wrong in no time”.

That’s when I got the idea to make a real-time, in-app, layout editor. At first, I thought: “No way, it’s just going to be too hard, too complex and mostly too long to make. If no one, even Google, did it before, that’s probably because it’s impossible”. Well, it’s always impossible until it’s done.

And so, I spent the next two months on it. I must say, to provide context, that I didn’t quit my job or anything. Because I’ve been working as a freelancer since I’ve started working on Android. So it’s quite “easy” for me to spend a long time working on a personal project (well, as long as there’s still money on my bank account that is).

After a few weeks of work, I had my proof of concept, and it was working pretty well. I just thought it was awesome and that it would save me many hours, even days or weeks of work in the future. The hard thing was to support every little widget. Because there are more than 200 just in the core Android framework (I’m not even talking about the support/androidx libs or the material components here).

The other hard thing was that I couldn’t use any of the support/androidx libraries (since I couldn’t know which version of the support/androidx libraries a project integrating my tools was depending on, risking dependency conflicts), meaning that I could only use the basic widgets and features of the core Android framework. That made me lost a lot of time since I had to code many “basic” widgets and features myself. But I also learned a lot about the core of the Android framework along the way.

Why stop there?

Anyway, at some point, I got a new idea. Why couldn’t I also make an “Overlay” tool to display various visual information on top of views, like size, margins, paddings, position, grids, gutters, etc…

Then I got another new tool idea: Actions. At this point, it was becoming clear that I wasn’t building a tool anymore but a suite of tools.

Day after day, ideas of new tools and new features kept popping up into my head. I wanted to start every new idea I had but I knew I had to avoid this mistake I made so many times in the past. So I wrote down every little idea I had until a point where I had no less than 24 different tools.

I couldn’t stop yelling to myself: “How could Google not think about this simple solution, about all these (relatively simple) tools for all those years!?”

24 tools. For years, I had coded with nothing else but a code editor and the logcat. Like every other Android developer. How many days, weeks, months of work could I have saved if I had access to those 24 tools?

And I don’t think that 24 is the end of it, it’s just that my brain stopped having ideas because I had to focus on the tools I was making at the moment and work hard to finally make a public release.

Speaking about it, initially, I wanted to release only 3 tools. But then, as any (inexperienced) entrepreneur, I thought that it wasn’t enough. So I then made another 3 tools for a total of 6. Even then, I thought it wasn’t good enough, but I also knew I had to start somewhere, and start making it available to know what other developers were thinking about it.

Something is better than nothing

If I’m being completely honest, I don’t think my tools are the best in terms of UX. Mainly because you have to use them in-app, meaning that the screen size is limited and come over your app. I’m well aware that a desktop app would be much better but since I only know Java and Kotlin as development languages (and some server-oriented languages that doesn’t help me more in this case), I told myself that at least it was better than nothing. And so, I did my best to make tools that are easy to use for the developer and have a good design (I’m not a designer but I tried my best!).

By and for Android developers

Right from the start, I have put a lot of effort to make the tools easily extendable. That’s why I implemented the plugin and module system. This way, you can easily support your custom widget in the view inspector if you like, create your own actions, etc…

You can also make your own plugins if you don’t want to wait for us to make the feature you need, and you can use our custom widgets and interact with the SDK.

I also made the tools for me, as a developer. Meaning I was both the client and the user of the project. I wanted the tools to be easy to use, and to be time-saving in every way. That’s why for example, FAST remember which options you’ve set the last time you used it, or why you can use keyboard shortcuts to launch plugins, to name a few handy, time-saving features.

As you can see, not making a desktop app also has its advantages. This way, every Android developer can make its own plugin and modules to fit their needs.

Aiming to simplify a lot of Android stuff

Anyone can make the simple complicated. Creativity is making the complicated simple.

Charles Mingus

I really hope that FAST will become the best friend of every Android developer and make you happy to code every day.

I also have plenty of other ideas to make Android developers’ life easier. While Google continue to overcomplexify the Android ecosystem, I aim to oversimplify it. I mean, you shouldn’t have to write so many classes and so many lines of code, just to display a simple list, if you know what I’m talking about…

I’m looking forward to what we’re going to build with the Android developer community, and I’m welcoming any feedback, whether you agree or not with my vision.


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