From Westinghouse to Android Instant apps, a BuzzFeed Journey
About a year and a half ago, BuzzFeed began working with Google on an initiative code named Westinghouse. This would allow an Android app to run natively without installing it. Today we know project Westinghouse as Instant apps.
Westinghouse is in reference to George Westinghouse, who believed in Nicola Tesla. Together they won the Battle of Currents for providing electricity to homes and businesses. Thomas Edison’s DC (Direct Current) solution required that a power station was located within a mile of every house. Westinghouse and Tesla’s AC (Alternating Current) allowed a power station to be located hundreds of miles away from the homes and businesses that it serves. Clearly AC power is for everyone whereas DC power is only for those in densely packed urban areas.
Instant apps, like George Westinghouse’s AC power provides your app’s native experience to everyone on Android, not just those who have installed the app.
The Beginning
Working with Google, we decided to expand our BuzzFeed Video app to include Instant apps. Initially, the Android Studio goodness that made our lives so much easier was not there: No debugger integration, no auto-complete. We resorted to log statements and actually remembering a class’ package name and entering import statements by hand. You don’t appreciate something until it’s gone. True both for relationships and IDEs.
The SDK was installed by hand, and the wh (Westinghouse) scripts were written in Python. One thing that did make life a lot easier is that the build scripts used Gradle. Except for the –P flag, this is standard Gradle command line syntax.
./gradlew :showxiapk:assembleRelease -Pandroid.useOldPackaging=falseUsing our trusty Python scripts we could run on a device. Not just any device, but we had a couple Nexus 5X phones with special powers (rooted phones with a custom kernel actually).
Google introduced the concept of an atom. Think of this as a Gradle module only different. Two new gradle plugins were introduced: the atom and the instantapp.
apply plugin: ‘com.android.atom’apply plugin: ‘com.android.instantapp’
Also a couple new attributes floated around inside of the AndroidManifest.xml file (don’t pay any attention to all this — it’s all been simplified).
We branched from our production code, and began the process. After many Diet Cokes/Mountain Dews and Espressos, we got our first running version (thanks Paul Marino and Dan Tann from the original BuzzFeed Video App team)! From our excitement, one would have thought we conquered nuclear fusion. Even this first version was surprisingly fast and stable. We did have the occasional random crash, but we worked through those quickly.
Google was pleased with our Instant app. They mentioned that they might showcase it at one of the booths at Google I/O. Go Instant apps!
That Day
It was a Friday, and I left work early so my wife Sherry and I could visit our son Kai attending college in Madison Wisconsin. I received a message from Ryan Johnson, the VP of Mobile at BuzzFeed (Ryan has since been bumped upstairs into one of our business units). Google was getting a crash with our Instant app running on an older version of Android that we had not tested. Oh yeah, also they wanted to demo it to Sundar Pichai, the CEO of Google, in two hours (no pressure!).
I was driving and my wife was messaging Ryan. We looped in Aaron Goldberg from BuzzFeed’s Android team. We stopped at a coffee shop somewhere in the middle of rural Wisconsin (but it had killer Wi-Fi!) and Aaron and I conferred. Aaron fixed the offending call, and we were all set, with one hour to the demo.
Google I/O 2016
The demo went well and now we were told that our Instant app might be demoed during the keynote. We were also told, that the producers for the I/O keynote change and cut sections at the last minute, so we shouldn’t get our hopes up.
I received an email from Google the evening before the keynote, stating the importance of not discussing Instant apps until the conclusion of the keynote. Sounded very promising.
Finally the big moment arrived. Here is the YouTube video of Google’s introduction of Android Instant apps to the world:
This was definitely the highlight of my technical career. “I wrote that”, I thought silently to myself, following the non-disclosure directive.
Let’s Do This for Real
BuzzFeed made the decision to embrace Instant apps and go for it. Our starting point was the temporary code branch that had more TODOs and commented out lines of code than we could count. At the same time, BuzzFeed Mobile had two other initiatives underway:
- Absorb the Video app functionality into our core app,
- Convert to a mono-repo allowing numerous apps to be built from a single code base.
At first, doing all of these simultaneously scared the you know what out of me. As it turns out they fit rather synergistically.
Don’t Fear (Gradle) Modules but Embrace Them
The vast majority of the effort to create an industrial strength production Instant app, wasn’t Instant apps specific, but modularizing our now unified code base. Historically Android developers used a simple app architecture of an app module, and perhaps a library module.
What we quickly found was it made sense to have smaller specialized modules. Features of the app were separated into their own modules. In addition, it made sense to abstract a feature even further into definitions and implementation modules.
For example, we can have a base module that has abstract classes or interface definitions. Then a module that implements the definition for the APK, and a different module implements the definition for the Instant app. We did this only for functionality that varied between the APK and the Instant App (which is now few and far between).
This eliminated ugly code such as
if (isInstantApp) { // do something for Instant apps} else { // do something for the APK}
By using polymorphism (or composition), instead of if/else logic, our code was much cleaner (and compact too)! We only pulled in the code that we truly needed.
ProGuard, Ugh!
Another tedious task was using ProGuard to reduced unused code. Again, this was not directly related to Instant apps, but utilized for all released APKs. Because of the need to aggressively reduce the binary image for faster loading, we pursued more explicit matching than may typically be used for a standard APK.
Google’s TODO List
Of course, let’s not forget that Google had a few items they needed to enhance for Instant apps to reach full featured status:
- Google Search,
- Google Play,
- Android Studio,
- The Android kernel.
Instant apps is All Grown Up
As I’m sure you have heard by now, Android Instant apps is all grown up now and released to the public. Android Studio 3.0 directly supports developing Instant apps. and all the Android Studio goodness is back and then some! Its tools now address the major pain points of ProGuard usage and refactoring the code base into separate modules.
I can talk about Our BuzzFeed Instant app!
After over a year of excitement (and silence) about BuzzFeed’s Instant app, I can tell the world about it. So here it is:
Our BuzzFeed Instant app is now available for your viewing pleasure on most newer Android devices!
Simply search for your favorite BuzzFeed show, such as BuzzFeed Tasty, Try Guys BuzzFeed or Nifty BuzzFeed. You get the same rich native experience as if the app is installed.
One of my favorite moments is witnessing people who see Instant apps in action for the first time. You can talk about Instant apps, but to fully comprehend it you must experience it.
Conclusion
BuzzFeed has only begun our Instant apps journey. We are currently adding even more BuzzFeed functionality to Instant apps, so stay tuned. Who knows? It might even be written in Kotlin.
