At the end of next week I will be leaving my job at Google and moving on to a new challenge outside $GOOG.
Looking back, it’s funny to think that I’ve been in the same team and the same role for that entire time. I was even lucky enough to relocate to Sydney and back to London within that time.
I can honestly say that I’ve loved every minute of it. Whilst I am sad to leave 😢, I feel like now is the right time for me to explore what’s next for me. I’ve learned so much, from so many people over the years (lots now outside Google), thank you.
This blog post isn’t about my reasons for leaving or anything like that. Instead I want to take 10 mins and take a trip down memory lane to look at some of the people and projects who helped me get to where I am today.
I joined Google over 8½ years ago in January 2013, joining the Android Developer Relations team. I was soon given a ‘starter project’: ActionBarCompat…
ActionBarCompat (AppCompat)#
At the time a lot of apps were using (or migrating to) the fairly recent ActionBar. This was before AndroidX or Jetpack existed, and the ‘Support Libraries’ was actually really just one support library: support-library-v4.jar. There was also v13 but it was mostly an add-on library to v4.
Since most apps didn’t have a minimum SDK version of 11, apps were increasingly relying on the ActionBarSherlock library by Jake Wharton to provide a backport of the ActionBar APIs to work on prior API levels. To ease the pressure on Jake, the Android team decided that we should do our own version, which is how the idea of ActionBarCompat was born.
When I joined, the skeleton project had been setup but not much progress had been made on the functionality itself. I was given it as my starter project, and tasked with getting something shipped by Google I/O 2013, 5 months later.
Ultimately the version which shipped at I/O ‘13 was a bug-ridden mess, but it had just enough functionality to support the Google I/O app that year:
I continued working on AppCompat (née ActionBarCompat) for roughly 4 years on and off. Kirill Grouchnikov took over development for a few years and now it’s close to being in maintenance mode.
When I look back though, it’s probably one of the things I’m most proud of, for a number of reasons:
Perspective change#
When you look at how well supported AndroidX is nowadays you might think it’s always been that way… but it hasn’t. The early years of the Support Libraries were not particularly well supported by the Android team. It was mostly worked on by those who though had a passion for it, rather than cohesive goals to support developers. AppCompat and v4 became so fundamental and far-reaching for developers that it forced a perspective change by Android leadership.
A few things happened in my opinion:
- The Android team realized the impact of the API level fragmentation issues which developers were facing. For some framework teams, any time a new platform API was added they would help out with creating the
v4(Core) shims. Some teams don’t though, which is still an issue to this day. - v4 and AppCompat got so big that DEX method count limits became a real issue. This led to the idea of splitting them up into smaller pieces.
- Shipping libraries to developers was accepted as an ‘impactful’ thing to work on. This might sound weird, but engineers (usually) want to work on things which move them upwards. If you can’t show impact, you’re not working on the right things in Google.
Anyway, I think these ultimately led to the beginnings of Android Jetpack, Architecture Components, etc.
Being the glue which holds things together#
AppCompat has a very wide remit, of backporting parts of the Android UI Toolkit back to earlier API levels. Since there was usually only 1 engineer working on AppCompat at each time, any time a new feature needed to be backported, that team would create the backport implementation, and then AppCompat would be the glue which made them easily usable for developers.
Before those features even came about though, there was an increasing need to backport features to views. The most important feature was drawable tinting which was fundamental to how Material Design was implemented in Android Lollipop.
Libraries can’t just bolt-on or instrument existing framework classes, so I spent a long time trying to come up with a reliable and seamless way to get tinting to work for apps. In the end, I came up with the hack idea of replacing an app’s views with our own implementations at runtime, through the use of LayoutInflater.Factory.
This blog post talks a little bit of what it looks like:
In essence, any time you use <ImageView> in your layout, AppCompat would replace it with <androidx.appcompt.widget.AppCompatImageView> which contained a backport of the tinting functionality.
This quickly expanded into other views, such as <TextView> which enables downloadable fonts, autosizing and emoji to integrate into AppCompat. There are now 13 AppCompat widget classes which get replaced at runtime. This functionality has even been expanded to enable Material Design Components to ‘inject’ their own implementations.
When I look back, it actually looks like a simple & obvious solution, but it wasn’t at the time! It amazes me that this load-bearing hack works still!
DayNight#
The last one I’ll mention is DayNight. Dark Themes have had a bit of a renaissance lately, with support added in both Android 10 and iOS 13, but of course they existed before that. In fact, AppCompat has provided dynamic dark theme support before it was cool 😎, way back in 2016:
The first major customer of DayNight (that I remember anyway) was the Twitter app for Android. I remember vividly working with Joaquim on some utterly weird bugs triggered by DayNight, such as one where the text color would randomly change from light to dark (and vice-versa).
There was also a bug which still haunts me to this day: DayNight + WebViews. The root cause of all of these issues with DayNight is that it pushes the Android Resources system to the limit, which opened up a whole load of bugs which weren’t really anything to do with DayNight.
For those using the feature now, you have Alan to thank for spending a _ lot _ of time tracing resource system calls to find a combination which works. Thanks Alan!
Back to the present#
I think that’s enough of a trip down memory lane for now 😆.
Reminiscing about AppCompat has made me realize how much better Android Development is these days. Even though AppCompat helped developers ship apps which work on all API levels, there were always limitations to what we could do in it. Now that Jetpack Compose is here to completely remove the need for AppCompat, I think it’s time to raise a beverage of your choice to it and ActionBarSherlock. 🥂
Maybe one day I’ll write some more blog posts about other projects I’ve worked on, but for now I’m just looking forward to taking a break, and then starting my new role. 🐥