One still surprisingly valid reason to use the old Animation (API 1+)

and how I made Chet Haase question everything he held dear

Photo by Ellen Isaacs (source)

Back in 2011 with the release of Honeycomb (API 11), the Android UI Toolkit team introduced the new animation system, known to you all by classes like ValueAnimator and ObjectAnimator. This was done to replace the old android.view.animation system, which had quite a few flaws:

• it could only animate Views, but not arbitrary values in your app;
• it could only animate certain properties of Views: translation, rotation, scale, and alpha, but nothing else;
• most importantly, it could only animate the appearance of animated elements, but not their actual properties. When a View was animated, its parent ViewGroup simply applied a transformation matrix when sending it down the rendering pipeline. The View framework layer was unaware of the transformation though and treated the View as if it was within its original bounds. This resulted in a bug where an animated element could be drawn elsewhere on the screen, but click events were still captured at its original position.

The new Property Animation system solved these problems. It was versatile and decoupled from the View framework. When used to animate View’s position, it actually changed its respective properties, effectively updating its touchable bounds. It became a preferred way to animate Views, and after the introduction of View Property Animation (.animate()) in API 12 and then Transitions API in KitKat, there was little reason left to use the old one.

Side note. The old Animation system (R.anim) is still used for Activity and Fragment transitions. Here I compared it to the new Transitions API. But that’s a well-known use and not what the story’s about.

Fast-forwarding to 2018 when I’m writing my latest app, Three.do. For the context, it’s a minimalist unique reminder app with the main focus on ultra-fast UI that lets you capture tasks super-quickly. To give you a feel of how quick it is, here’s a gif of me adding a reminder in ⅓ second:

Name an app where you can add reminders faster, and I’ll gift you Pro

This animation here is exactly why I’m writing this article (and for some shameless self-promotion, duh!)

Let’s look at the same “add a reminder” flow executed at normal speed:

Install my app to feel it in glorious 60 FPS

A user taps on tiles to build a reminder title. The next set of tiles replaces the previous one with a subtle slide-and-fade animation. This seemed trivial, so I went on and coded it with .animate() as I would usually do in such case:

But then I noticed that when I tapped the tiles very fast, some clicks wouldn’t register. Why would that happen? You guessed it — the entering tiles were still animating and a few dozen pixels away:

This was a problem. One of the unique selling points of my app is that users can learn to quickly tap the tiles instinctively, with muscle memory, without giving it any thought. Rapidly tapping in one place is one of desired scenarios: a user expects that tapping in the place of a (x; y)-tile selects it regardless whether the animation has already finished or not. Having to wait or getting your clicks ignored would nothing but stumble the user and break the flow.

There were a few ways to address this problem:

• implement custom onTouchEvent() — too complicated;
• inflate faux static views on top of the animated ones — too redundant;
• give up on the animation altogether — too radical;
• remember about the old Animation API and its ‘bug’ — bingo!

And so I rewrote the above animation with this:

And the appearing tile started capturing the second click as if it were in its place already:

Note: I disabled AlphaAnimation in this gif for better illustration

That’s the whole trick for you. If your app or game has pieces of UI that take a while to slide in while the user may be anxious to tap them faster, using the old Animation system can actually improve the experience. Unfortunately, most of the docs on Android Developers have been purged for this old API, but pieces of it can still be found here and there.

So what about Chet?

Chet Haase is the Lead of the Android UI Toolkit team. He’s one of the people (if not the one) who took down the old Animation system and replaced it with the new one in Honeycomb. And so it happened that he was also one of the keynote speakers and superstar guests at our darling conference GDG DevFest Ukraine where I had joy of volunteering for the last few years.

The conference ends, and there’s this ‘secret’ after-party for speakers, organizers, and volunteers only. I’m there, Chet is there, everyone is celebrating and chatting with each other. At some point I break into the conversation.

“You know, Chet, there’s actually still one valid reason to use the old Animation API.”

“Don’t use the old Animation API,” he replies.

“Hold on, let me just show you,” I say, rushing to get my phone.

“BEHOLD the fastest reminder app ever!” I say while presenting Three.do to him and Daniel Galpin who was also there. I explain the problem and how I have decided to use the old system’s flawed behavior to my advantage.

Chet looks mildly perplexed. “So you actually want the bug?”

“Yep! For me it’s not a bug, it’s a feature.”

And Chet had nothing to say to that.

Dan, me, and Chet, photobombed by Andrea Falcone

Thank you for bearing along. If you liked my story and want more like these, please clap and follow and stuff, but best of all — please do check out my app. Not only you fellow developers can find it very useful, but I also did some interesting things there from design and engineering perspective that I’d love to share eventually. For example, how about blazingly fast cold start time? (only 350 ms on my old Nexus 5) Or this dope af text animation? When I reach 50k downloads I swear I’ll open source it as a library.